Кто знает, чем отличается среда Visual C++ от Builder C++.
В книжках по Builder'у пишется, что некоторые вещи практически
невозможно сделать в Visual C++. Наверняка, верно и обратное.
Я не видел Visual C++ и программирую в Builder'е и Delphi
(и не напрягаюсь, что интересно). Но уж как-то много народу
пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

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

L>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>В книжках по Builder'у пишется, что некоторые вещи практически
L>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал ) :-(

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

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

L>>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>>В книжках по Builder'у пишется, что некоторые вещи практически
L>>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

K>А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал ) :-(

Ой, боюсь втянемся опять в "религиозные войны"....

Чисто из своего опыта — вначале мы писали на BCB. Все были довольны — быстро,удобно, просто, куча компонент... А потом, когда понадобилось сделать чтото, чуть более сложнее сем пара диалогов с кнопочками, полезли ошибки. Ошибки билдера. Мы писали в Inprise, они обкещали исправить к след. версии, а мы тем временем писали уйму кода чтоб их обойти.... Один экспорт класса из ДЛЛ чего стоит! (это еще во времена BCB3!). ПроDelphi я ничего не говорю — хорошая вешь. Беда билдера, то что это сишный интерфейс к паскалевскому интерфейсу сишных апи вызовов. Чуете крутизну? :)

Вот. Компилируя программу с packages допускало корректную работу dll, но криво создавалось окно, в dll содеожащееся. и наоборот. Короче, намучались мы основательно, последней каплей было тормозность OpenGL!!!! Ну как это они умудрились???? В общем переписали мы практически все проги гдето за 4 месяца на MFC, и пока все просто чудесно!

Еще прикол, что в 4 билдере не компилировался проект созданый в 3-м. Просто не работал!

Потому мы бросили исследование очередных версий BCB, что в 5-м честно говоря не знаю.

Так вот. Если у меня ктото и спрашивает на чем писать — то в зависимости от уклона — Delpi или MFC. Но никак не BCB.

Саша.

K>>А я уже лет пять мучаюсь с Visual C++. По сравнению с Дельфи все гораздо сложнее и заковыристей. Это как сравнивать иномарку ( купил — сел и поехал ) и наши тачки ( купил — разобрал — подтянул — починил и может быть поехал ) :-(

Насчет иномарок — точно. Зато когда чтото портится (глючит) — где ошибка — у тебя или у них не поймешь... Особенно когда пару раз окажется что действительно у них. Так теряешь веру, и любую ошибку начинаешь валит на них, и естественно, найти ее не получается.....

А тут — все под конролем!

Саша.

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

Вопрос очень... нет, ОЧЕНЬ плохой. На iXBT он тотчас же привел бы к тремстам постингам флэйма. Если Вы действительно хотите понять разницу между некоторыми продуктами, то:
а) Вам это должно быть Оооочень нужно!
б) Вам (лично) нужно освоить оба продукта и не на тестах, а на реальных по возможности больших проектах.

Если Вы понимаете о чем (и главное почему) я это говорю, то можете читать дальше. Далее я дам СВОЕ сугубо субъективное мнение. И оно будет не о среде, а о продуктах в целом. Да собственно и не о продуктах, а о профессионалах, мастерах, ламерах, и прикладниках.

Вы, удивитесь, но если отбросить совсем новичков и совсем крутых гуру, то эти среды отличаются уровнем знаний использующих их программистов. Заранее говорю! СПОРИТЬ Я НИ С КЕМ НЕ БУДУ! Delphi и Builder объединяют вокруг себя большое прикладных программистов и ламеров. Связано это с тем (похоже, реального ответа, думаю, не знает ни кто), что в этих продуктах реализованы две вещи.
1. Мощный визуальный редактор форм.
2. Много готового кода с приемлемым качеством разнесенного по разным классам и компонентам.
Остальные, безусловно полезные, интересные и красивые решения, технологии и подходы являются лишь строительным материалом для вышеперечисленных фич.
Прикладнику которому нужно, например, работать с промышленными СУБД, такое решение может оказаться очень подходящим. Основная логика задачи реализуется легко, а небольшие тонкости, время от времени возникающие на пути, можно решать за счет того, что оба языка являются (как минимум основаны) языками третьего поколения и позволяют осуществлять доступ к всевозможным API. Правда, такая деятельность для них является хакерством (или высшим пилотажем). Про ламеров и говорить ни чего не надо. Они (и начинающие программисты) выбирают эту среду из-за возможностей быстрого старта. Старта и в смысле обучению языку и в смысле легкости создания каркаса программ. Еще одним критерием который приводит выбору этих продуктов является возможность вообще избежать программирования как такового за счет использования готовых компонентов (как входящих в поставку так и посторонних). Скажу сразу ни чего плохого во всем этом нет, кроме того, что очень часто начинающий программист вместо того, чтобы прейти в разряд мастера переходит в разряд ламера, который считает задачу не решаемой если не нашлось готового компонента для ее решения и в ближайшей конфе не помогли.

VC, gcc, g++, Intel C Compiler, и многие другие (заметьте, это не всегда среды) соберают вокруг себя тех кто может думать головой. Боже упаси думать могут и пользователи Borland, но из-за выше перечисленных причин общий процент не велик. Продукты приведенные в списке отличаются тем, что на них почти нельзя работать не углубившись в дебри познания.
Простой пример. В поставку VC входит ПОЛУТОРА ГИГОБАЙТНЫЙ MSDN. Большинство работающих на продуктах Borland даже не знают о его существовании (ну, или ограничиваются этим знанием). А ведь MSDN – это библия Win32 программирования. Далее в VC средства дизайна GUI мягко говоря уступают средствам предоставляемым Delphi или Builder-ом (gcc и g++ — это вообще только компиляторы). Это приводит к тому, что основная часть программы является кодом. Причем Вашим кодом. Т.е. на программиста ложится несравнимо большая нагрузка и от него требуется знать намного больше чем в Builder. Построение таких программ приводит к появлению бОльшего количества кода и рано или поздно встает проблема структурирования кода. Delphi эта проблема стоит не так резко, так как во-первых, она сама помогает структурировать программу, а во-вторых, много кода вообще не надо писать. Собственно это большое преимущество если речь идет о сроке и выполнения проекта. Для прикладника это и является главным факторам. НО!!! Но, с точки зрения обучения – это большая беда! Просто нет такого количества практики, и проблем. Думаю анализ не нужен. Могу сказать только, что, по моей практике, самые луч VB- и Delphi-программисты – это высоко "скильные" C/C++-ники пересаженные на эти продукты.
VC люди выбирают не только из мазохистских побуждений. Бывают области (и как не странно их большинство) где GUI основанное на диалогах не главное. Например, подсчитайте количество диалогов в Word-е. А теперь прикиньте столько там остального кода. Или Q1-Q3 или те же компоненты. Причем в этих программах очень часто становятся критичным скорость выполнения. Для таких программ обычны большие объемы рукописного кода (порядка – 30к-300к строк C++-ного кода, а иногда и больше). И тут на первый, план выходят не RAD-ости, а средства работы с большими объемами кода и средства оптимизации. Вот здесь то VC и g++ выходят на первые роли.
Оговорюсь, что на Delphi можно сделать все тоже самое, что можно сделать на VC, но общая совокупность перевешивает. Например, компилятор Delphi порождает очень не дурственный код когда речь идет о работе со строками и целыми числами. Это – 90% потребностей прикладного программиста, но когда речь заходит о ручной оптимизации, о работе с float, о доступе к неординарным API, то Delphi пасует и сильно. Builder вообще обижен Borland-ом он проигрывает даже своей сестре – Delphi. С VC ему даже бесполезно тягаться. К тому же в VC можно довольно встроить Intel C Compiler который увеличивает разрыв в скорости (на новых процессорах) до заоблачных величин. Конечно можно попытаться это сделать и на Builder-е, но... Вот тут и рождается менталитет.

А что нужно мастеру если его основная задача моделировать задачи и долбить код? Правильно средства моделирования и хороший редактор кода. С средствами моделирования на сегодняшний день дела обстоят очень плохо. Самым серьезным инструментом моделирования для C++ является Роза от Рэйшонал. Откровенно говоря гов-но она полное. Кривая рисовалка, но хоть что-то! И именно, это, что-то, входит с 98 г. в VC. Но, из-за малой пользы на практике... Перейдем к редактору кода. Вот тут VC и Emacs (применяемый обычно совместно с g++) сильно выигрывают. Про Emacs лучше спросить у его поклонников, а про VC расскажу. 1. в VC можно полностью настроить клавиатуру под себя, на схему с раскладкой заменить, а настроить любую кнопку с на любое действие (даже макрос или метод плагина). 2. Сам редактор имеет больше возможностей и более интуитивен. Присутствуют такие функции как автоматическое форматирование отступов, запись и воспроизведение макросов. Отладчик VC (на сегодня) не превосходит дельфийский (а иногда даже ему уступает), но он более чем пригоден, для отладки сложных приложений. И это так уже на протяжении минимум десяти лет. В Delphi приличный отладчик появился в пятой версии, да и то при серьезной работе возникает слишком много проблем и неудобств. Кстати, некоторые навороченные возможностей отладки были реализованы MS, а Borland использует их плоды.
И Delphi и Builder и VC поддерживают расширения. Это приводит к тому, что недостающие части среды можно дополнять модулями скаченными из Internet-а. Для VC можно найти много мощеных расширений и почти все они доступны в исходных кодах. Расширения есть и для сред Borland, но преимущественно для Delphi, и 90% носят фетишистский характер. Например, для VC есть мощнейший опгрэйд для комплит ворда — "Visual Assist". С ним не сравнятся встроенные реализации ни VC 6 ни Builder-а ни даже VC 7.

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

PS

Да, совсем, забыл о профессионалах! :) Профессионал – это человек зарабатывающий себе на пропитание некоторой профессией. Обычно подразумевается, что делает он это не случайно. То есть профессионал может быть и дельфист и сионист и кто угодно кроме ламера. Чего себе и Вам желаю. :)

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

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

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

Когда у нас будет избранное? Я хочу поместить этот крик души туда. ;o)

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

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

IT>Когда у нас будет избранное? Я хочу поместить этот крик души туда. ;o)
это Ты спрашиваешь ?-)

Igor

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

VD>Вопрос очень... нет, ОЧЕНЬ плохой. На iXBT он тотчас же привел бы к

Красота !!! Повесить линк на титульной страничке !! :))

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

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

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

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

IT>Когда у нас будет избранное? Я хочу поместить этот крик души туда. ;o)

Ну хотя бы в раздел новости... А уж я в пару эх запостю, с разрешения автора :)
У меня приятель один, кстати, бывает провокатором под настроение: в Su.Windows.Prog или еще куда-нибудь пошлет письмо "здравствуйте-я-начинающий-подскажите-что-лучше-Си-или-Паскаль"...
Через полгода, бывало, зайдешь — а страсти все бушуют...

А если серьезно, то COM проложил небольшой мостик в этой бурной реке непримиримых стандартов. Мне лично пофиг, на чем кто-то напишет нужный компонент — пусть работает, как надо!
Успехов,
Виталий.

Потрясающе точно.
Господа администраторы, включите сие творение куда-нибудь, дабы не затерялось со временем.

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

R> А уж я в пару эх запостю, с разрешения автора :)
Да, сколько влезет.

R>А если серьезно, то COM проложил небольшой мостик в этой бурной реке непримиримых стандартов. Мне лично пофиг, на чем кто-то напишет нужный компонент — пусть работает, как надо!

Ну, про COM ято отдельный разговор (см. наши статьи http://www.optim.ru/cs/Topics/TopicCom.asp), а так и мен пофигу, а больше про метаморфозы. Когда лучшее, иногда, бывает врагом хорошего.

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

L>Кто знает, чем отличается среда Visual C++ от Builder C++.
L>В книжках по Builder'у пишется, что некоторые вещи практически
L>невозможно сделать в Visual C++. Наверняка, верно и обратное.
L>Я не видел Visual C++ и программирую в Builder'е и Delphi
L>(и не напрягаюсь, что интересно). Но уж как-то много народу
L>пишет в VC++. Хотелось бы знать, есть ли принципиальные отличия?

Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование. И это есть правильно. Объясняю почему. Когда пишется большой проект на visual c++, возможность множественного наследования провоцирует программистов на его использование. В результате получается много путаницы и трудновоспринимаемый код. Множественным наследованием надо пользоваться очень осторожно, когда это действительно необходимо, хотя я считаю, что его надо избегать. А в остальном visual c++ очень классная вещь, и писать надо на нём и на MFC. И как бы мы его не ругали MFC за его неповоротливость, без него нам было бы ой как трудно.

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


K>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

Вообще-то это запрещено в VCL, а не в самом Buildere. Причем только для классов, порожденных от
TObject.
А язык там всё равно C++, поэтому если кто-то чего-то хочет напуть с множественным наследованием,
то пожалуйста ;)))

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

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

K>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

Ну это напрасно. Например, концепция ATL базируется на шаблонах и множественном наследовании.

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

K>>Единственное, что мне нравиться в Builder, так это то, что там запрещено множественное наследование.

IT>Ну это напрасно. Например, концепция ATL базируется на шаблонах и множественном наследовании.

Гы-гы. И Билдер ATL содержит в своей поставке.

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

R>А если серьезно, то COM проложил небольшой мостик в этой бурной реке непримиримых стандартов. Мне лично пофиг, на чем кто-то напишет нужный компонент — пусть работает, как надо!

Вот только и на этом поприще Borland с MS умудрились найти разногласия. :) Насколько я знаю, COM от VC++ (обычный "чистый") бывает не так легко использовать у Borlanda...

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

K>...Когда пишется большой проект на visual c++, возможность множественного наследования провоцирует программистов на его использование. В результате получается много путаницы и трудновоспринимаемый код. Множественным наследованием надо пользоваться очень осторожно, когда это действительно необходимо, хотя я считаю, что его надо избегать.

Вот странно, да. Я вот вроде как написал пару-другую не слишком маленьких проектов и пока не то чтобы не слишком, а, насколько я помню, вообще не использовал множественного наследования. И не особо жалею по этому поводу. Но использовать его стоит. Вот только проектировать надо тщательно. Впрочем, это относится не только к множественному наследованию...

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

TL>Здравствуйте kaziboba, вы писали:

TL>Вот странно, да. Я вот вроде как написал пару-другую не слишком маленьких проектов и пока не то чтобы не слишком, а, насколько я помню, вообще не использовал множественного наследования. И не особо жалею по этому поводу. Но использовать его стоит. Вот только проектировать надо тщательно. Впрочем, это относится не только к множественному наследованию...

Я как-то за субботу-воскресенье набросал основные классы небольшого проекта (pure WIN api, console app) — так вышло
что без теплейтов, множественного наследования, и наследования типа C : BT<С> никак ... проекти никак не проектировался — ибо маленький и в общем-то stand alone app ...

Igor

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

TL>Здравствуйте retalik, вы писали:

TL>Вот только и на этом поприще Borland с MS умудрились найти разногласия. :) Насколько я знаю, COM от VC++ (обычный "чистый") бывает не так легко использовать у Borlanda...

Да все там легко... если знаеш все. У билдера и VC есть только одно серьзеное отличие #import в билдере реализован на столько криво, что реально его испльзовать не возможно. Все остольное обходится и залатывается, был бы опыт...

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

IS>Я как-то за субботу-воскресенье набросал основные классы небольшого проекта (pure WIN api, console app) — так вышло
IS>что без теплейтов, множественного наследования, и наследования типа C : BT<С> никак ... проекти никак не проектировался — ибо маленький и в общем-то stand alone app ...

Ну, это уже образ мышления... А насчет множественного и одиночного наследавания, так это же просто разные концепции 1-е подразумевает построение классов путем сбора под одну крышу функциональных частей, 2-е расширение возможностей базового типа данных. Вон вирт вообще без глассов обходится. Да, и теорию АТД еще ни кто не отменял...