информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetСтрашный баг в WindowsГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Это все от опыта зависит 16.01.03 22:11  Число просмотров: 1035
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> а на счет VC, не нравится он мне, интерфейс какой то не
> очень дружественный :)
Вон у vim-а вообще интерфеса нет, а люди которые знают в нем что либо, кроме :q! (я знаю: Shift - ZZ - в смысле подряд два Z с шифтом :-))) ) - ставят его в один ряд с IDE от билдеров и прочих визуал сей. Некоторые говорят, что на билдере легче интерфейсы создавать, а я так даже MFC не люблю - только plain С и DlgProc (к которому все-таки и сводятся все билдеровские извраты). Да, так отчасти сложнее в простых ситуациях, но в виду полного контроля над ситуацией гораздо безболезненней разруливаются ситации сложные (именно за это я люблю C)

Мои претензии к билдеру:
1) Уж очень тормознутый, как при компиляции, так и, например, в отображении (ну не помню как это в нем называется) прототипов функций, типов переменных и т.д. при наведении мыши, автодополнении членов класса и т.д.
2) Много извращений: в частности property - действительно можно было реализовать простой перегрузкой оператора = и конструкторов.
3) Сильно большой и почти всегда более тормознутый код.
4) Если уж де-факто (ну не написали в борланде своей ОС-и со своим GDI) есть например структура, представляющая ресурсы (в частности диалог) внутри самой ОС-и, то какого хранить эти ресурсы в текстовом виде, потом динамически строить эту структуру и отдавать ее системе. Особенно мне не нравится, то что синтаксис этого псевдоязыка для описания ресурсов явно паскалеподобный - ну не нравится он мне. Извините, если кого обижу, но на паскале имхо пишут те, кому лень или не по силам выучить цэ.
Не нравится потому, что это говорит о разработчиках борлянда.
5) Много граблей, непонятно откуда возникающих и отнимающих много времени. В частности один мой знакомый почти неделю искал багу в своей проге, и в конце концов нашел багу в стандартной библиотеке (это было давно и не с билдером, а с BCC 5.02).
А вот совсем недавний случай: была структурка:

if (ядреное_условие)
continue;

---

Этот самый continue выполнялся ВСЕГДА.
После того, как пару часов промучались меняя условие, вводя промежуточные переменные и отслеживая их в дебаггере, и в конце концов сведя код к:

if (false)
continue;

---

Просто для того, чтоб проверить кто из нас глючит; оказалось, что он - в этой конструкции всегда выполнялось continue. Двадцать раз перепроверяли, нет ли там лишней точки с запятой, удаляли полностью эти строки и перенабирали полностью. В общем-то понятно, что если бы так происходило всегда, вне зависимости от контекста, бага не дожила бы до 6-й версии, поэтому мы начали менять контекст. Сначала заменили continue на {continue;} - не помогло. Помогло следующее:


if (то_же_самое_ядреное_условие_взятое_из_CVS_а) {
int a = 3;
continue;
}

Елки-палки, но на это же ушло несколько часов. Нет, я предпочитаю знать, что происходит

ЗЫ: отписать баг репорт не смогли, так как не смогли написать тестовое повторение баги, а отсылать весь проект не хотелось - коммерческий все-таки.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach