Гуд бай Повер(точнее дырявый) Бэйсик

[PBDN]

Кажется последняя капля сделала свое дело.
По крайней мере для меня точно.
После того как в Повер Бэйсике решили что их изделие самое лучшее на земле, и это дает им право менять обще признанные законы математики то становится немного страшно. Какие еще супер "гениальные" идеи воплощены в этом изделии которое явно застряло на уровне прошлого века стоит только догадываться. А терять время на раскопки и замены на ассемблер пасхальных яиц дяди Боба уже осточертело.

Если кто пишет программы от которых зависят человеческие жизни, сделайте соответствующие выводы. ПБ дает очень не плохой толчок к получению знаний на уроне АПИ, так что переключится на популярный и ставший ДеФакто стандарт в серьезном программировании С++ не составит большой ломки. ИМХО лучше потратить пару недель на то чтобы переключиться на современные языки, чем всю жизнь конвертировать с него в уникальный но явно попахивающий маразматизмом ПБ.
Ребята явно зашли слишком далеко и этим самым противопоставили себя всему миру категорически не признавая что законы математики выполняются одинаково во всем мире.

Всей русской коммюнити ПБ мои до свиданьки.
Может где еще встретимся на просторах других языков, где скорее всего найдем пропавшего с ПБ форума Семена. К сожалению только сейчас понимаю, почему он порвал с ПБ.

Совсем не пропадаю... буду заглядывать к вам по возможности, пока не сданы последние проекты на ПБ. (Кушать хочется каждый день, поэтому переписывать на С сейчас с нуля почти готовые работы было бы глупо).

Если кто надумает переключаться, может начнем новую серию постов /PB2C/ ?

[D'alex]

Как альтернатива:
http://www.tiflocomp.ru/docs/programming/fbc.php
http://ru.wikipedia.org/wiki/FreeBasic
IDE:
http://www.assembler.ca/radasm/fbedit/index.html
Сайт разработчика:
http://www.freebasic.net
Текущая версия 0.18.2 Beta(2007-10-12)

[PBDN]

Как альтернатива:

Проблема в том, что очень многие заказчики ставят одно из обязательных условий - "Не использовать freeware или shareware программы и компиляторы".

[D'alex]

Проблема в том, что очень многие заказчики ставят одно из обязательных условий - "Не использовать freeware или shareware программы и компиляторы".

Тогда:
http://www.purebasic.com
http://www.purearea.net/pb/english/index.htm

[PBDN]

Тогда:
http://www.purebasic.com
http://www.purearea.net/pb/english/index.htm

Не, с меня хватит тянуть себя в прошлый век.
Смотрим веб-сайты предлагающие работу, и удивляемся почему не требуются програмисты на всех эти Pure и Power и Free бэсиках

[jangle]

Кажется последняя капля сделала свое дело.
По крайней мере для меня точно.
После того как в Повер Бэйсике решили что их изделие самое лучшее на земле, и это дает им право менять обще признанные законы математики то становится немного страшно. Какие еще супер "гениальные" идеи воплощены в этом изделии которое явно застряло на уровне прошлого века стоит только догадываться. А терять время на раскопки и замены на ассемблер пасхальных яиц дяди Боба уже осточертело.

А в чем собственно проблема? Что не получается?
99,9% всех ошибок - это вина программиста.

Если кто пишет программы от которых зависят человеческие жизни, сделайте соответствующие выводы.

Я писал софт с использованием DLL библиотек на PB, работая в одном из НИЦов Минздрава РФ, пишу и сейчас работая в ГО МЧС России. Поводов усомнится в качестве PB - не было ни разу (версии до 8.04)
Тестированием готовых проектов занимается целый отдел сотрудников, это альфа, бета-тестирование, статическое, динамическое, регресионное тестирование, белый, черный ящик, покрытие кода, скрипты и ручное вплоть до проверки результатов пересчетом на калькуляторах. Ни одного бага, по вине компилятора - не было.

Если кто надумает переключаться, может начнем новую серию постов /PB2C/ ?

Не стоит, все таки это форум о PB

[jangle]

Как альтернатива:
http://www.tiflocomp.ru/docs/programming/fbc.php
http://ru.wikipedia.org/wiki/FreeBasic
IDE:
http://www.assembler.ca/radasm/fbedit/index.html
Сайт разработчика:
http://www.freebasic.net
Текущая версия 0.18.2 Beta(2007-10-12)

Не советую, FreeBASIC, к сожалению, мёртворожденное дитя. Слишком много багов, и слишком низкая квалификация разработчиков этого продукта.
Насчет PureBASIC тоже самое, его кстати разрабатывает один человек, но прикидывается софтверной компанией.

[PBDN]

А в чем собственно проблема? Что не получается?
99,9% всех ошибок - это вина программиста.

Эт мы знаем. Только в данном случае выплыл тот самый 0.1%

LOCAL n,f AS DWORD

n = &h8fffffff???
f = n * n * 2

? "ПБ результат = 0х"+HEX$(f),,"Любой другой компилятор = 0хC0000002"

[jangle]

А в чем собственно проблема? Что не получается?
99,9% всех ошибок - это вина программиста.

Эт мы знаем. Только в данном случае выплыл тот самый 0.1%

LOCAL n,f AS DWORD

n = &h8fffffff???
f = n * n * 2

? "ПБ результат = 0х"+HEX$(f),,"Любой другой компилятор = 0хC0000002"

Мда.. Маразм крепчает... Начинаем учить арифметику за 5 класс.

&h8fffffff в десятичном исчислении это 2415919103

Соответственно:

f = 2415919103 * 2415919103 * 2

Получаем:

f= 11673330224480649218

И это при том, что верхняя граница типа DWORD - 4294967295 !!!

Отсюда вывод, для такого большого числа нужен тип EXT - 1.2*10^4932

Изменяем код:

Код: Выделить всё

#Compile Exe
#Dim All

Function PBMain () As Long
    Local n As Ext
    Local f As Ext
n = &h8fffffff
f = n * n * 2
? "ПБ результат = 0х"+Hex$(f),,"Любой другой компилятор = 0хC0000002"
End Function

И получаем искомый результат: 0хC0000002

Как видишь, это все тот же 99,9% ошибок программиста

[Dark Machine]

),,"Любой другой компилятор = 0хC0000002

Какой компиль?
Если проверял на другом языке програмирования, то полный исходник именно этого кусочка кода (не весь RC6) плиз.

Надоб пощупать ...

[Dark Machine]

Кстати, PureBASIC это не настоящий компилятор. Он переводит исходный код на ассемблер FASM - т.е. он конвертер Басик-Фасм, только все спрятано.

[keks-n]

Код: Выделить всё

Sub main()
Dim f As Variant, n As Variant
n = CDec(&H8FFFFFFF)
f = n * n * 2
Debug.Print f

End Sub


На выходе 7061644223233130498, которое Hex$ не переваривает.

[PBDN]

Мда.. Маразм крепчает... Начинаем учить арифметику за 5 класс.

Jangle, у вас с Бобом явно одинаковый подход к проблеме.
Так что скорее всего маразам у вас обоих

f = 2415919103 * 2415919103 * 2

Получаем:

f= 11673330224480649218

И каким же таким образом интересно Вы господа вмещаете в ДВОРД
размером в 4294967295 такие крупненькие числа ?
Ну с Бобом вообщем то все понятно, он на время калькуляции без спроса переводит в QUAD считает а потом конвертит назад.

Отсюда вывод, для такого большого числа нужен тип EXT - 1.2*10^4932

Jangle, условие задачи ясно ? Мне нужно производить математические операции с типом ДВОРД. А о наличие EXT я и сам знаю.

Изменяем код:

Не, менять мы ничего не будем, потому как мне нужны математические операции именно с 4-х байтовым типом ДВОРД. И если вы когда нибудь пользовались компиляторами С , Дельфи, Ява... впрочем любой нормальный компилятор, то все они возвращают результат операции как и положено. Если не пользовались, то включите хотя бы виндовый калькулятор, переключите в "научный" вид, дальше переключите в HEX и самое главное не забудьте нажать кнопочку DWORD, а потом произвести те же самые операции.

Ну так и у кого маразм ?
Кстати советую почитать про эллиптические функции, геометрические прогресии применяемые в глубочайших циклах специально используя эффект переполнения регистров в специализированных расчетах. Эт вам с Бобом не 5 класс

Как видишь, это все тот же 99,9% ошибок программиста

Угу согласен, только программиста который написал компилятор.

Кстати чудо компилятор может делать и впрямь чудеса, стоит поменять без знаковый ДВОРД на ЛОНГ и все начинает считать как принято во всем мире.

Как прокомментируем подобные чудеса ?

[PBDN]

Какой компиль?
Если проверял на другом языке програмирования, то полный исходник именно этого кусочка кода (не весь RC6) плиз.

во всех диалектах С:
unsigned long a=0x8fffffffUL;
unsigned long b;

b = a*a*2


Жаба:
int a,b;
a=0x8fffffff;
b = a*((a << 1)+1);

[jangle]

Как прокомментируем подобные чудеса ?

PBDN прочитай мой предущий пост. Медленно... Вдумчиво.. Пытаясь осознать прочитанное. Можно три раза.

Затем попытайся ответить для себя, почему код:

LOCAL n AS DWORD
LOCAL f AS DWORD

n = &h8fffffff???
f = n * n * 2

Приводит к неправильному результату.

P.S Красным цветом указаны подсказки

[PBDN]

PBDN прочитай мой предущий пост. Медленно... Вдумчиво.. Пытаясь осознать прочитанное. Можно три раза.

Аналогично. Медлено и вдумчиво... можно десять раз:
w= &hFFFFFFFF???
w=w + 1 = 0
w= w +1 =1
w= w +1 =2
...
как дойдем до FFFFFFFF
начинаем сначала.
Теперь как вы говорите, вспоминаем математику за 5 класс
2*2 = 2+2=4

и начинаем понимать почему во всем мире при операциях умножения работают те же самые правила что и с сложением.
дошли до максимально допустимой разрядной сетки , сбросились в ноль и поехали сначала.
Это конечно очень тяжело понять, если долго умножать яблоки на коробки и коробки в машине на машины.

Затем попытайся ответить для себя, почему код:

Jangle, Вы мне очень напоминаете своими манерами одного господина Мишу Матиаса, который тоже не втыкает по теме, но пытается говорить очень умные слова. Или Вы так же как и Боб считаете что все остальные компиляторы дерьмо, и только один ПБ самый прецизионный компиль во всем мире, который затыкается на нуле если в глубоком цикле прогонять подобные формулы.

P.S.
Кстати, на виндозном калькуляторе проверили свою теорию перед тем умничать?

[jangle]

Эх- Гвозди бы делать из этих людей, крепче бы не было в мире гвоздей!

PBDN - а кто собственно обещал, что при переполнении разрядной сетки формата числа, ты получишь Overflow? Боб обещал? Нет совсем наоборот, это даже в хелпе описано:

In order to generate tight, fast code, we have eliminated quite a bit of error checking that was done in earlier compilers (such as Division-by-Zero, Numeric Overflow, and most other numeric checking errors). While this results in code that is considerably smaller and faster than any other Windows compiler product, it does put more of an onus on the programmer to write code that is bug-free, or code that does its own error checking and validation of its data.
For example, an application that performs exponentiation of a negative value to a fractional power (-5^1.9) will not trigger a run-time error, but the result of the expression will be undefined. Therefore, it makes sense for the application to make some attempt to validate or restrict the numeric range of the arguments of this kind of expression.

Контроль, за возможным переполнением, возложен на плечи программиста. Отчасти из-за этого, скорость математических расчетов на PB значительно выше, чем у VB6. Просто нет лишних проверок.
Если она тебе нужна, ты сам ее добавишь в ущерб скорости работы кода.
Описаная тобой ситуация - секрет Плишинеля, уже много раз отпедалированная на официальном форуме PB.

[Dingo]

Положа руку на сердце был удивлён результату <> C0000002h, однако фраза из приведённой jangle цитаты "For example, an application that performs exponentiation of a negative value to a fractional power (-5^1.9) will not trigger a run-time error, but the result of the expression will be undefined." сразила наповал!
Фирма формально права (она не обещает младшей части от результата, как было бы логично ожидать), но по сути поведение компилятора как минимум(!) "обманывает" ожидания. т.ч. негодование PBDN я прекрасно понимаю.

Кроме того, лично меня бесит нескончаемость "DIM N AS BYTE: FOR N = 0 TO 255: PRINT N;: NEXT N", которая аналогичным образом оправдывается в мануале, и невозможность отрицательного инкремента со STEP для DWORD.
Да и упёртость фирмы в своей правоте (http://www.powerbasic.com/support/pbfor ... hp?t=35387) тоже раздражает.
Могли бы пойти на мировую и включить в список пожеланий следующего релиза что ли... Хочу надеяться!

Печально всё это.

P.S. Такой вариант как:
LOCAL n,f AS DWORD
n = &h8fffffff???
'f = n * n * 2
f = n * n
f = f * 2
? Hex$(f)
конечно же даст ожидаемое C0000002h, хотя последовательность мат.операций та же. Но кого волнует математика, если важнее производительность...

[PBDN]

Эх- Гвозди бы делать из этих людей, крепче бы не было в мире гвоздей!

Н-да... у меня б в разделе на сырцах Вы б за маразм и гвозди схлопотали от меня банку Хотя последнее время привык, что на русских форумах без перехода на подначки просто не могут жить.

PBDN - а кто собственно обещал,

Общепринятые законы математики во всем мире обещали.

что при переполнении разрядной сетки формата числа, ты получишь Overflow? Боб обещал? Нет совсем наоборот, это даже в хелпе описано:

Никто не использует Overflow в операциях с целыми числами.
Переполнения не должно возникать, просто нет тормозов между нижним и верхним допустимым значением разрядности переменной целого типа. Вышел результат за допустимые пределы , - просто берется лоу ордер результата операции и возвращается.

In order to generate tight, fast code, we have eliminated quite a bit of error checking that was done in earlier compilers (such as Division-by-Zero, Numeric Overflow, and most other numeric checking errors).
...
...

Расчудесная документация ! Только почему тогда это выполняется для ДВОРД но стоит поменять на ЛОНГ и мы тогда вместе со всем миром, или другой тип переменной как БАЙТ, там тоже все Ок. Не наводит не на какие мысли ?

Контроль, за возможным переполнением, возложен на плечи программиста.

Чего, чего ???
Jungle, нет в операциях с целыми числами переполнений !
есть ролаут от 0 до максимума и опять сначала.

mov eax, &h8fffffff???
mov ebx, 2
mul ebx
mov ebx, &h8fffffff???
mul ebx

вот так это работает во всем мире. Если операция проводится с типом ДВОРД, то все промежуточные результаты тоже проводятся только с типом ДВОРД. Результат полного 64 битого значения (с учетом hi order EDX )не принимается во внимание, потому что изначально затребован тип переменной размером в ДВОРД.

Отчасти из-за этого, скорость математических расчетов на PB значительно выше, чем у VB6. Просто нет лишних проверок.

Здесь я пасс, т.к. за всю жизнь написал только две программы на ВБ, одна из которых Хелло Ворлд, а вторая перелопачивавшая данные с одного хитрого станка ЧПУ. Но этих двух программ мне хватило чтобы понять ограниченность языка (Только давайте не будем разводить холивары еще и на эту тему. Это просто мое мнение и все.)
а по поводу "Просто нет лишних проверок." это точно, так как кто в ПБ просто жить не может без сопроцессора и любую задачу пытаются свалить на него.

Если она тебе нужна, ты сам ее добавишь в ущерб скорости работы кода.

Еще раз, в операциях с целыми числами нет проверки на переполнение... по крайней мере на любом математическом инструментарии в мире.

Описаная тобой ситуация - секрет Плишинеля, уже много раз отпедалированная на официальном форуме PB.

А можно это на русский перевести, вообще не догнал.

[PBDN]

Фирма формально права (она не обещает младшей части от результата, как было бы логично ожидать), но по сути поведение компилятора как минимум(!) "обманывает" ожидания. т.ч. негодование PBDN я прекрасно понимаю.

Спасибо, только негодование, это очень мягко.

Кроме того, лично меня бесит нескончаемость "DIM N AS BYTE: FOR N = 0 TO 255: PRINT N;: NEXT N",

А как на счет того что разрешать обьявлять глобальные переменные внутри функций и субов ? Когда в "менее точном" С++ применяется обьявление таких переменных только в теле программы, за пределами любых функций и подпрограмм что соответствует логике их названия и области применения - глобальные.

Или если для всех понятная математическая запись
А=Б=С=5 обозначает что значение 5 присваивается всем трем переменным А,Б,С.

Однако в ПБ есть на это свое понимание
Это сравнение "С" с 5 и возврат в Б ложь или правду результата сравнения , тоже самое по цепочке с "Б", "С" и"А".... суппер фича ...блин
хотя используемый для этого во всем мире IIF& в одном случае может вернуть правильное значение а в зависимости от звезд в сопроцессоре совершенно другое, хотя у них на это тоже есть отмазка используйте сверх тормозной IIF или CDWD
Хотите попросить чтоб переделали ? Не теряйте времени, ответ будет мы не можем себе позволить разбить код у покупателей изза изменения поведения. Интересно только, кто это любит сравнивать таким способом? Хотя в тоже время при переходе в мажорных версиях можно запросто пренебречь своим же правилом.

Да и упёртость фирмы в своей правоте

Это уже легендарность и многолетние лицо фирмы.

(http://www.powerbasic.com/support/pbfor ... hp?t=35387)

Это просто намек на то что Рон Ривест - известный криптолог во всем мире вроде как не дурак использующий в своих алгоритмах формулы подобные приведенным выше.
А начало здесь:
http://www.powerbasic.com/support/pbfor ... hp?t=35375
и продолжение тут
http://www.powerbasic.com/support/pbfor ... hp?t=35407

Зная Боба, удивляюсь только почему до сих пор темы не исчезли.

Могли бы пойти на мировую и включить в список пожеланий следующего релиза что ли... Хочу надеяться!

Если разум восторжествует, то сделают как всегда втихую.
Много БагФиксов в последнем релизе видели?
Что вы ?! Они же самые лучшие, им даже С++ в подметки не годится.

Печально всё это.

Очень, Очень мягко говоря - Не то слово. Компилер то действительно классный. Но окружив себя забором уникальности отрезали себя от остального мира. Сколько им Семен не долбил что юникод не просто два байта с нулями впереди, а может еще начинаться и с 04(для русских) толку - ноль.

P.S. Такой вариант как:
LOCAL n,f AS DWORD
n = &h8fffffff???
'f = n * n * 2
f = n * n
f = f * 2
? Hex$(f)

Во ! Еще одно доказательство. Спасибо.

Но кого волнует математика, если важнее производительность...

Да какая нафиг скорость, если они подсовывают сопроцессору конвертированное в QWORD значение на время выполнения с их точки зрения "наиточнейших" вычислений и обращаются к памяти уже не как к 4 байтовой переменной а как к 8 байтной.

[jangle]

Эх- Гвозди бы делать из этих людей, крепче бы не было в мире гвоздей!

Да ладно, зачем на шутки обижаться!

[jangle]

Печально всё это.

P.S. Такой вариант как:
LOCAL n,f AS DWORD
n = &h8fffffff???
'f = n * n * 2
f = n * n
f = f * 2
? Hex$(f)
конечно же даст ожидаемое C0000002h, хотя последовательность мат.операций та же. Но кого волнует математика, если важнее производительность...

А вот и совсем не так. При f = n * n * 2 сопроцессор поднимает флаг исключения, а при f = n * n: f = f * 2 - нет!

Небольшой пример:

Код: Выделить всё

#Compile Exe
#Dim All

Function GetFPU_Status As Long
    Local  Fpu As Dword
    ! mov   eax, 0
    ! fstsw ax
    ! mov  Fpu, eax
    ! fclex
    ! cmp  Fpu, 1
    ! je   FpuMsgOut
    Exit Function
    FpuMsgOut:
    GetFPU_Status=1
End Function


Function PBMain () As Long
   
Local n,f As Dword
n = &h8fffffff???
f = n * n * 2

If GetFPU_Status Then
   MsgBox "FPU выбросил исключение на (f = n * n * 2) !"
End If

f = n * n: f = f * 2

If GetFPU_Status Then
   MsgBox "FPU выбросил исключение на (f = n * n: f = f * 2) "
End If


End Function

Наверное соглашусь с Бобом, не надо допускать переполнения разрядной сетки формата числа. Или, в противном случае, все-же проверять состояние флагов FPU после "опасных операций c переполнением"

[jangle]

Прямо по нашей теме статья с WASM`а:

Перенос и переполнение - что они представляют собой на самом деле?

http://www.wasm.ru/print.php?article=carry_overflow

А там любопытный фрагмент, неужели правда? Или все таки врут?

Сложение БЕЗЗНАКОВЫХ чисел при возникновении переноса протекает неправильно (ТОЛЬКО из-за переноса из разрядной сетки - перенос в знаковый разряд роли не играет). При интерпретации слагаемых как беззнаковых чисел перенос из разрядной сетки приводит к потере старших разрядов числа, и результат оказывается неверным.

[Dingo]

jangle,
угу, ток зачем при умножении DWORDов FPU вообще задействовать? Почему бы не старый добрый mul ? Ведь в случае LONGов это через imul происходит...
Очень допускаю то, что я чего то и не знаю (что чаще всего и бывает ), однако всегда думал, что целочисленные мат.действия быстрее выполняются не на FPU (потому что это Processing Unit для Float), а командами из основного набора. А в данном случае тут вопрос стоит даже просто о правильности.
Или же перед разработчиками компилятора стояла какая то неочевидная для нас неразрешимая проблема беззнаковых целых? Сомнительно оно, но факт на лицо: извращеная реализация DWORD-вычислений через числа с плавающей точкой, и фирму это устраивает.

P.S. оставив эмоции в стороне для себя решил по возможности избегать типа DWORD, а все финты с переносами/переполнениями (если когда потребуется) делать asm-вставками.

[PBDN]

Да ладно, зачем на шутки обижаться!

Сань, какие нафиг обиды Просто когда разговор заходит о серьезных вещах, подобные шутки
могут очень легко утянуть разговор от темы. Ничего больше и никаких обид.

Наверное соглашусь с Бобом, не надо допускать переполнения разрядной сетки формата числа.
Или, в противном случае, все-же проверять состояние флагов FPU после "опасных операций c
переполнением"

Страно, но у нас беседа протекает практически в том же русле что и на ПБ форуме.
Можно согласится с Бобом, или еще с кем нибудь,
НО, - это не значит что весь остальной мир согласится с нами. Есть общепризнанные
правила при работе с челыми числами фиксированного размера. И игнорирование этих правил
правил приводит к несовместимости со всем остальным миром.

По поводу примера: Дело в том что сопроцессор работает немного по другому.
Качаем толмут опкодов из первоисточника

Instruction Set Reference, A-M:
http://www.intel.com/design/processor/m ... 253666.pdf

Instruction Set Reference, N-Z:
http://www.intel.com/design/processor/m ... 253667.pdf

Отыскиваем там команды FPU для FADD/FADDP/FIADD и FMUL/FMULP/FIMUL
и смотрим таблицу как FPU поступает при переполнении.
Остановимся на вставшем поперек глотки целочисленном умножении, т.е.
операции FIMUL. Читаем:
"The FIMUL instructions convert an integer source operand to double extended-precision
floating-point format before performing the multiplication."

И далее смотрим таблицу 3-34
Вот и весь секрет.

Учитывая что Боб в дополнение ко всему самовольно меняет тип операнда от заказанного ДВОРД на КУАД
на время выполнения формулы, получается непредсказуемый результат, хотя следуя таблице 3-34
получаем то что и должно быть , т.е. - Ноль в случае переполнения вместо ролаута как принято во всем мире.

Прямо по нашей теме статья с WASM`а:
Перенос и переполнение - что они представляют собой на самом деле?
http://www.wasm.ru/print.php?article=carry_overflow
А там любопытный фрагмент, неужели правда? Или все таки врут?

Дальше этого

;// 253 + 5 = 2 (неверно)
; ИЛИ -3 + 5 = 2 (верно)

читать не стал, т.к. автор статьи глубоко заблуждается,
о чем есть подтверждение моих слов в конце статьи, а именно добавление от редакции:

Такое преобразование над числом так же называется дополнением до двух.
А само представление отрицательных чисел - дополнительным кодом. (прим. ред.)

Дело в том что в микропроцессорах используются Zero-based числа. Число 0(ноль) имеет точно такой
же вес как 1, 2 и прочие числа. Поэтому утверждение что 253 + 5 = 2 (неверно) есть неверно в принципе.
если максимальная разрядность операнда есть байт (0-255[0-FF]] то

Код: Выделить всё

253+1 = 254 (1)
254+1 = 255 (2)
255+1 = 0   (3) <-переполнение и сброс. Но адрес=ноль, это не пустошь, а реальное указание на что-то.
0 + 1 = 1   (4)
1 + 1 = 2   (5)


поэтому 253+5=2 с байтовой переменной это очень даже верно, что можно проверить на любом
компиляторе,CPU или микроконтроллере.

А вот игнорирование этих правил приводит к очень даже плохим последствиям.


P.S.
форум видимо очень перегружен, или защита от спама(скорее всего второе, сайт пингуется с 158мс),
страницы грузятся по 2-3 минуты или вообще подвисают.
Так что если быстро не смогу отвечать, то -сорри.

[Хакер]

"Не использовать freeware или shareware программы и компиляторы".

А какие тогда остаются? Donateware?

Насчет PureBASIC тоже самое, его кстати разрабатывает один человек, но прикидывается софтверной компанией.

Это, что, плохо?

[PBDN]

А какие тогда остаются? Donateware?

Остаются коммерческие, лицензионные.

[Dark Machine]

При компиляции с использованием #REGISTER NONE результирующий код не использует FPU, а используется операнд mul.

Написал на С и откомпилировал, посмотрев на ассемблерный листинг увидел, что умножение на 2 происходит через операнд shl eax,1.
А ПБ использует операнд mul.

Теперь компилируем на ПБ вот этот вариант:
f = n * n
f = f * 2
.. и получаем правильный результат.
Все очень интересно.
В этом случае ПБ использует операнд shl вместо mul ! И все верно. Ведь переменные целочисленные и вторая строка как раз интерпретируется как shl eax, 1.

Нетрудно догадаться, что собака зарылась в парсере математических выражений.

[jangle]

Мда, просто скандал в благородном семействе!

http://www.powerbasic.com/support/pbfor ... hp?t=35407

And the last one, I don’t trust anymore to PowerBasic compiler, because mathematic rules may be broken somewhere else inside PB engine. I don’t want spend hours to track down errors, which is appear by not my fault.
I don’t want go to a jail, if in some day my program will drive external equipment (which can be electric power station, medical equipment…) in a wrong way, and will hurt people’s lives.
I don’t want to see MCM face, when in some day IRS will found incorrect calculation in his PaymentProviderParther.
I don’t want looks stupid, when I will need explain to a customers why do I need use signed integer, when I need DWORD.
And I don’t want loose my reputation and my money just because someone forgets the math rules.

[jangle]

Кстати, кто предложит методы разрешения обсуждаемой ситуации?
Видимо, надо просто написать свои мат. функции для работы с DWORD с учетом сабжа