методы отлова ошибок из VB6 to PWB

[spamjokester]

Я программирую в VB60. И у меня сложилась своя система отлова ошибок. В частности не использую встроенные отладочные функции (точки останова и. т.д). Чаще всего, предполагаю ошибку, вставляю оператор STOP или IF ...STOP,и подвожу курсор к нужной переменной для определения ее значения и.т.д.
Как можно в PWBASIC это делать. Например, останов,вывод информации и завершение программы.
Т.е пример-код.
Спасибо.

[jangle]

Я программирую в VB60. И у меня сложилась своя система отлова ошибок. В частности не использую встроенные отладочные функции (точки останова и. т.д). Чаще всего, предполагаю ошибку, вставляю оператор STOP или IF ...STOP,и подвожу курсор к нужной переменной для определения ее значения и.т.д.
Как можно в PWBASIC это делать. Например, останов,вывод информации и завершение программы.
Т.е пример-код.
Спасибо.

Используй отладчик, PB в отличие от VB, компилятор. Поэтому никаких STOP здесь быть не может.

[spamjokester]

Я не пользуюсь отладчиками. STOP сильно и не нужен. Ну а вывод информации и завершение программы ?
А возможно,в PWBASIC включить отладку OVERFLOW,так,чтобы можно проверить программу в этом режиме.
Или же проверка такого рода ошибок возлагается на пользователя.

Также интересно, обнаружил такую заморочку в режиме #DEBUG ERROR ON

global x_ptr as integer ptr
dim x (129 to 145) as global: x_ptr=VARPTR(x(0))
x(129)=1
msgbox str$(@x_ptr[129])
Если человек адаптирует свою программу из VB60,и привык к массивам не с 0,
то это конечно не приятно,поскольку без режима #DEBUG ERROR ON все работает,
но при включении получается белиберда. Поскольку указатели начинают обращаться не туда,
и программа завершится аварийно. В режиме #DEBUG ERROR ON,работает правильно,если
массив объявляется с 0 dim x(0 to 145).
Т.е. Если я правильно понял, в этом случае придется временно объявлять все массивы с 0 ?
Все это немного раздражает,поскольку какой только информации в HELP нет,а то что нужно того нет.
Неужели нельзя, предусмотреть авторам,c чем может столкнуться пользователь при адаптации программы с VB60

[FireFenix]

Неужели нельзя, предусмотреть авторам,c чем может столкнуться пользователь при адаптации программы с VB60

Почему автора должны что-то придумывать для совместимости с другими продуктами, не являющимися их собственностью?
И почему перед переходом на другой язык, пользователь не ознакамливается с документацией нового языка, а делает как ему хочется?

[spamjokester]

FireFenix
(Почему автора должны что-то придумывать для совместимости с другими продуктами)
Дело в том,что PWB это BASIC. Переход с VB60 как раз в HELP уделено особое внимание.
Только,в документации я лично не видел таких разделов,где это предупреждалось, предусматривалось.
А ведь это можно было продумать,а то приходится догадываться.
Но меня интересует больше отладка а не эта тема.

[Qwertiy]

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

global x_ptr as integer ptr
dim x (129 to 145) as global: x_ptr=VARPTR(x(0))
x(129)=1
msgbox str$(@x_ptr[129])

А взять адрес начального элемента и вычесть из него соответствующее число байт - не вариант?

[spamjokester]

Тут основная не приятность в том,что человек,после подключения отладки,может подумать, что в программе какие то ошибки,и причину можно искать долго.
Я уже сказал,можно сделать массивы,которые >0 в ноль,те что <0 не нужно.
Обращение к массивам в этом режиме не имеет не каких проблем,ничего не надо вычислять.
Речь идет о указателях на массивы с начальным индексом >0. Просто получается (как я понимаю) адрес не того участка памяти.

[jangle]

global x_ptr as integer ptr
dim x (129 to 145) as global: x_ptr=VARPTR(x(0))
x(129)=1
msgbox str$(@x_ptr[129])

Этож сколько надо выкурить, чтобы такое написать?

[spamjokester]

Какое именно )). Это просто тест в режиме #DEBURG ERROR ON

#COMPILE EXE
#DIM ALL
'#DEBUG ERROR ON
GLOBAL x_ptr AS INTEGER PTR
FUNCTION PBMAIN () AS LONG

DIM x(129 TO 145) AS GLOBAL INTEGER:x_ptr=VARPTR(x(0))
MSGBOX STR$(@x_ptr[129])

END FUNCTION
=0
Без режима=1

[spamjokester]

x(129)=1 забыл.

[jangle]

Какое именно

Твой первый код я имел ввиду.

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

dim x (129 to 145) as global 

- это что за тип такой global ?
И далее по-коду почему обращаешься за границы объявленного массива?

[jangle]

Какое именно )). Это просто тест в режиме #DEBURG ERROR ON

#COMPILE EXE
#DIM ALL
'#DEBUG ERROR ON
GLOBAL x_ptr AS INTEGER PTR
FUNCTION PBMAIN () AS LONG

DIM x(129 TO 145) AS GLOBAL INTEGER:x_ptr=VARPTR(x(0))
MSGBOX STR$(@x_ptr[129])

END FUNCTION
=0
Без режима=1

Почему

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

x_ptr=VARPTR(x(0))

, а не

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

x_ptr=VARPTR(x(-10000))

или

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

x_ptr=VARPTR(x(32768))

?

Было бы намного круче!
Все таки рекомендую купить и прочитать книгу по-программированию для начинающих.

[spamjokester]

Ну так,адаптация с Public (VB60). Конечно не тип,просто думал,что смысл в сути а не как записано.
Я просто так всегда,integer понятно.
Пока,пытаюсь свой код адаптировать с минимальными изменениями. в зависимости,что показывают тесты.
Тест показывает, что одномерные указатели на массив с индексом >0,могут работать (DEBUG=OFF).
Если в смысле x_ptr=VARPTR(x(129)) ?
x(129)=1
Индексы не совпадают, работает @x_ptr[0],@x_ptr[1].
Но у меня,огромное число массивов-указателей,мне надо совпадение,никакое смещение и.т.д. не подходит,это накладно.

[spamjokester]

Я же уже писал. Что пишу DLL для VB60. Там в HELP,указано,что массивы надо передавать для указателей с 0,x(0),x(0,0).
И они все работают без DEBURG,потому что DLL c указателями или работает или НЕТ. Отсюда и я привык 0.
Поэтому и пушу, с чем можно столкнуться с точки зрения...

[jangle]

spamjokester - надеюсь ты понимаешь, что обращение за границы продекларированного массива это ошибка?
То что компилятор не стучит тебе по-голову объясняется тем, что проверка выхода за границы слишком накладна, и применяется она только в простейших языках для начинающих типа VB.

[spamjokester]

При обращении указателей к не верному адресу,программа завершится в скором времени. А она показывает правильное значение.
Может,это исключение,и она знает куда обращаться.))

[jangle]

При обращении указателей к не верному адресу,программа завершится в скором времени. А она показывает правильное значение.
Может,это исключение,и она знает куда обращаться.))

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

[spamjokester]

Меня бы, больше интересовали способы выявления ошибок в PWB.). Вот адаптирую большую программу. Но приходится изменять некоторые участки.
А значит не исключена ошибка OVERFLOW, значением для вычислений может стать какой то 'мусор'. И его трудно искать.
Неужели PWB не дает возможность 'проверки такого режима'. Или дает ?

[jangle]

А значит не исключена ошибка OVERFLOW, значением для вычислений может стать какой то 'мусор'. И его трудно искать. Неужели PWB не дает возможность 'проверки такого режима'. Или дает ?

Не дает, впрочем как и любой другой компилятор.

Note: PowerBASIC does not trap numeric overflow or underflow errors in equation and expression evaluation.

[Хакер]

применяется она только в простейших языках для начинающих типа VB.

Jangle, прекрати писать хрень.

[jangle]

применяется она только в простейших языках для начинающих типа VB.

Jangle, прекрати писать хрень.

В чем хрень?

[Хакер]

Во всём. В том, что указанное применяется только в простейших языках (это неправда). В том, что VB является простейшим языком. В том, что VB является языком для начинающих.

[jangle]

Во всём. В том, что указанное применяется только в простейших языках (это неправда). В том, что VB является простейшим языком. В том, что VB является языком для начинающих.

Ну тогда скажем в высокопроизводительных языках, Java не простой и запутанный, но все равно медленный интерпретатор.
Есть единственный стандарт языков в программировании это С/С++, а там проверки границ массива нет.

[Хакер]

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

[jangle]

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

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

[iGrok]

Они там не нужны. Профессиональному программисту проверка границы массива только мешает.

Надеюсь, у тебя есть письмо от Страуструпа с его личной подписью, где он тебе об этом сообщил?

Есть единственный стандарт языков в программировании это С/С++

Толсто. Очень.

[jangle]

Толсто. Очень.

Что толсто?

[iGrok]

Троллишь толсто.

[jangle]

Троллишь толсто.

Это ты троллишь. Причем глупо. MS VС++ единственный возможный инструмент для профессиональной разработки в настоящее время.
Например в моей организации используется VS2008. Скажи чем заменить тут C++ если контора создает КИС и тренажеры содержащие 2D/3D графику?
При этом приходится работать с OpenGL и Direct3D, с шейдерами Cg/HLSL/GLSL, использовать 3DS MAX SDK, юзать STL и boost и просто asm, в добавок кучу тулз типа VTune или AMD Codeanalyst. Какой инструмент можно использовать кроме MSVC++?

[Qwertiy]

применяется она только в простейших языках для начинающих типа VB.

А Java, C# и VB.NET - тоже "простейшие языки для начинающих"?

Профессиональному программисту проверка границы массива только мешает.

Убеди-ка в этом Microsoft

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

И что же в нём неправильного?