Вопрос
Мне 13 лет. С детства писал на VB, потом батя заставил учить С++. Под руку запал Borland C++ Builder. Купил книгу А.Я. Архангельского. Мудрен язык. Много не понял. BCB со временем стал надоедать. Полез в инет. Поискал сравнения Visual C++ и BCB. Нашел codenet.ru. Оказалась у BCB мгого минусов.
А его противника расхваливают. Собираюсь пойти купить VC++. Народ, посоветуйте, может книга не та, иль VC действительно лучше.
А кто сказал, что VC лучше? Я пишу в основном в BC, и вот почему:
1) VC НЕ СООТВЕТСТВУЕТ СТАНДАРТУ!!! Многие свои программы из BC я успешно перенёс из Windows в Linux/Unix(GCC), однако с VC даже не компилируются, а при модификации возникает масса проблем. У VC даже синтаксис не во всём соответствует стандарту! Что уж говорить о библиотеках, которые в С++ с момента появления и стандартизованы и признаны давно и всеми!
2) VC ГЕНЕРИРУЕТ МЕНЕЕ ЭФФЕКТИВНЫЙ КОД, чем BC. Кто бы в чём меня не пытался убедить, я потратил много времени на сравнение временных характеристик кода, полученного этими компиляторами; я никому не верил, всё дизассемблировал и анализировал). Иногда VC полностью сводит на нет всю возможность повышения производительности средствами гибкости синтаксиса Си. Вопрос: тогда зачем нужен Си, если компилятор перечёркивает добрую половину его достоинств???
PS: BCC32.exe forever, даже при всех его глюках :)
Я тоже не фанат VC, но тебе все-таки повозражаю:
1)Синтаксис зависит от програмиста, а не от компилятора или среды разработки, никто тебе не мешает писать в VC переносимые программы.Мало какой компилятор вообще соответствует стандарту. Теже билдеровские __property ни в каой стандарт не вписываются. Хотя сейчас борланд внес проект идеологии PME в комитет по стандартизации. Так что вполне возможно что скоро __property будут стандартом. Они уже прописаны в референсе ANSI C++ 2002 вроде как.
2)Насчет эффективности кода - борланд априори не может генерировать более эффективный код, потому как эффективность кода во многом зависит от системы. А лучше MS винду никто не знает. В общем советую на этот счет поговорить с Юрой Хароном или Владом Фольцем из fido7.ru.cppbuilder
Взято из Far/WhatsNew.Rus.txt:
[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02. MSVC 6 SP4 не оправдал ожиданий (FAR 1.70 beta 1) и добавил тормозов (работа с выделением памяти для мелкими объектов).
А для выделения памяти под маленькие объекты смотри Алесандреску.
1) VC НЕ СООТВЕТСТВУЕТ СТАНДАРТУ!!!
Пустое сотрясание воздуха. Конкретные примеры в студию.
Если ты мне докажешь, что BC++ соответствует
стандарту с меня ящик пива. Ну а если я докажу обратное, то с тебя хотябы пол-ящика, согласен?
Многие свои программы из BC я успешно перенёс из Windows в Linux/Unix(GCC), однако с VC даже не компилируются, а при модификации возникает масса проблем.
Эта фраза заставляет усомниться в твоей компетентности... Примеры того, что ты хотел этим сказать, плз.
У VC даже синтаксис не во всём соответствует стандарту!
Это как? Приведи ка пример.
Что уж говорить о библиотеках, которые в С++ с момента появления и стандартизованы и признаны давно и всеми!
О каких именно библиоеках ты говоришь? CRT, STL, Boost или др.?
К твоему разочарованию могу сказать, что ни MS, ни Borland не реализовывали полностью сами эти библиотеки, а брали уже готовые, либо чуть переделывали уже готовые. Кстати, на сколько я помню, и в VC++ и в BCB используется один и тот же STL.
2) VC ГЕНЕРИРУЕТ МЕНЕЕ ЭФФЕКТИВНЫЙ КОД, чем BC. Кто бы в чём меня не пытался убедить, я потратил много времени на сравнение временных характеристик кода, полученного этими компиляторами; я никому не верил, всё дизассемблировал и анализировал). Иногда VC полностью сводит на нет всю возможность повышения производительности средствами гибкости синтаксиса
Ну это все субъективно и во многом зависит от "близости отношений и понимании" программиста и языка.
Си. Вопрос: тогда зачем нужен Си, если компилятор перечёркивает добрую половину его достоинств???
Хм-м...
Мы тут, вообще-то про, C++ говорим, а не про C.
1)Синтаксис зависит от програмиста, а не от компилятора или среды разработки
Вот это стало для меня откровением. :D
Я то думал, что синтаксис определен (т.е. и зависит) от стандарта языка.
Может ты имел в виду стиль, а не синтаксис?
Мало какой компилятор вообще соответствует стандарту.
А если быть точнее, то ни один из существующих компиляторов не соответствует стандарту на 100%. Лишь Comeau заявляет, что он очень близок к стандарту.
2)Насчет эффективности кода - борланд априори не может генерировать более эффективный код, потому как эффективность кода во многом зависит от системы. А лучше MS винду никто не знает.
Я так понял, что разговор был о компиляторах (only), так что ОС тут по большому счету не причем.
А для выделения памяти под маленькие объекты смотри Алесандреску.
Похвально, весьма похвально. Я тоже рекомендую этого автора. Только не стоит понимать его слишком буквально и пользоваться приведенными примерами (Loki) as is. Это все же примеры, технологии и рекомендации, а не жесткий, четко выверенный код.
Как вы понимаете слово "стандарт"? Если нет ни одного компилятора близкого к стандарту, то где -то этот стандарт существует в виде другого компилятора, который бы использовался. Где эти стандарты вообще находятся?
А есть такой комитет по стандартизации языка С++. Он периодически выдает рекомендации по языку. Актуальная на данный момент референция ANSI C 99 если мне память не изменяет.
Может ты имел в виду стиль, а не синтаксис?
выменно его я и имел ввиду. Просто хотел человеку сказать, что в любой среде можно написать переносимый код и непереносимый.
Похвально, весьма похвально. Я тоже рекомендую этого автора. Только не стоит понимать его слишком буквально и пользоваться приведенными примерами (Loki) as is. Это все же примеры, технологии и рекомендации, а не жесткий, четко выверенный код.
А я и не говорил непосредственно про реализацию. Насколько я помню там перед описанием реализации идет описание проблемы, объяснение что проблема не из пальца высосана.
Пустое сотрясание воздуха. Конкретные примеры в студию.
Если ты мне докажешь, что BC++ соответствует
стандарту с меня ящик пива. Ну а если я докажу обратное, то с тебя хотябы пол-ящика, согласен?
Эта фраза заставляет усомниться в твоей компетентности... Примеры того, что ты хотел этим сказать, плз.
Это как? Приведи ка пример.
О каких именно библиоеках ты говоришь? CRT, STL, Boost или др.?
К твоему разочарованию могу сказать, что ни MS, ни Borland не реализовывали полностью сами эти библиотеки, а брали уже готовые, либо чуть переделывали уже готовые. Кстати, на сколько я помню, и в VC++ и в BCB используется один и тот же STL.
Ну это все субъективно и во многом зависит от "близости отношений и понимании" программиста и языка.
Хм-м...
Мы тут, вообще-то про, C++ говорим, а не про C.
Вот это стало для меня откровением. :D
Я то думал, что синтаксис определен (т.е. и зависит) от стандарта языка.
Может ты имел в виду стиль, а не синтаксис?
А если быть точнее, то ни один из существующих компиляторов не соответствует стандарту на 100%. Лишь Comeau заявляет, что он очень близок к стандарту.
Я так понял, что разговор был о компиляторах (only), так что ОС тут по большому счету не причем.
Похвально, весьма похвально. Я тоже рекомендую этого автора. Только не стоит понимать его слишком буквально и пользоваться приведенными примерами (Loki) as is. Это все же примеры, технологии и рекомендации, а не жесткий, четко выверенный код.
1. В VC даже C Runtime, который в большинстве аспектов идентичен аналогичному в Unix не соответствует стандарту, а ведь чистый Си появился ещё в 70-х и он практически полностью стандартизован и признан всеми. BC в этом отношении больше соответствует стандарту.
А что сказать даже о банальных stream'ах C++, которые даже в разных ОС ведут себя практически одинаково, а в VC противоречат всем остальным.
2. Об эффективности: как бы MS ни знала свои ОС, но ОС тут как раз-таки не при делах. VC генерирует более громоздкий код даже в простейших случаях (анализировать надо размер отдельных участков кода, а не exe'шника в целом). Многие виды оптимизации кода, которые производит сам программист, используя Си просто сводятся на нет. Банальный пример: у меня 6-ой VC для операции типа a+=b (a,b - register) вместо
add [рег1],[рег2] ; BC Debug/Release
генерирует что-то вроде
mov [рег3],[рег1] ; =
add [рег3],[рег2] ; = VC 6 Debug/Release
mov [рег1],[рег3] ; =
Оптимизация программиста летит в окно :-(((
3. О чём бы мы не говорили (С или С++), а программы просто не могут состоять только из вызовов функций бибилотек, поэтому если код генерируется неэффективный, то никакие библиотеки не позволят эффективно исполнить базовый алгоритм, разработанный программистом.
А есть такой комитет по стандартизации языка С++. Он периодически выдает рекомендации по языку. Актуальная на данный момент референция ANSI C 99 если мне память не изменяет.
А можешь сказать ресурс, где все это находится?
И почему никто не хочет, делая компиляторы, полностью соответствовать стандарту? Наверно же есть на это причины.
Банальный пример: у меня 6-ой VC для операции типа a+=b (a,b - register) вместо
add [рег1],[рег2] ; BC Debug/Release
генерирует что-то вроде
mov [рег3],[рег1] ; =
add [рег3],[рег2] ; = VC 6 Debug/Release
mov [рег1],[рег3] ; =
Оптимизация программиста летит в окно :-(((
А почему тогда программы на VC меньше по размеру, можешь объяснить?
есть строка:
"Пакет C++BuilderX существенно облегчает перенос приложений на новые или унаследованные платформы за счет использования нового компилятора, который на 100% удовлетворяет требованиям стандартов ANSI/ISO C++ и C99."
1. В VC даже C Runtime, который в большинстве аспектов идентичен аналогичному в Unix не соответствует стандарту, а ведь чистый Си появился ещё в 70-х и он практически полностью стандартизован и признан всеми. BC в этом отношении больше соответствует стандарту.
А что сказать даже о банальных stream'ах C++, которые даже в разных ОС ведут себя практически одинаково, а в VC противоречат всем остальным.
Причем тут ОС и stream? Какие именно stream-ы ты имеешь в виду?
Конкретные примеры противоречия?
Не хочу переходить на личности, но твой стиль изречения похож на стиль политиков советского и перестроечного времени: сплошные лозунги и ни какой конкретики. Без обид, ок?
Мне самому интересно, какие противоречия ты нашел.
Я знаю лишь один ляпус:
<math.h>
#define sinl(x) ((long double)sin((double)(x)))
и др. мат.функции с long double
Банальный пример: у меня 6-ой VC для операции типа a+=b (a,b - register) вместо
add [рег1],[рег2] ; BC Debug/Release
генерирует что-то вроде
mov [рег3],[рег1] ; =
add [рег3],[рег2] ; = VC 6 Debug/Release
mov [рег1],[рег3] ; =
Оптимизация программиста летит в окно :-(((
Приведи, плз, пример кода и параметры компиляции, а то я что-то не могу повторить твой пример для проверки.
3. О чём бы мы не говорили (С или С++), а программы просто не могут состоять только из вызовов функций бибилотек, поэтому если код генерируется неэффективный, то никакие библиотеки не позволят эффективно исполнить базовый алгоритм, разработанный программистом.
Эффективность генерируемого кода - понятие специфичное для конкретной задачи.
Например, известно, что применение шаблонов в большинстве случаев увеличивает размер генерируемого кода, но на то он и язык высокого уровня, чтоб дать возможность оптимального соотношения времени разработки и расхода ресурсов.
А почему тогда программы на VC меньше по размеру, можешь объяснить?
ОТВЕТ ПРОСТ: оценка размера кода, сгенерированного компилятором, по размеру EXE'шника не совсем корректна (и даже совсем не корректна). В EXE'шнике находятся также вспомогательные функции, для каждого компилятора различные. А что уж говорить о компиляторах с такой различной идеологией и подходами, как VC и BC? Код BC также содержит формы (DFM-бинарники, но громоздкие) в секции ресурсов и др, чисто Borland'овские Lib'ы, Obj'ы и др.
И ГЛАВНОЕ. Размер кода надо оценивать не по всему EXE'шнику, а по конкретному фрагменту кода, сгенерированного компилятором для вполне определённого участка кода, старательно набранного программистом. Именно и это более важно для эффективности. А на больших проектах (ОООЧЕНЬ больших) весь мусор, добавляемый BC мало влияет даже на общий размер EXE'шника.
КРОМЕ ТОГО, ради справедливости замечу, что EXE'шники BC можно сделать значительно компактнее, если использовать только динамическое связывание (получается не больше чем у VC).
Причем тут ОС и stream? Какие именно stream-ы ты имеешь в виду?
Конкретные примеры противоречия?
Не хочу переходить на личности, но твой стиль изречения похож на стиль политиков советского и перестроечного времени: сплошные лозунги и ни какой конкретики. Без обид, ок?
Мне самому интересно, какие противоречия ты нашел.
Я знаю лишь один ляпус:
<math.h>
#define sinl(x) ((long double)sin((double)(x)))
и др. мат.функции с long double
Приведи, плз, пример кода и параметры компиляции, а то я что-то не могу повторить твой пример для проверки.
Эффективность генерируемого кода - понятие специфичное для конкретной задачи.
Например, известно, что применение шаблонов в большинстве случаев увеличивает размер генерируемого кода, но на то он и язык высокого уровня, чтоб дать возможность оптимального соотношения времени разработки и расхода ресурсов.
Привожу 2 примера того, как мою программу (по всем понятиям переносимую, соответствующую стандарту), написанную в BC и с незначительными модификациями перенесённую в Linux, пришлось долго переделывать под VC:
1. Отстутствие throw исключений в предписанных стандартом случаях (в частности, new);
2. Отсутствие возвращения нулевого значения при неуспешном открытии fstream'а [if (!some_fstream) {}... не пашет].
PS: А с (long double) из double двух десятков функций двойной точности math.h верно подмечено ;-)))
Я полностью согласен, что эффективностью можно пожертвовать во имя удобства и простоты (сам не без греха, а что уж вспоминать за STL), но ведь эффективность - одно из главных достоинств C/C++, и мне она часто бывает важна.
Я ничего не имею против VC, но как раз-таки с ним у меня больше всего проблем перенорсимости (в т.ч. из ОС в ОС). И в критичном к быстродействию программировании я получаю более быстрый код в BC , в связи с чем предпочитаю BC.
И ГЛАВНОЕ. Размер кода надо оценивать не по всему EXE'шнику, а по конкретному фрагменту кода, сгенерированного компилятором для вполне определённого участка кода, старательно набранного программистом.
Различные фрагменты могут быть оптимизированны различными компиляторами по-разному. Один компилятор лучше оптимизирует одни "обороты", другой - другие. Так что об оптимизации вцелом говорить не имеет смысла.
Приведи конкретные примеры кода с параметрами компиляции.
Именно и это более важно для эффективности.
Что ты подразумеваешь под эффективностью? Критерии эфективности?
А на больших проектах (ОООЧЕНЬ больших) весь мусор, добавляемый BC мало влияет даже на общий размер EXE'шника.
КРОМЕ ТОГО, ради справедливости замечу, что EXE'шники BC можно сделать значительно компактнее, если использовать только динамическое связывание (получается не больше чем у VC).
При чем тут динамическое связывание, если мы говорим о компиляторах?
Привожу 2 примера того, как мою программу (по всем понятиям переносимую, соответствующую стандарту), написанную в BC и с незначительными модификациями перенесённую в Linux, пришлось долго переделывать под VC:
Может, надо было всего-лишь использовать другой STL?
1. Отстутствие throw исключений в предписанных стандартом случаях (в частности, new);
Что-то я под конец рабочего дня стал плохо врубаться. Что ты имел в виду? Пример кода привести можешь?
2. Отсутствие возвращения нулевого значения при неуспешном открытии fstream'а [if (!some_fstream) {}... не пашет].
У меня пашет... :о\
Ты какой STL использовал? Я использую STLPort.
Мы говорили вроде бы о компиляторе, STL к нему не имеет прямого отношения.
Я Visual C++ .NET установил. Написал Hello, World! на консоли. Так вот это приложение работает намного медленее, чем аналогичное на билдере.
:D :D :D
Серьезный аргумент!
P.S. "Может что-то в консерватории подправить?"
Для того, чтобы new кидал исключение в VC, достаточно включить любой заголовок из STL, хотя бы <new>, что соответствует стандарту.
Всё работает.
Гы-гы :D