O>> в 2х словах: напичкать примочками... и максимально абстрагироваться от их реализации...
ВВ>Мать моя, дык это ж дотнет!
Вот в последнем BuilderX-е борланд прямым текстом и говорит:
Хотите писать под win-ду — валите на dotnet. ;-c

Здравствуйте, S@ndro, Вы писали:

L>>А вот Visual C#.Net это совсем другое дело, это дествительно похоже на Дельфи. При L>>создании пользовательского интерфейса отличии не велики (правдо поддержка различнных L>>нововведений Windowsа типа GDI+ появляются у microsoft быстрее, странно L>>почему ). И с доступом к БД или созданием Web приложений VisualC#.Net явно на L>>высоте. Да и среда удобней.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте Lexus:

VD>Вопрос очень... нет, ОЧЕНЬ плохой.

Эх, золотые слова, это бы в статью оформить и на сайте вывесить

Здравствуйте, Offsider, Вы писали:

O>Вот та фраза котрую я ждал...

O>На самом деле... У билдера неплохая идея!!! но эту идею, разработчики, по-видимому, не смогли реализовать до конца (в плане, без ошибок)... Возможно, это вызвано громоздкостью идеи...

O>Кто, что думает по этому поводу?

Не могу не согласиться.
Более того: похоже, у Борланда это хроническое — с завидным упорством практически дословно переносить идеи из Паскаля/Delphi в С++ с весьма сомнительным результатом Вспомните TurboVision или ObjectWindows — C++ кальки с паскалевского кода всегда умудрялись проигрывать в размере и производительности кода, не говоря уже о диковатости pascal-style кода на C++ как такового. OWL в конце концов переписали на чистом C++ (причем, IMHO, по функциональности и "си-плюс-плюсности" OWL5 делала MFC на раз; впрочем, по надежности — увы! — нет), но тут-то как раз вылупился Билдер, и бедняжка пемерла.
Упорство дословного переноса паскалевских библиотек (хотя, ясное дело, в случае с Delphi/BCB все сложнее; скажем так, использование паскалевской идеологии при работе на С++) можно сравнить, наверное, только со стремлением Борланда реализовать многоплатформенные библиотеки/инструментарий: та же OWL для виндов и полуоси, VCL для виндов и линухов...
К сожалению, у меня также сложилось мнение о Борланде, как о поставщике весьма не плохих идей и весьма же ненадежных решений

Кто знает, будут ли новые версии Borland C++ Builder?

Здравствуйте, <Аноним>, Вы писали:

А>Кто знает, будут ли новые версии Borland C++ Builder?
Вроде будет. Вроде даже front end от EDG но мне кажется это им не поможет. У них back end хреновый ни оптимизировать толком не умеет ни даже банально без ошибок код сгенерить.
Вобщем репутация у этой конторы очень "подмоченая".
Если хотите компилятор с front end от EDG и качественным back end то вам прямая дорого за Интеловским компилятором. Хотя и VC++7.1 тоже очень хорошь.

Здравствуйте, WolfHound, Вы писали:

WH>Если хотите компилятор с front end от EDG и качественным back end то вам прямая дорого за Интеловским компилятором. Хотя и VC++7.1 тоже очень хорошь.

Слышал слули что "буржуи" нашим землякам этот компилер не продают.
Правда иль вымысел?
Читал на www.wasm.ru,
там из-за этого, даже на примере интеловского компилера проги ломать учат.

Здравствуйте, Lexus, Вы писали:

L>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>В книжках по Builder'у пишется, что некоторые вещи практически
L>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?
Мое мнение:
Ув. тов. Vlad2 и Ocelot во многом правы. Но с некоторыми моментами я не согласен. RAD позиционировались изначально как средства быстрого создания приложений. Быстрого создания программ, а не создания быстрых программ. И в области создания мелких (по целям, по размерам они отнюдь не мелкие) программ RAD'ы на высоте. Рекомендую создать окно на чистом АПИ и в Билдере любому начинающему для проверки.
Про оптимизацию хорошо сказал Зубков и есть неплохие статьи К.Касперски. Если человек знает, как работает оптимизирующий С-компилятор, он будет писать код, который отлично оптимизируется конкретным компилятором — раз, и 90% оптимизации достигается на уровне оптимизации алгоритма. Кому надо оставшиеся 10% — милости просим, асм нам всем поможет.
Доводы про компиляторы и скорость немного мимо, хотя это верные доводы. Вот почему: любая приличная среда разработки создает свои обертки вокруг относительно низкоуровневых АПИ. ЧТобы каждый раз не изобретать велосипед. Пример (несколько неудачный): VS обладает MFC и WTL, Борланд — VCL. Тк что разговор идет о наборе готовых решений (библиотек классов, etc.), поставляемых с конкретной средой. Получается, что мы сравниваем немного разные компиляторы: кроме стандарта ANSI борладновский компилятор еще кучу всего делает, чего компилятору от VC делать в жизни не придется.
Если говорить о редакторе кода и компиляторе, то возможно пользоваться другими редакторами и компиляторами и для Борланда. Правда, исчезнет сам смысл использования — пользоваться VCL будет достаточно затруднительно и пропадет средство визуального редактирования форм. Тут очень правильно сказали про "менталитет" — emacs+makefile затачивается под любой компилятор, но только кто из адептов данного пути возьмет компилятор от Билдера? Уж лучше тогда free command-line tools.
И в заключение — инструменты дома есть? Я надеюсь, в наборе не единственная отвертка и не единственный гаечный ключ.

Здравствуйте, glyph, Вы писали:

G> Про оптимизацию хорошо сказал Зубков и есть неплохие статьи К.Касперски. Если человек знает, как работает оптимизирующий С-компилятор, он будет писать код, который отлично оптимизируется конкретным компилятором — раз, и 90% оптимизации достигается на уровне оптимизации алгоритма. Кому надо оставшиеся 10% — милости просим, асм нам всем поможет.
Вот тут я не совсем согласен. Алгоритмические оптимизации это конешно основное. НО качество оптимизации С++ компилятора очень сильно влияет на производительность. Порой в разы.
А на счет асма то я не знаю людей которые могут писать на асме лучше чем генерирует код ителовский компилятор.

Здравствуйте, WolfHound, Вы писали:

WH>Вот тут я не совсем согласен. Алгоритмические оптимизации это конешно основное. НО качество оптимизации С++ компилятора очень сильно влияет на производительность. Порой в разы.
WH>А на счет асма то я не знаю людей которые могут писать на асме лучше чем генерирует код ителовский компилятор.
Есть и такие, однако оптимизация такого рода — изыск, на практике смысла в ней нет. Пусть уж оптимизирует компилятор...

Здравствуйте, VladD2, Вы писали:

L>>Кто знает, чем отличается среда Visual C++ от Builder C++.

VD>VC, gcc, g++, Intel C Compiler, и многие другие (заметьте, это не всегда среды) соберают вокруг себя тех кто может думать головой. Боже упаси думать могут и пользователи Borland, но из-за выше перечисленных причин общий процент не велик. Продукты приведенные в списке отличаются тем, что на них почти нельзя работать не углубившись в дебри познания.

для тех кто используют far + bcc32 ( cl,.. etc ) вопрос что использовать borland или visual не стоит ))O-)


VD>Простой пример. В поставку VC входит ПОЛУТОРА ГИГОБАЙТНЫЙ MSDN. Большинство работающих на продуктах Borland даже не знают о его существовании (ну, или ограничиваются этим знанием). А ведь MSDN – это библия Win32 программирования.

лично я msdn пользуюсь крайне редко и ест-сно не ставлю всю эту прорву на диск — мало того что место занимает
так VS по ней искать пытается — на П4 с 1Гб случайное нажатие F1 подвешивает работу секунд на 30.. а я всего лишь
какой нить puts искал ( например ). гораздо лучше ( имхо!!!)) борландовский hlp — и меньше ( я беру только 2 файла
про C-Runtime library и STL ) и быстрее.) а F1 пришлось в студии вообще дизейблить). а когда очень надо то
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_vclang_home.asp — благо у всех постоянный и быстрый онлайн стал нормой. всем очень рекомендую ) а полтора гига лучше хорошей музыкой занять )

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Lexus, Вы писали:

А>Весь этот флейм чистой воды фидошничество! Говно глючное можно написать как на VC, так и на BCB, да и на VB, Perl, Pascal, Delphi и даже на ассемблере. Да на чем угодно. Вы думаете в MFC глюков нет? Есть! И в VCL они тоже есть. Глюки есть практически в любом софте. А качество софта измеряется не языком программирования, а программистом, который его ваяет. Так что не занимайтель словоблудием. Каждый выбирает то, что ему нравится!

А>Lexx
согласен!!!!!!!!!
запретить такие темы !!!!

Здравствуйте, VladD2, Вы писали:

VD>Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает
Какая-то несуразица.
1. Либо я не научился в делфи стек вызовов смотреть либо все же там нельзя это сделать. Хотя я вобщем-то на 6 пробовал. То что там есть — это скудный вариант.
2. А какже Edit@Сontinue???
3. А кастомизация отображений

На мой взгляд не стоило сравнивать дебагеры. У каждого есть и преимущества и недостатки. Я програмиирую на делфи и на vc и нахожу дебагер vc более мощным. Но это мое имхо и не для развития флейма эта фраза.

А в остальном — достойно публикации.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Lexus, Вы писали:

А>Весь этот флейм чистой воды фидошничество! Говно глючное можно написать как на VC, так и на BCB, да и на VB, Perl, Pascal, Delphi и даже на ассемблере. Да на чем угодно. Вы думаете в MFC глюков нет? Есть! И в VCL они тоже есть. Глюки есть практически в любом софте. А качество софта измеряется не языком программирования, а программистом, который его ваяет. Так что не занимайтель словоблудием. Каждый выбирает то, что ему нравится!

А>Lexx

"А качество софта измеряется не языком программирования". Не всегда. Что касается delphi, vc++ и т.д. — тут понятно.
НО!!! Вы работали на CA Visual Objects 2.5. Вещь не рабочая по своему определению. Там многие синтаксические ошибки компилируются даже без ворнингов. Потом ручная компиляция и отладка такого проекта — одна сказка. Более того, там неудачный GC. Передал указатель в функцию- начинаешь его использовать — а там ничего нет — пямать дефрагментировалась. А вся библиотека оконных классов реализована с использованием фиксатора указателей (чтобы не дефграгментировался этот участок памти) а при вызове более 300 этого фиксатора программа уходит.

Ну вобщем я хочу сказать что не все языки программирования относятся к утверждению "А качество софта измеряется не языком программирования".

Здравствуйте, WolfHound, Вы писали:


WH>Вот тут я не совсем согласен. Алгоритмические оптимизации это конешно основное. НО качество оптимизации С++ компилятора очень сильно влияет на производительность. Порой в разы.
WH>А на счет асма то я не знаю людей которые могут писать на асме лучше чем генерирует код ителовский компилятор.
Смотря на каком процессоре и памяти. Конечно если ходить по двойной ссылке это скажется (но на огромных вычислениях) при условии что все данные попадают в кэш. Если смотреть на Delphi то там компилятор далек от совершенства, но например разница большая на Целерон 500 и Athlon ХР 2400+ . Если на первом Delphi может проигрывать нетовскому JIT то на втором выигрывает. А все дело в том что скорость к кэш памяти на уровне доступа к регистрам.

Здравствуйте, glyph, Вы писали:

И охота Вам было поднимать эту пыльную, покрытую паутиной, ветку?
В "Священные войны" ее и куда-нибудь поглубже

Здравствуйте, WolfHound, Вы писали:

TL>> А как же Вы пишете?
WH>Я ипользую смесь 80% конечных автоматов, 15% процедурного и 5% структурного программирования.
WH>К сожалению я плохо обьясняю поэтому лучше почитайте здесь.

80% многовато, я думаю реально чуть меньше

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

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

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

Здравствуйте, AlexEagle, Вы писали:

AE>Здравствуйте, VladD2, Вы писали:

VD>>Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает
AE>Какая-то несуразица.
AE>1. Либо я не научился в делфи стек вызовов смотреть либо все же там нельзя это сделать. Хотя я вобщем-то на 6 пробовал. То что там есть — это скудный вариант.

Не научился. Интерфейс в Дельфи специфический, но пользоваться очень даже можно.

AE>2. А какже Edit@Сontinue???

Кстати, на атл-ых проектах если его не отключить, то легче повеситься.

AE>3. А кастомизация отображений

Отображений чего?

AE>На мой взгляд не стоило сравнивать дебагеры.

Хорошо, что есть разные мнения.

Здравствуйте, vdimas, Вы писали:

V>80% многовато, я думаю реально чуть меньше
Я рекомендую посмотреть на дату этого поста... 02.07.2002.
Я тогда был еще маленьким
Сейчас меня писать логику на конечном автомате уговорить практически не реально. Если толко задача лучше всего решается именно конечным автоматом. На пример для лексера и парсера конечный автомат впполне адекватен. Причем я его скорей всегу буде генерить. Но в большинстве задач данная техника весьма сомнительна.