Как вообще люди в VC работают???
В чем тогда преимущество писания на VC?
Давно хотел задать этот вопрос, он меня мучает и не дает спокойно спать. Как в VC работать? В нем от Visual только название. Если взять, к примеру, Borland Buider или другие компиляторы с ДЕЙСТВИТЕЛЬНО визуальным интерфейсом, то в соревновании "кто быстрее сделает окно с юзер интерфейсом (кнопки, формы ввода и т.п." победит явно не тот, кто юзает VC, а тот, кто пользуется визуальными средствами Builder'а. Тогда в чем прикол? WinAPI работает и там, и там. Размер конечного продукта? Да на это уже все давно плюют с высокой колокольни, выпуская файловые менеджеры размером с компакт-диск :)
В чем тогда преимущество писания на VC?
Традиции – страшная вещь...:D :D :D :D :D :D :D
Visual С действительно является визуальной средой разработки, а вот назвать его средой RAD как-то не получается.
По поводу плюсов - хотя бы скорость работы, которая критична например в 3d играх, или в чем посерьезнее, например мат.моделях, экспертных системах и т.д.
Уважаемый mustlive, если бы вы работали с как вы выразились комилятором CBuilder вы были бы неприятно удивлены отсутствием визуальности как таковой. Компилятор CBulder'a например, называется bcc32.exe и уж точно не имеет "ДЕЙСТВИТЕЛЬНО визуального интерфейса".
Да ну???????? Правда что ли?????? Я и не знал :-(
:)
По поводу плюсов - хотя бы скорость работы, которая критична например в 3d играх, или в чем посерьезнее, например мат.моделях, экспертных системах и т.д.
Критичность кусков кода - я понимаю. Их можно написать и на ASM (если вы знаете, что это такое).
А вот преимуществ в VC перед другими СРЕДСТВАМИ РАЗРАБОТКИ ПРОГРАММ НА С++ для Вындовс (если уж вы так настаиваете на терминах) я не вижу. Зато я вижу большие недостатки если нужно БЫСТРО что-то исправить - а таких задач на практике большинство. Если вы не пишете курсовой проджект
Кроме того лично мне удобно писать на VC++ программы с нуля, т.е. используя только свое. Например, недавно писал контролы для редактирования матриц и полиномов. Всю обработку и вывод текста на экран, перемещение курсора делал вручную. А на экраны программ такого вида уже устал смотреть:
|_______|_______|_______|
|_______|_______|_______|
|_______|_______|_______|
|_______|_______|_______|
Зато я вижу большие недостатки если нужно БЫСТРО что-то исправить...
А как вы, уважаемый, собрались БЫСТРО что-то исправить, если это написанно на абсолютно незвестном мне asm'e;)
Опять же, если использовать MFC то особой разницы в скорости разработки не вижу(про БД умолчу т.к. в VC с ними не сталкивался).
С товарищем pavor'ом абсолютно согласен по поводу не совсем адекватного на мой взгляд представления WIN32 API в VCL.
недавно писал контролы для редактирования матриц и полиномов. Всю обработку и вывод текста на экран, перемещение курсора делал вручную.
Вот-вот... курсовики, мать их :)
А как вы, уважаемый, собрались БЫСТРО что-то исправить, если это написанно на абсолютно незвестном мне asm'e;)
Опять же, если использовать MFC то особой разницы в скорости разработки не вижу(про БД умолчу т.к. в VC с ними не сталкивался).
С товарищем pavor'ом абсолютно согласен по поводу не совсем адекватного на мой взгляд представления WIN32 API в VCL.
Я вижу преимущества ВИЗУАЛЬНЫХ средств в том, что они позволяют ОЧЕНЬ быстро сделать приличную программу, не особо заморачиваясь с интерфейсом, на котором угробишь туеву хучу времени, используя VC. Свои контролы нигде писать не запрещается, насколько мне известно (ни один КОМПИЛЯТОР пока до этого не додумался ;).
Так в чем плюсы, кроме того, что "это все мое, родное (c) Brother II"?
Давным-давно, в стародавние времена попался мне в руки Visual C++ 6.0. Обзаведясь RTFM, я решил накропать что-нибудь с помощью этого чудесного Visual средства. Каково же было мое изумление, когда я прочитал примерно следующее:
Вы хотите поместить кнопку с надписью "I'm dumb" на форме? НЕТ НИЧЕГО ПРОЩЕ! Для этого вам и нужен SUPER VISUAL C++!!! Для начала, откройте файл ресурсов, создайте там идентификатор с названием, допустим, YOU_ARE_NEXT_REALLY_DUMB 10000000...
После чего желание писАть что-либо на VC отпало на раз. Надеюсь, так понятней??? :)
Однако IMHO затраты на создание интерфейса в виде пары кликов в RAD или пары десятков кликов в VC не есть критичное различие, а вот разница в скорости выполнения на 15-20% это существенно(хотя для калькулятора или примитивной бухгалтерской программы из пары таблиц как раз наоборот).
Кстати, насчет интерфейса, можно вообще обходиться консольными приложениями, все зависит от задачи...
З.Ы. Кажется дискуссия переходит в бессмысленное сравнение удобства щелканья мышью8)
Знакомое ощущение, первые впечатления были такие же:)
Ну дык, об чем и речь.
Кстати, насчет интерфейса, можно вообще обходиться консольными приложениями, все зависит от задачи...
Вот про скорость - это уже ближе к теме, это становится похоже на "преимущество".
Мне вот что интересно: в принципе, хотелось бы пописАть на Visual, посколько VC роднее Windows'у по определению, более нативно (в компонентах ведь и ошибок можно больше наделать при создании - я имею ввиду создание VCL), но как все-таки люди на VC быстро создают приложения? Это приходит автоматом с практикой, или может наработки используют (типа, написали 5 лет назад один раз программу, которая строит главное окно, и используют ее теперь как шаблон)???
Ну дык, об чем и речь.
Вот про скорость - это уже ближе к теме, это становится похоже на "преимущество".
Мне вот что интересно: в принципе, хотелось бы пописАть на Visual, посколько VC роднее Windows'у по определению, более нативно (в компонентах ведь и ошибок можно больше наделать при создании - я имею ввиду создание VCL), но как все-таки люди на VC быстро создают приложения? Это приходит автоматом с практикой, или может наработки используют (типа, написали 5 лет назад один раз программу, которая строит главное окно, и используют ее теперь как шаблон)???
Как правило, используются именно шаблоны. Ну плюс ко всему если знать Win32 API - то процесс рисования приложений на VC получается не столь уж сложным - скорее более трудоемким.
Если копнуть глубже - недостатков хватает и в BCB и VC.
Мне неприятно работать в Builder, потому что там сделано все не так, как есть на самом деле. То есть если механизм в Windows работает так, то в Builder все работает иначе. И поэтому мне неудобно мыслить, а затем все переводить в другую концепцию.
Тут немного не соглашусь. Что значит "в Builder все работает иначе"? API оно и есть API - как его не крути. Все работает по тем же самым законом и правилам - просто завернуто в обертку :)
Пример - я знаю, что таймер - это сообщение, а не компонента.
WM_TIMER - это сообщение. Компонент TTimer - не более чем класс, который ловит сообщение WM_TIMER и генерирует свой эвент (кстати дюже удобная штука за изобретение __closure готов поставить Борланду памятник). Так что все законно и точно так же как в обычном API. Другое дело, с чем опять таки бесспорно соглашусь, то что:
1) VCL компилялся на паскале что не есть гут.
2) Практически все VCL компоненты Borland просто перегрузил кучей абсолютно бесполезных методов, которые при разработке программ нужны как машине пятое колесо, а места в экзешнике кушают что только держись. Вот за это Борланду следовало бы уши отвинтить и сказать шо так и було.
Если взять, к примеру, Borland Buider или другие компиляторы с ДЕЙСТВИТЕЛЬНО визуальным интерфейсом, то в соревновании "кто быстрее сделает окно с юзер интерфейсом (кнопки, формы ввода и т.п." победит явно не тот, кто юзает VC, а тот, кто пользуется визуальными средствами Builder'а.
если умеешь по полной IDE пользовать, используешь MFC, WTL или другой враппер и создаешь диалоговое приложение, имхо что на билдере работаешь, что на VC++ разницы нет, может даже на VC++ и быстрее будет.
Попробую объяснить, откуда у меня вообще появился этот вопрос, может быть, станет понятней...
Давным-давно, в стародавние времена попался мне в руки Visual C++ 6.0. Обзаведясь RTFM, я решил накропать что-нибудь с помощью этого чудесного Visual средства. Каково же было мое изумление, когда я прочитал примерно следующее:
Вы хотите поместить кнопку с надписью "I'm dumb" на форме? НЕТ НИЧЕГО ПРОЩЕ! Для этого вам и нужен SUPER VISUAL C++!!! Для начала, откройте файл ресурсов, создайте там идентификатор с названием, допустим, YOU_ARE_NEXT_REALLY_DUMB 10000000...
После чего желание писАть что-либо на VC отпало на раз. Надеюсь, так понятней??? :)
если сравнение компиляторов перешло на такой уровень, замечу, что в Visual C++ 6.0 диалоговые окна создаются также как и в Buildere (почти) а именно - Drag&Drop'ом... :)
если же серьезно, нельзя сказать, что VC++ являеться более быстрым компилятором. работа с памятью реализована лучше в Билдере. правда все же следует признать, что VC++ получше оптимизирует исходный код. кто не верит - берете IDA и смотрите, на что меняются основные конструкции там и там. далее. Microsoft не рекомендует использовать с VC++ STL - что на мой взгляд - недостаток, причем конкретный. в частности - класс string (STL) работает на порядок быстрее родного CString. (проверено :) поэтому я все же рискую и пользую STL активно). так же слышал, что в Builder присутствуют весьма существенные ошибки при работе с ссылками и реализации множественного наследование VCL классов (сам не проверял - см.
http://www.comizdat.com/3/4/90/3571/3808/3810/ ну и тестирование сравнительное по работе с различными компиляторами там приведено. это чтобы не быть голословным.) а вообще предлагаю каждому для себя придумать пару тестов для сравнения. лучше вникните в работу главного инструмента программера...
если сравнение компиляторов перешло на такой уровень, замечу, что в Visual C++ 6.0 диалоговые окна создаются также как и в Buildere (почти) а именно - Drag&Drop'ом... :)
если же серьезно, нельзя сказать, что VC++ являеться более быстрым компилятором. работа с памятью реализована лучше в Билдере. правда все же следует признать, что VC++ получше оптимизирует исходный код. кто не верит - берете IDA и смотрите, на что меняются основные конструкции там и там. далее. Microsoft не рекомендует использовать с VC++ STL - что на мой взгляд - недостаток, причем конкретный. в частности - класс string (STL) работает на порядок быстрее родного CString. (проверено :) поэтому я все же рискую и пользую STL активно). так же слышал, что в Builder присутствуют весьма существенные ошибки при работе с ссылками и реализации множественного наследование VCL классов (сам не проверял - см.
http://www.comizdat.com/3/4/90/3571/3808/3810/ ну и тестирование сравнительное по работе с различными компиляторами там приведено. это чтобы не быть голословным.) а вообще предлагаю каждому для себя придумать пару тестов для сравнения. лучше вникните в работу главного инструмента программера...
Уфф... ребята, ну вы даете...
Ваши споры схожи с кудахтаньем бабок на скамейке о крутости автомобиля по его цвету и количеству рюшечек.
Чтож вы мешаете в одну кучу компилятор, среду разработки, MFC и STL?
Где ты видел, что "Microsoft не рекомендует использовать с VC++ STL" ? Глупость какая.
И какое отношение STL имеет к компилятору и среде разработке, я уж не говорю про MFC?
При чем тут диалоговые окна и компилятор?
Для mustlive.
Для того, чтобы понять всю прелесть VC++ попробуй всерьез заняться изучением языка программирования С++, а так же различных оконных врапперов. Думаю, ты поймешь, что BCB похож на "золотую клетку со всеми удобствами". Он хорош для разработки разового проекта. Не думаю, что тебе приходилось использовать повторно хотябы 5% наработанных текстов без использования Copy/Paste. :D
Очень понравилось изречение pavor о внешнем виде програм на BCB и Delphi. Они и вправду, как близнецы братья, причем далеко не симпатичные. :D
(вопрос провакационно-риторический в стиле открывшего эту тему)
Разрешите господа встрять новичку на конференции в ваш разговор.
Я хочу добавить одну мысль к перечислениям достоинств и недостатков VC и BCB -- хороша или не хороша система разработки это вопрос субъективный и что одному нравится, то другому плохо и никогда практически не удается переубедить этого другого в своей правоте. Действительно, как тут уже писали нужно попробовать и то и другое и задача покажет, что лучше и кстати что подходит к самой задаче.
Поясню на личном примере... В году эдак 97 или 98 дорвался я первый раз до задачи под Win. Ну первое что удалось найти это был BCB 1.0 -- ну и ладно, прочитал в журналах -- хвалят, купил книжку -- вроди ничего. Буду работать в нем. Задачка -- так себе, средненкая (даже ближе к небольшой)не шибко закрученный польз. интерфейс, графика, в виде кривых. Сварганил достаточно быстро и почти возрадовался. Но тут попросили добавить в программу печать. И вот тут началось... Вы скажете ха, что же тут особенного в печати, но сложность была в том что печать так называемая рулонная. В зависимости от длинны кривых и от масштаба в котором они печатаются, это может быть распечатка на несколько метров. Вобщем натрахался я по полной программе. Пришлось залезть в исходники VCL, и тут для меня было первое разочарование. Я увидел что архитектурно библиотека очень похожа на TurboVision (ненавистную с DOS-овских времен -- тоже поимел неприятное знакомство), да и воще написано не ахти. Короче разрешить главные вопросы мне так и не удалось. А в соседнем отделе как раз появился VC кажется или 4.0 или 4.2. С горя решил посмотреть там, и на удивление где-то за неделю разрешил там все свои вопросы, сделал в API-шных вызовах все что надо и перекинул в борландовскую свою программу и сбагрил этот проект, который вспоминаю с тошнотой. И, как вы уже наверно догадываетесь, тошнота не от сложности задачи, а от знакомства с BCB. Конечно последний с версии 1.0 к настоящему времени наверняка несказанно похорошел и получшел, но я в него уже не зайду ни за какие деньги. Я уж тут не вспоминаю про непомерно большие времена перекомпиляции, неудобство инерфеса, наверно это уже решено в современных версиях, но как говорится "неприятный осадок" остался.
А VS как понравилась мне еще в те времена, так все больше нравится с каждой версией (сейчас VS.NET 2003) и главное что в следующей версии они сделают, то чего мне не хватает сейчас. Например outlining и InteliSense, сделаны буквально как я хотел. И, главное, я уверен, что сделаю здесь любую задачу даже немного и нестандартную. (полностью согласен с высказыванием про "золотую клетку" -- уж больно просматривается заточенность BCB под простые задачи и в основном под базы даннных).
Я думаю, что основное преимущество VS (для меня, по крайней мере) в том, что он построен на MFC, которая есть лишь легкая надстройка над API. И хорошо, что она легкая -- чем ближе к телу тем лучше, а мой опыт именно за это. Конечно все писать в API трудновато, а вот как в MFC вполне достаточно.
Извиняюсь за длинность... Резюме -- на вкус и цвет товарищей нет. Сам знаю что банално, но мне кажется выискивать различия в компиляторах в IDE, сейчас бесполезно, все всё друг у друга подсматривают и все примерно равны. Нужно попробовать и работать в чем понравится.
Но, если, перегрузить оные операторы для пользовательских классов, а для простых типов использовать malloc/free(для полного счастья HeapAlloc/HeapFree)вы будете приятно удивлены скоростью работы VC++ с памятью.
По поводу того что VС++ медленно работает с памятью - тоже старая фишка. В VC++ вызовы new/delete всегда работают с точки зрения потоково-безопасного выделения памяти, даже если в настройках указанно однопоточное приложение.
Но, если, перегрузить оные операторы для пользовательских классов, а для простых типов использовать malloc/free(для полного счастья HeapAlloc/HeapFree)вы будете приятно удивлены скоростью работы VC++ с памятью.
Откуда такая информация?
Только что проверил. Вызовы new/delete сводятся к обычному HeapAlloc/HeapFree, а дополнительной работы с объектами синхронизации, которая обуславливает потокобезопасность, я не заметил. Да и зачем? Это дело операционной системы (HeapAlloc/HeapFree).
А про разницу в "скорости работы с памятью" между стандартными компиляторами VC++ и BCB - это IMHO миф. Докажите мне обратное конкретным примером с исходным кодом, параметрами компиляции и результатами работы. Неплохо бы еще дизассм приложить.
Давно хотел задать этот вопрос, он меня мучает и не дает спокойно спать. Как в VC работать? В нем от Visual только название. Если взять, к примеру, Borland Buider или другие компиляторы с ДЕЙСТВИТЕЛЬНО визуальным интерфейсом, то в соревновании "кто быстрее сделает окно с юзер интерфейсом (кнопки, формы ввода и т.п." победит явно не тот, кто юзает VC, а тот, кто пользуется визуальными средствами Builder'а. Тогда в чем прикол? WinAPI работает и там, и там. Размер конечного продукта? Да на это уже все давно плюют с высокой колокольни, выпуская файловые менеджеры размером с компакт-диск :)
В чем тогда преимущество писания на VC?
mustlive, я сам девлюсь таким чудесам! и почему люди предпочитают VC++ билдеру. И на работе требуются по VC++. Я вроде себя успокоил тем, что может VC++ дешевле. А вот теперь вижу, что есть такие люди которые просто по незнанию защищают VC++. Просто диву дивишься!!! В билдере огромные возможности.
А вот теперь вижу, что есть такие люди которые просто по незнанию защищают VC++.
:D :D :D
Колумб!
А все остальные - темень беспросветная...
В билдере огромные возможности.
Возможности в студию!
И какое отношение STL имеет к компилятору и среде разработке, я уж не говорю про MFC?
не знаю причем тут MFC :) а насчет реализации STL в VC++ 5/6 см. к примеру
http://groups.google.com/groups?hl=en&selm=7l14rd%247he%241%40news.harvard.net один трабл...
впрочем, не настаиваю. может в самых последних версиях все ок.
При чем тут диалоговые окна и компилятор?
а при том, что если человек ругая компилятор приводит в качестве довода:
Вы хотите поместить кнопку с надписью "I'm dumb" на форме? НЕТ НИЧЕГО ПРОЩЕ! Для этого вам и нужен SUPER VISUAL C++!!! Для начала, откройте файл ресурсов, создайте там идентификатор с названием, допустим, YOU_ARE_NEXT_REALLY_DUMB 10000000...
то что ему можно ответить? поневоле сам переходишь к сравнению сред разработки...
Я думаю, что основное преимущество VS (для меня, по крайней мере) в том, что он построен на MFC, которая есть лишь легкая надстройка над API. И хорошо, что она легкая -- чем ближе к телу тем лучше, а мой опыт именно за это. Конечно все писать в API трудновато, а вот как в MFC вполне достаточно.
Вот вы сами сказали, что используете VS .NET, а ведь в .NET место MFC должна занять Windows.Forms (по крайней мере, так считает MS), а Windows.Forms больше похож на VCL, чем на MFC.
не знаю причем тут MFC :)
При том, что ты показываешь CString из MFC аналогом std::string из STL вслед за фразой о том, что MS не рекомендует использование STL
а насчет реализации STL в VC++ 5/6 см. к примеру
http://groups.google.com/groups?hl=en&selm=7l14rd%247he%241%40news.harvard.net один трабл...
впрочем, не настаиваю. может в самых последних версиях все ок.
Наличие трабла ещё не говорит о том, что MS не рекомендует использовать STL. Я знаю и другие проблемы в STL стандартно поставляемом с VC++, поэтому и использую STLPort.
То, что VC++ 6 толком не поддерживает шаблоны не говорит же о том, что MS не рекомендкет использовать шаблоны. Пожалуйста, используйте, но с соотв. ограгичениями.
А по поводу категоричных заявлений,я для себя взял за правило и других прошу: если уж заявляете категорично "Microsoft не рекомендует использовать с VC++ STL", то привидите ссылку на официальный документ, где было бы сказано "It is not recommended to use STL".
Я же нашел лишь обратное утверждение:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/msdn_vcdhtmlclnts.asp
It is recommended to use STL as much as possible.
если человек ругая компилятор приводит в качестве довода:
Вы хотите поместить кнопку с надписью "I'm dumb" на форме? НЕТ НИЧЕГО ПРОЩЕ! Для этого вам и нужен SUPER VISUAL C++!!! Для начала, откройте файл ресурсов, создайте там идентификатор с названием, допустим, YOU_ARE_NEXT_REALLY_DUMB 10000000...
то что ему можно ответить? поневоле сам переходишь к сравнению сред разработки...
Не стоит уподобляться людям плохоразбирающимся в сути вопроса. Наверное, лучше объяснить, что компилятор не имеет отношения к среде разработке и используемой GUI-библиотеке.
Вот вы сами сказали, что используете VS .NET, а ведь в .NET место MFC должна занять Windows.Forms (по крайней мере, так считает MS), а Windows.Forms больше похож на VCL, чем на MFC.
Лично я вообще не использую MFC, но при этом остаюсь пользователем VC++, потому что меня устраивает:
1) среда разработки,
2) редактор ресурсов,
3) компилятор,
4) линкер,
5) отладчик,
6) интеграсия с MSDN,
7) интеграция с SourceSafe и StarTeam.
То, что не устраивало - MFC и STL, я заменил другими библиотеками - WTL и STLPort.
Надо будет заменю компилятор и линкер.
Для создания кросс-платформенных или мультиплатформенных приложений подрублю gcc, mingw и Qt.
А есть ли возможность в BCB отказаться от VCL в пользу другой GUI-библиотеки?
Можно ли использовать редактор форм в качестве обычного редактора ресурсов?
Насколько просто заменить компилятор или настроить сборочную систему на базе makefile?
Для дальнейшего спора подумайте, о чем конкретно вы спорите?
Вы пытаетесь сравнить одним махом сразу пять различных вещей:
1) среду разрабоки,
2) компилятор,
3) линкер,
4) дополнительный инструментарий (редактор ресурсов, отладчик и т.п.)
5) GUI-библиотеку.
если уж заявляете категорично "Microsoft не рекомендует использовать с VC++ STL", то привидите ссылку на официальный документ, где было бы сказано "It is not recommended to use STL".
ладно... согласен пользовался непроверенной инфой. правда это не мое категоричное утверждение. ссылку на соответствующую статью я давал выше (в самом первом посте. там статья про сравнительный анализ компиляторов)
а что за STLPort?
а что за STLPort?
:D :D :D
Колумб!
А все остальные - темень беспросветная...
Возможности в студию!
VC++ работает быстрее? Возможно.(Этот вопрос мне еще предстоит выяснить). Если бы скорость была так важна, то многие программировали бы на asm (до посинения). Скорость важна, но побольшей части в разработке приложения. Чем VC++ уступает билдеру. А объёс exe - модуля может и побольше(чего я собириюсь выяснить), но не на гегабайты же. Вы предираетелсь к скорости и к объёму как-будто собираетесь писать прогу для сотовых телефонов или для какой-то другой аппаратуры, которая не может похвастаться производительностью и соответственно для них пишут проги на asm. Но билдер как раз и предусмотрен для разработки больших приложений. И компилятор можно наладить так как тебе угодно (настроек там тьма). И будет и скорость и объём нужных размеров (в пределах разумного). В билдере (во всяком случае в 6 версии) имеются библиотеки owl,MFC,stl,coff, тогда как в VC++ только MFC. Также в билдере можно разрабатывать свои визуальные компоненты. Также в билдере имеется поддержка транспортных сетевых протоколов TCP/Ip, HTTP,FTP,NNTP,SMTP,POP3, чего не скажешь про VC++. В билдере есть диагностика утечки памяти, чем VC++ не может похвастаться. Некоторые товарищи говорят, что им мол нравиться с нуля начить, чего в билдере тоже можно сделать. Вы скажите, чего можно сделать в VC++, что не получиться в билдере. Да ничего. Билдер не уступает VC++, он его превосходит. В билдере также есть хранилище объектов. Еще одно достоинство билдер - это КРОСС ПЛАТФОРМЕННЫЕ ПРИЛОЖЕНИЯ. Т.е. проги можно не переписывать для разных платформ (Windows,Linux), а просто перекомпилировать их на соответствующей платформе. Хотя это беседа мне напоминает: "А у нас в квартире газ. А у вас?". Но если быть совсем чесным, то VC++ просто не нравиться!!!:D :D :D
Все, что вы тут наговорили меня сподвигло на повторное возвращение в среду VC++. Попробуем еще разок...
:D :D :D
Колумб!
А все остальные - темень беспросветная...
Возможности в студию!
Здравствуй, много почтенный индеец, я покажу тебе новые земли.
VC++ работает быстрее? Возможно.(Этот вопрос мне еще предстоит выяснить). Если бы скорость была так важна, то многие программировали бы на asm (до посинения). Скорость важна, но побольшей части в разработке приложения. Чем VC++ уступает билдеру. А объёс exe - модуля может и побольше(чего я собириюсь выяснить), но не на гегабайты же. Вы предираетелсь к скорости и к объёму как-будто собираетесь писать прогу для сотовых телефонов или для какой-то другой аппаратуры, которая не может похвастаться производительностью и соответственно для них пишут проги на asm. Но билдер как раз и предусмотрен для разработки больших приложений. И компилятор можно наладить так как тебе угодно (настроек там тьма). И будет и скорость и объём нужных размеров (в пределах разумного). В билдере (во всяком случае в 6 версии) имеются библиотеки owl,MFC,stl,coff, тогда как в VC++ только MFC. Также в билдере можно разрабатывать свои визуальные компоненты. Также в билдере имеется поддержка транспортных сетевых протоколов TCP/Ip, HTTP,FTP,NNTP,SMTP,POP3, чего не скажешь про VC++. В билдере есть диагностика утечки памяти, чем VC++ не может похвастаться. Некоторые товарищи говорят, что им мол нравиться с нуля начить, чего в билдере тоже можно сделать. Вы скажите, чего можно сделать в VC++, что не получиться в билдере. Да ничего. Билдер не уступает VC++, он его превосходит. В билдере также есть хранилище объектов. Еще одно достоинство билдер - это КРОСС ПЛАТФОРМЕННЫЕ ПРИЛОЖЕНИЯ. Т.е. проги можно не переписывать для разных платформ (Windows,Linux), а просто перекомпилировать их на соответствующей платформе. Хотя это беседа мне напоминает: "А у нас в квартире газ. А у вас?". Но если быть совсем чесным, то VC++ просто не нравиться!!!:D :D :D
Все, что вы тут наговорили меня сподвигло на повторное возвращение в среду VC++. Попробуем еще разок...
Здравствуй, много почтенный индеец, я покажу тебе новые земли.
Здравствуй, бледнолицый друг.
VC++ работает быстрее? Возможно.(Этот вопрос мне еще предстоит выяснить).
Ты мои посты про то, что вы тут пытаетесь сравнивать, читал?
Или "чукча - не читатель, чукча - писатель"?
Если бы скорость была так важна, то многие программировали бы на asm (до посинения). Скорость важна, но побольшей части в разработке приложения.
Угу. Только, помимо скорости разработки единичного проекта в "одно жало", есть корпоративная разработка и повторность использования кода.
Но билдер как раз и предусмотрен для разработки больших приложений.
Каких именно? Какие приложения называются большими?
Там где "две сотни форм"? :D
В билдере (во всяком случае в 6 версии) имеются библиотеки owl,MFC,stl,coff, тогда как в VC++ только MFC.
Я с самого начала не строил иллюзий по поводу профессионального уровня своего оппонента, но ты превзошел все мои самые худшие ожидания.
Бери книгу и садись учиться!
Также в билдере можно разрабатывать свои визуальные компоненты.
Не задумывался, почему на самолетах нет стоп-крана?
Также в билдере имеется поддержка транспортных сетевых протоколов TCP/Ip, HTTP,FTP,NNTP,SMTP,POP3, чего не скажешь про VC++.
Без слов :D :D :D
В билдере есть диагностика утечки памяти, чем VC++ не может похвастаться.
Полно самых разнообразных, не считая стандартного отладчика. Я пользуюсь: BoundsChecker, Purify.
Некоторые товарищи говорят, что им мол нравиться с нуля начить, чего в билдере тоже можно сделать.
А если начинать не с нуля, но при этом не пользоваться VCL?
Вы скажите, чего можно сделать в VC++, что не получиться в билдере. Да ничего.
Прав. А тебе не приходило в голову, что не все получится сделать стандартным набором VCL, и тогда придется все делать через ж#пу.
Меня радуют вопросы в форумах типа: "А где дростать компонент для..."
Билдер не уступает VC++, он его превосходит.
По массе или по объему?
Может по мощности? На сколько Ватт? :D
В билдере также есть хранилище объектов.
Что за зверь?
Еще одно достоинство билдер - это КРОСС ПЛАТФОРМЕННЫЕ ПРИЛОЖЕНИЯ.
Ты читать, вообще, умеешь?
Т.е. проги можно не переписывать для разных платформ (Windows,Linux), а просто перекомпилировать их на соответствующей платформе.
Да... Прям панацея!
А ты пробовал перекомпилировать приложение под Windows под Linux? Очччень сомневаюсь!
Но если быть совсем чесным, то VC++ просто не нравиться!!!:D :D :D
А какой у тебя опыт работы с VC++?
Во скольких коммерческих, корпоративных проектах ты учавствовал?
Хотя, если ты не имеешь представления о STL, COFF и т.п., то глупо спрашивать.
Этот спор ведется уже давно и более профессиональными ребятами. Мне понравилось одно изречение о Delphi, но оно применимо и к BCB:
А что, кто-то ещё не знает ответа на этот вопрос? Тогда повторю - Негативное отношение к Delphi вызвано огромным количеством ламеров его юзающих, наполняющих форумы идиотскими вопросами, ответы на которые находятся за одну минуту в хелпе\интернете.
Это намек.
Как всегда мощные доводы - приятно почитать!!!
Мне так кажется, что если бы этот вопрос задали на
форуме для BCB или Delphi , то защитников VC++ было бы маловато.
P.S.:
VC++ - ruleZZZZZZZZZ!!!!!!!!!!!!!
От себя добавлю - в VC .Net подобного не замечал, хотя установка single-threaded library действительно дает некоторый прирост.
З.Ы. в VC .Net ошибки с STL по утверждению MS исправили, так что можно STLPort и не ставить.
Originally posted by Fatal
Также в билдере имеется поддержка транспортных сетевых протоколов TCP/Ip, HTTP,FTP,NNTP,SMTP,POP3, чего не скажешь про VC++.
рулеззз... я сражен наповал... злой Мелкософт опять нам нагадил! а ip - ярчайший представитель транспортных протоколов...
Мне больше понравилась фраза про отсутствие STL:D А цитата про Delphi действительно хорошая. Да, и по поводу "помогите найти компонент..." - глядишь скоро будут спрашивать "помогите найти компонент MS Word или компонент MS Windows" - ляпнул на форму - получил готовое приложение.
Я не думал, что мой пост выльется в такой флейм. Спросил всего лишь о МЕТОДИКЕ создания приложений на MS VC ("я за кефиром пошел, а тут - такое!!!")
Ну вы сильны, горячие финские парни :)
Ответов на свой вопрос я практически и не увидел (кроме одного, где-то наверху), зато посмотрел на дискуссию сторонников и противников. Забавно...
Кстати, по поводу вот этого:
Немного offtop'a
Мне больше понравилась фраза про отсутствие STL:D А цитата про Delphi действительно хорошая. Да, и по поводу "помогите найти компонент..." - глядишь скоро будут спрашивать "помогите найти компонент MS Word или компонент MS Windows" - ляпнул на форму - получил готовое приложение.
Цель написания программы как таковая - чтобы сделать БЫСТРО и чтобы все это работало, IMHO, все равно на чем писать, главное - результат. А гордиться тем, что "они ляпают компонент на форму - и все готово за 10 минут, ламеры, а я весь красивый и умный написал 35 классов за месяц, у меня программа лучше" я думаю, ни к чему.
Все в конечном итоге работают на пользователей, которым наплевать, знаешь ты STL,OWL,VCL,OLE,OLAP и прочее или нет - главное, я повторяю, готовый результат.
Цель написания программы как таковая - чтобы сделать БЫСТРО и чтобы все это работало,
Ошибочное мнение, если не сказать бред.
Основное правило любой креативной области - "Два из трех: быстро, качественно, недорого."
Скорость разработки регламентируется соотв. документами и определяется множеством факторов.
IMHO, все равно на чем писать, главное - результат.
Результат во многом зависит от инструментария. Не думаю, что пила "Дружба" заменит с таким же успехом лобзик, впрочем, как и наоборот.
А гордиться тем, что "они ляпают компонент на форму - и все готово за 10 минут, ламеры, а я весь красивый и умный написал 35 классов за месяц, у меня программа лучше" я думаю, ни к чему.
Здесь не гордость, а подход к проблеме: "уметь создать клетку, сконструировать льва и агрегировать его в клетку", против "поиск компонента 'клетка', поиск компонента 'пустыня', поиск компонента 'лев', бросаем компонент 'клетка' на форму 'пустыня', помещаем компонент 'лев' в компонент 'клетка'".
Все в конечном итоге работают на пользователей, которым наплевать, знаешь ты STL,OWL,VCL,OLE,OLAP и прочее или нет -
Опять ошибка.
Все в конечном итоге работают на себя, на поддержку и сопровождение продукта, на создание новых версий и новых продуктов.
главное, я повторяю, готовый результат.
- Папа, почему солнышко встает на востоке, а садится на западе?
- Точно? Ты проверял?
- Да.
- Тогда оставь все как есть и ничего не трогай!
Вот какой образ твоей работы создался:
Сделать всё как можно быстрее, чтоб работало... хоть как-нибудь... ага, вот тут залатаем... это не важно... работает? почти! отлично! Всё сдать и забыть, как страшный сон! Вперед к новому проекту!
Ошибочное мнение, если не сказать бред.
Основное правило любой креативной области - "Два из трех: быстро, качественно, недорого."
Скорость разработки регламентируется соотв. документами и определяется множеством факторов.
Я кажется сказал - быстро и чтобы все работало? Я не прав? Нужно медленно и чтобы работало через раз? :)
Результат во многом зависит от инструментария. Не думаю, что пила "Дружба" заменит с таким же успехом лобзик, впрочем, как и наоборот.
Все равно на чем писать, главное чтобы все работало. Имеется ввиду - писать базу данных на специальзированном софте (СУБД), писать программу расчета мат. модели на том языке, который обеспечивает хорошие вычислительные функции и хорошей точностью вычислений (не СУБД).
Здесь не гордость, а подход к проблеме: "уметь создать клетку, сконструировать льва и агрегировать его в клетку", против "поиск компонента 'клетка', поиск компонента 'пустыня', поиск компонента 'лев', бросаем компонент 'клетка' на форму 'пустыня', помещаем компонент 'лев' в компонент 'клетка'".
Если у вас есть проект, конечной целью которого является "лев в клетке" и все, нужно найти компоненты "лев" и "клетка" и их совместить. Если это займет по времени 1 день против самостоятельного написания того же (по результату) за месяц впятером.
Опять ошибка.
Все в конечном итоге работают на себя, на поддержку и сопровождение продукта, на создание новых версий и новых продуктов.
Никто так не работает. Самоцель - не выпуск новой версии. Цель - обеспечить решение проблемы пользователя, минимизировав параметры "затраты времени" и "расходы" и стремление максимизировать параметр "прибыль". Вот это грамотно. И волки сыты, и овцы целы.
Вот какой образ твоей работы создался:
Сделать всё как можно быстрее, чтоб работало... хоть как-нибудь... ага, вот тут залатаем... это не важно... работает? почти! отлично! Всё сдать и забыть, как страшный сон! Вперед к новому проекту!
Абзац 1. Чтобы сделать БЫСТРО и чтобы это РАБОТАЛО (не через раз).
Основное правило любой креативной области - "Два из трех: быстро, качественно, недорого."
О скорости разработки вы еще оговорили нюансы ("Скорость разработки регламентируется соотв. документами и определяется множеством факторов").
А что такое "качественно", что такое "недорого"? Это абстрактные понятия, на худой конец - субъективные (причем, даже у ЗАКАЗЧИКА и ИСПОЛНИТЕЛЯ эти параметры сильно разнятся)
Приятно почитать :)
На извечный вопрос о том "стоит ли заколачивать гвозди микроскопом или взять для этого молоток" - написано столько разносторонних мнений :) Best!
Маленькое дополнение к одному пункту:
согласен с цитатой приведенной Green'om... сдается мне, что главный недостаток Delphi&BCB - обманчивая легкость программирования... можно не лазить в недра Windows, не читать много книжек, вообще мозги не загружать. любая прога - Drag&Drop+"умный вопрос" на форуме... однажды, правда, сказка кончается. и совсем не весело
Немного с этим не согласен. В конечном итоге все напрямую будет зависить от программиста. Ежели ему интересно и необходимо - будет копаться (в независимости от того на чем он пишет). В свое время, когда я был молодой и неопытный - писал исключительно на Паскале, не понимал как вообще можно писать на C, а динамическую память считал абсолютно ненужным излишком (зачем она? ведь есть статические массивы). Как показало время - я сильно ошибался.
P.S. Немного не в тему разговора - но у меня до сих пор осталось весьма теплое и нежное отношение к Watcom C, хотя его давно уже нету... А жаль.
Немного с этим не согласен. В конечном итоге все напрямую будет зависить от программиста. Ежели ему интересно и необходимо - будет копаться (в независимости от того на чем он пишет). В свое время, когда я был молодой и неопытный - писал исключительно на Паскале, не понимал как вообще можно писать на C, а динамическую память считал абсолютно ненужным излишком (зачем она? ведь есть статические массивы). Как показало время - я сильно ошибался.
Где ОН будет копаться? В недрах BCB или DELPHI?
У многих после этого не выдерживают нервы!!!
Уж лучше MS VC++ !!! Конечно, если челу нужно относительно быстро что-нить (обычно визуальное)
наляпать , то тут BCB! НО!!!
Упаси господи это использовать в дальнейшем если понадобится!!!! Так что имея какой - либо базовый проект на Visual обычно легко его модифицировать(и писал сам тем паче большую его часть и код как на ладони!!!).
ЗюЫю Ж IMHO !!!
Где ОН будет копаться? В недрах BCB или DELPHI?
У многих после этого не выдерживают нервы!!!
Уж лучше MS VC++ !!! Конечно, если челу нужно относительно быстро что-нить (обычно визуальное)
наляпать , то тут BCB! НО!!!
Упаси господи это использовать в дальнейшем если понадобится!!!! Так что имея какой - либо базовый проект на Visual обычно легко его модифицировать(и писал сам тем паче большую его часть и код как на ладони!!!).
ЗюЫю Ж IMHO !!!
А при чем здесь недра BCB и Delphi когда ты сам говорил про недра Windows? Что собственно мешает при разработке прог на BCB/Delphi использовать весь механизм WinAPI? Да и все "недра" виндов?
А при чем здесь недра BCB и Delphi когда ты сам говорил про недра Windows? Что собственно мешает при разработке прог на BCB/Delphi использовать весь механизм WinAPI? Да и все "недра" виндов?
Весь ужас в том , что жареный петух клюёт именно "ТУДА" и очень БОЛЬНО!!!
Представь! У тебя есть прога, основанная на использовании неких компонентов. В принципе ты мало знаком с их кодом , но ты их радостно юзаешь.Всё высше.
Настал судный день (29 августа 1997 года - у кого-то может другая дата). Тебе нужно переделать прогу/доработать и т.д. И подходящего компонента нет!!!Всё.
А что касается API - немногие используя BCB/Delphi
его хорошо знают.
А что касается API - немногие используя BCB/Delphi его хорошо знают.
:) О чем я собственно говоря и писал :) ВСЕ зависит от программиста :) Я сейчас зачастую пишу на BCB - что не мешает мне совершенно свободно работать и на VC и прекрасно знать WinAPI. А синдром "забивания гвоздей микроскопом" я привел не случайно - грамотный программист, для каждой конкретной задачи может грамотно подобрать нужный инструмент. Я ни ЗА и не ПРОТИВ как VC так и BCB - я воспринимаю их только с точки зрения инструментов. А согласись - глупо кричать что молоток самый крутой инструмент на свете. Равно как и микроскоп. У каждого инструмента есть своя область применения.
А что касается программистов свято уверовавших в то что BCB это самый лучший пакет разработки - ну это уж их проблемы. Останутся недальновидными и замкнутыми на компонентах... Принцип естественного отбора - выживает сильнейший :) Просто у них будет существенно меньше шансов. Много-ли HTML кодеров гордо именующих себя "программистами" знают подноготную того на чем и для чего пишут? Не думаю.