Если так все пойдет и дальше

im1111
> Главное то что прога должна иметь простоту локализации
> и все "вражеские" тексты кладутся в .ini.
просто тут кто-то говорил, что в VS есть редактор ресурсов.
ну, во-первых, редактор он так себе... для начинающих, да
и глючный страшно, часто приходится лазить и руками править
в то, что он там наредактировал. но! тезис тут такой, что рисовать
статические элементы и сразу выводить в них надписи нельзя
(т.к. текст меняется от языковых настроек), оставлять пустым
чтобы вывести на лету - можно, но... что произойдет если текст
не влезет в элемент?! как ни крути, а нужно создавать элементы
динамически, определяя их размер с учетом длины текстовой строки...

> А есть плагин для FAR с логикой как у intellisence?
это (и многое другое) делает colorer. по скобки/кавычки
подсвечивает (очень удобно сразу видеть блок, который
относится к данным скобкам), по скобкам прыгает...

> "Go To Definition/Declaration"?
тоже есть такое, только не помню в colorer'е или другом плагине...
навигация по функциям/классам там тоже есть...

> Если такой плагин есть то можно и на FAR перейти
попробуй! не пожалеешь!!!

 

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

 

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

 

Nouzui
я говорил, что интерактивные отладчики развращают.
а отладочные средства (типа отладочного вывода, например)
зачастую являются единственным возможным средством
понять, почему программа работает не так, как предполагалось.
ладно, время "секса с резидентами" в MS-DOS уже прошло,
зато сейчам мы имеем грабли с багами синхронизациями,
особенно коварными на многоядерных процессорах,
которые под отладчиком могут вообще не наблюдаться.

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

im1111
надо будет обсудить эту тему с редактором. посмотрим,
что он скажет....

 

А vim???? Подсветка синтаксиса, неограниченые возможности редактирования исходного кода(colorer'y далеко до него)

 

kaspersky
в общем, я уже развращен до крайности, и переубеждать меня бесполезно )

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

но вообще смысл не в этом
использование сплошных рантаймовых проверок, позволяющих находит ВСЕ ошибки по логам, не используя дополнительных отладочных вставок, просто невозможно
что же делать? добавлять отладочный код? сразу так, чтобы оставить его в релизе для поиска багов при сопровождении? а если не угадал, и этот код не помог? написать еще один, и тоже оставить? если именно так, то отладчик действительно не нужен.
ну хорошо, а если ты все-таки хочешь найти ошибку, и после убрать этот код из программы? во-первых, добавление такого кода изменяет саму программу, едва ли настолько, чтобы повлиять на логику, но все же, во-вторых, написанный код потом все равно придется удалять, а не проще ли было не писать? и в-третьих, его действительно нужно написать, то есть указать явно все переменные, которые ты хочешь посмотреть.. в каждой точке, в котрой тебе хочется узнать их значение, придется вставлять протоколирование в каждую из точек, последовательность выполнения котоых ты хочешь проверить.. а потом удалять или комментировать!
или не в каждую, а только в наиболее подозрительные, но тогда, как правило, придется запускать программу повторно по несколько раз, поскольку угадать сразу ты не сможешь..
конечно, есть и другая сторона медали - этот код можно оставить на будущее, а запретить его одним ловким движением макроса. бывает, что и пригодится, но в большинстве случаев.. понятно, что исправив какую-то незначительную локальную ошибку, возникшую по ходу разработки, ты к ней уже не вернешься, а код только останется мертвым грузом, затрудняя читабельность этого участка. короче, я таким никогда не занимался..
по поводу ошибок, для которых отладчик не предназначен.. тебе все равно придется искать их, и наличие отладчика никак этому не помешает. даже больше того: взять, к примеру, ту же синхронизацию. для того, чтобы начать искать свящанную с ней ошибку, нужно сперва выяснить, что именно синхронизация является причиной проблем. под отладчиком ошибка не проявляется? вот и отлично, сразу наталкивает на мысль..
или наоборот - под отладчиком програма вообще перестала нормально работать. повод задуматься..

одним словом, выбор среды разработки, равно каи методов отладки, является скорее делом вкуса и привычки, так что спорить об этом бессмысленно
лично мне - VS и дебаг ))

 

да забыл сказать Eclipse + MINGW + wxWidgets - оч неплохая связка для разработки офисных приложений =)

 

Nouzui
> понятно, что ран тайм проверки никто не отменял,
> и наличие отладчика этому никак мешает..
но делает отладчик во многих случаях ненужным...

> что значит "дописать десяток строк кода"?
> да их надо сразу написать, если хочешь,
"дописать" значит "добавить к программе"

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

> только честно скажу, так я не писал никогда - вставлять системный
> вызов перед изменением группы переменных, потом снова,
> чтобы закрыть эту область памяти.. по моему, это черезчур
А там будет флаг if (global_opt_debug) { }
причем это дело можно автоматизировать,
через макросы или функции-обертки вокруг malloc...
но это уже вопрос реализации

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

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

> добавлять отладочный код?
А вот этого точно не надо

> во-первых, добавление такого кода изменяет саму программу,
> едва ли настолько, чтобы повлиять на логику, но все же, во-вторых,
> написанный код потом все равно придется удалять,
вообще-то, во все мало-мальски сложные системы
(будь то железо или софт) принято включать механизмы
самодиагностики в том или ином виде, и оставлять их там навечно
или твои программы никогда не глючили у клиентов?!
ведь если клиент (и не один) жалуется, что у него что-то там падает,
а у тебя все работает нормально, то это уже умом поехать можно
пока ты разберешься. кстати, даже дампы памяти мало помогают.
ты что ли не сталкивался с ситуациями, когда инструкция XOR ECX,ECX
вызывает исключение доступа к памяти?! и чем тебе дамп поможет?!
а все просто... глюк кэша процессора, достаточно чтобы сбойнул один бит
и XOR ECX,ECX превращается в нечто совсем другое, а в момент снятия
дампа считается реальное содержимое памяти, где все ОК
в таких ситуациях спасает только интегрированный отладчик,
ну или... дампер службных регистров проца, по которым еще что-то
можно понять... вообще-то в идеале, я предпочитаю воевать с багами
удаленно, но далеко не всякий клиент позволит это сделать...

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

> под отладчиком ошибка не проявляется?
> вот и отлично, сразу наталкивает на мысль..
ни фига не наталкивает. под отладчиком много чего не проявляется...

> выбор среды разработки, равно каи методов отладки
> является скорее делом вкуса и привычки,
> так что спорить об этом бессмысленно
> лично мне - VS и дебаг ))
говорить о "вкусе" можно только тогда, когда ты перепробовал
(и не просто "вглянул", а поработал некоторое время) с кучей
сред разработки, после чего нашел свой идеал...
а так.. получается в стиле: я попробовал vs, он мне понравился,
и я послал остальные на фиг я тоже раньше был убежденным
привеженцем vs, пока более умные люди не наставили на путь
истинный. в результате - программировать я стал быстрее,
а ошибок совершать - меньше.

 

Хе. даже нечего сказать, все выразили свою точку зрения.

 

>а какой тогда?? олькой, что-ли, свои проги отлаживать?
хе, а я так часто делаю (язык - Це). )

 

ой, жуть.. ))
короче

ну ничего возразить не могу
действительно, по-настоящему ни в чем, кроме студии, я не работал
очень понравился SlickEdit - писал в нем прораммулину для загрузки с дискетки (непосредственно из BR), но студии он не заменит, а остальное по-настоящему не пробовал, только смотрел кое-что
да и вообще, опыта у меня намного меньше..
ну а как насчет тебя? сколько ты можешь перечислить сред, в которых ты реально работал? и почему ты в итоге пришел именно к фару (я правильно понял, файловый менеджер FAR + плагин colorer?). я вообще им не пользуюсь, мне тотал больше нравится!

ps: про отладку я больше не хочу - у меня уже волосы дыбом )) но несколько вещей просто хочу спросить:
1. ты реально, чтобы посмотреть, что получается на самом деле в переменной в каком-то месте, вставляшь протоколирование в лог, и оставляешь это навсегда?
2. ты же не оставляешь весь отладочный код работать в релизе? ты пользуешься общим флагом для разрешения вывода отладочной инфы (там же мегабайты будут!) или разрешаешь в участках кода по-отдельности?
3. что значит "снабдить ее простейшим трассировщиком"?
4. "ни фига не наталкивает. под отладчиком много чего не проявляется..." - а как ты диагностируешь причину ошибки? Я же не говорю, что все рантаймы нужно убрать. Вставляй сколько угодно проверок, чтобы выяснить причину, если отладчик этого не позволяет, но чем он мешает-то?

да, вот еще:
1.
по поводу "многие ошибки синхронизации "исчезают" в отладчике" - ты же не думаешь, что программы тестируются под отладкой? отладчиком пользуются, чтобы найти ошибку, а не чтобы поглядеть, работает код или нет!

2.

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


pps: про XOR ECX,ECX - это уже за пределами возможностей моего мышления ))

 

а она разве умеет отлаживать по исходнику? и как в ней переменные посмотреть?

 

Nouzui
Если есть pdb -- да.

 

censored
и локальные переменные тоже показывает?

я ей пользовался в основном для отладки чужих, а не своих программ ))
да и, честно говоря, мало пользовался
вопрос - зачем грузить ольку, подружать pdb, искать место, с которым ты работал, и только потом ставить бряк, если можно просто сразу поставить бряк в редакторе, и нажать run?

 

>и локальные переменные тоже показывает?
хрен там, сплошная епля со стеком %)
но забавно %)

>вопрос - зачем грузить ольку, подружать pdb, искать место, с которым ты работал, и
>только потом ставить бряк, если можно просто сразу поставить бряк в редакторе, и
>нажать run?
у меня она обычно сама вываливается с ошибкой обращения к памяти %)
(прога тоесть)

либо обычное дело:
__asm int 3;

 

короче, мне не понять (
толку от этого __asm int 3, если там сплошная .. со стеком? проще сразу начать вставлять отладочный код..

кстати, Крис, невнимательно прочитал:

а как же тогда надо??

 

Nouzui
> а она разве умеет отлаживать по исходнику?
> и как в ней переменные посмотреть?
ну а map файл на что?! а отлаживать последнее время
я стал чаще всего в иде... не потому что это удобнее,
а как-то... привычнее что-ли. и потом, если я сделал
пишу что-то *(*x++)-- или другую абракадабру с кучей
преобразований указателей от char* до int* и обратно,
то в сорцах вообще ошибки не видны

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

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

> и почему ты в итоге пришел именно к фару
> (я правильно понял, файловый менеджер FAR + плагин colorer?)
ты понял правильно. только там не один колорер,
а много всякого добра, но дело не в нем.
FAR - это именно IDE в чистом виде, в нем очень удобно
переходить от файла к файлу, тут же компилировать их
и отлаживать. а всякие фишки типа визуализаторов классов
лучше решать отдельными специализированными средстами,
хотя сам я ими не пользуюсь, но знаю, что их выбор широк и
велик, как и других утилит, без которых не обойтись...

> я вообще им не пользуюсь, мне тотал больше нравится!
а мне нравится консоль и консольные приложения,
у меня все консольное практически: браузер, редактор, ида, неро...
из неконсольного - ворд, лис, опера, бат и оутглюк.

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

> 2. ты же не оставляешь весь отладочный код работать в релизе?
отладочную информацию - конечно же нет,
отладочный код - конечно же да, более того,
многие функции имеют процедуру самотестирования,
набор эталонных данных и контрольный результат.
самотестирование включается если предыдущий
запуск программы завершился аварийно...
кстати говоря, самотестирование меня не раз выручало,
помогая обнаруживать разницу в реализации некоторых
"плавучих" команд на разных процах, да что там говорить!
достаточно сравнить действия push reg16 на amd и Inel

> ты пользуешься общим флагом для разрешения вывода отладочной инфы
> (там же мегабайты будут!) или разрешаешь в участках кода по-отдельности?
там кольцевой буфер, т.к. интересуют события перед падением,
размер кольцевого буфера задается опционально, флагов обычно
делаю несколько:
выводить все - адреса маш. команд, данные, содержимое регистров;
выводить только адреса условных переходов и вызовов функций

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

> а как ты диагностируешь причину ошибки?
смотря что за ошибка. очень сильно по разному.
методике поиска ошибок посвящена куча книг.
универсальных рецептов нет, увы.

> Вставляй сколько угодно проверок, чтобы выяснить причину,
> если отладчик этого не позволяет, но чем он мешает-то?
мешает тем, что заставляет меня работать с ним вручную
в интерактивном режиме. возьмем к примеру последунюю
дыры в openbsd, где не туда воткнули макрос M_DUP_PKTHDR.
ошибка типичная? типичая! только отладчиком вявить ее
ничуть не проще, чем простым просмотром исходных текстов.
кстати, с макросами на си большая проблема ;(
мне не известен ни один отладчик, который бы мог работать
с ними на уровне исходных текстов ;(

> по поводу "многие ошибки синхронизации "исчезают" в отладчике"
> ты же не думаешь, что программы тестируются под отладкой?
> отладчиком пользуются, чтобы найти ошибку,
> а не чтобы поглядеть, работает код или нет!
я хотел сказать, что под отладчиков в общем случае
программа ведет себя иначе, чем без него и иногда
это очень критично. рассмотрим простой пример.
программирование винта через I/O без пауз.
на медленном компе (типа виртуальной машины
все будет работать на ура, под отладчиком - тоже.
а вот при "живом" прогоне - ни хрена. значит, нам
нужны методики поиска ошибок без отладчика...

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

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

> про XOR ECX,ECX - это уже за пределами возможностей моего мышления ))
при глюках L1 code кэша, в нем оказывается уже не то,
что есть на самом деле и потому ЦП может выдвать очень
странные коды исключений, которые выглядят совершенно
бессмысленными...

 

мда.. разные уровни, разные подходы
я так просто не умею ))

зы: по поводу FAR'а
я когда то уже "написался" в Борланде, честно говоря, текстовый интерфейс меня совсем не прельшает
но это уже точно дело вкуса
а консоль уважаю.. правда, для записи в неро все-таки открываю гуи, а вот стереть диск можно и через nerocmd

 

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

 

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

некого опенсурсного примера на паблик не будет случаем?
(написать то и самому можно, но...)