Они что ? В серьез думают, что их бездарную поделку будет кто-то покупать на "родной" платформе GCC ? (ну Killyx - еще могу понять, школьников и c00l l33t haXorZ всегда хватало)

Речь о C++ вообще-то ... GCC с C++ - не самая лучшая парочка вроде как ...

> Речь о C++ вообще-то ... GCC с C++ - не самая лучшая парочка вроде как ...

В C++Builder он еще хуже.

Злые языки утверждают, что С++ в GCC 3.x уже не так плох, как раньше. Как именно он хорош - я не знаю...:)

>Злые языки утверждают, что С++ в GCC 3.x уже не так плох, как раньше. Как именно он хорош - я не знаю...:)

>svu (*) (2002-01-25 13:55:53.0)

Говорят, что он как-бы реализует то, о чем написано в третьем издании
Страуструппа :))

А чем, собственно, плохо, если под Линух появится еще один компилер C++?

как бы то ни было GNU C++ активно лечится, а билдер - его только могила исправит.

Разговор не о добре и зле, а о бессмысленности затеи ;)

когда линух рождался, тоже наверно куча народу пожимало плечами и говорило "а на хрена?"...

Когда Borland начинал Kylix, кто-то из их менагеров сказал: Linux is about choice. И, мне кажется, это правильно (хотя бы частично - Linux is about many different thing, you know...:). Исходя из этой точки зрения, n+1 компиляторов - лучше, чем n.

2maxcom:
> В C++Builder он еще хуже.
да я бы не сказал. по заявлению самого борланда - полностью поддерживает ANSI, и по опыту работу - глюков в самом компилере не было.
сейчас скачал, прогнал тест с шаблонной ф-цией (чего нет в VC) - все работает.
есть у когонибудь ссылочка на полные тесты на совместимость для основных компилеров С++?

Qrot

Borland C/C++ очень даже неплохой компилер, а если они еще и C++ Builder перенесут под линух, вообще рулез будет.
В качестве теста напиши чего-нибудь с использованием stl, gcc при этом стандартно сходит с ума.

Ну все. Огр не успел затоптать Борланд, а они чего начали творить? Ревеню на 17% в четвертом квартале подняли, не в последнюю очередь за счет джавы и линуха:

http://www.borland.com/about/press/2002/4q01.html

Самое интересно там в complete release (pdf). Делают бизнес на cross-platform compatibility между линухом и виндоз(ТМ), понимаешь. Блюзмена на них нет.

>Borland C/C++ очень даже неплохой компилер, а если они еще и C++
>Builder перенесут под линух, вообще рулез будет.
Рулез будет если Вальтер Брайт свой DigitalMars под линь перенесет (Zortech C++ also known as Symantec C++ кто-нибудь помнит ?)
>В качестве теста напиши чего-нибудь с использованием stl, gcc при
>этом стандартно сходит с ума.
Я что-то не втыкаю, а где взять STL для GCC ? Да и потом, многие предпочитают использовать свои библиотеки.

2devil

Постоянно пишу с использование stl (на gcc c 2.7)

В любом linux-дитре достаточно программ использующих stl

Никаких проблем не видел,
можеть проблема в ручках :))))

Что за туфта, дружище. Когда это GCC сходил с ума от STL? libstdc++ -- отличная реализация. Дрючу каждый день, кстати, и Дебилдер и GCC. Препочтения в пользу последнего.

BC - mustdie, Borland - mustdie, у них даже под DOS не было нормального компилера, под DOS лучшим был ватком а за ним симантек, я считаю что борланду вобще нефиг Ц трогать, пусть паскаль ваяют, а на счет того, что речь идет не о Ц, а о Ц++, какой нафиг может быть Ц++ без нормальной реализации Ц?
Вот, лично мое мнение, никому не навязываю.

И вообще, меня борланд в детстве обидел, мой первый тысячестрочный проект убил :( , паскуда.

>И вообще, меня борланд в детстве обидел, мой первый тысячестрочный проект убил :( , паскуда.

Бедный мальчик, не научили его папа с мамой бэкапы вовремя делать ;-)

2Qrot: Посмотри на http://www.boost.org, там есть тесты, показывающие насколько хорошо компилируется boost на различных компиляторах. Штука это мощная и я думаю по этим тестам можно судить и о компиляторе

DigitalMars (ili D ono teper nazyvaetsya) perenosit poka nekuda - compilera net voobshe :) Nado govorit ne perenesut a napishut :)
A voobshe ya posmotrel na spec. D nu kak-to ne lezhit k nemu dusha..
I potom preprocessor v nem vykinuli - a mezhdu prochim ochen poleznaya vesh byla ! chtoby ni govorili.

В Норвегии осужден Йон Йохансен

даа... РедХат не смог уничтожить линукс с gcc 2.96, так багланд взялся за это... одно радует, что не так-то много под линух пишется на C++

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

2ZhekaSmith: "Огр не успел затоптать Борланд, а они чего начали творить? Ревеню на 17% в четвертом квартале подняли, не в последнюю очередь за счет джавы и линуха:"
При этом доходы упали на 26% Way to go....
http://biz.yahoo.com/rf/020124/n24313789_1.html

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

> по заявлению самого борланда - полностью поддерживает ANSI, и по опыту работу - глюков в
> самом компилере не было.

Народ, вы не понимаете самого главного. СиДеБидер позиционируется не просто как компайлер!!!
Если б он был просто компайлером, то и в этом случае GCC его за пояс заткнет.
Но ведь рекламируется как универсальная среда быстрой разработки приложений,
в-основном GUI, с использованием баз данных. А что такое борландовское BDE?
Это глюк на глюке и глюком погоняет. Одностраничный отчет без притязаний сляпать
на нем вроде можно, но в винде гораздо проще сделать это на VB, а в юниксах на tcl/tk.

2lb.
> ни один борландовский компилер еще ниразу
> не смог сделать нормально работающее приложение
> с использованием динамической памяти
А какое отношение имеет компилятор к динамической памяти?
В С/С++ за корректность обращения с динамической памятью отвечает программист.

Для тех, кто говорит "ни разу", "никогда", и т.п.
Borland не всегда была такой. Качество их продуктов достаточно долго было на высоте. Пока из-за плохой маркетинговой политики (насколько мне известно) компания чуть не обанкротилась. Сменилось руководство, ушло много хороших программистов. Потом Borland перестала существовать (стала подразделением Inprise). Мне их искренне жаль.
Под DOS у них была лучшая среда разрабоки для С/С++, IMHO. Их TASM и по сей день - наилучшее средство для асм-программера (for DOS/Win only, увы). Единственный баг, с которым я в нем столкнулся - некорректное размещение макроса в 32-битном сегменте кода в версии 3.1 (выпущенной где-то в 92г.). В следующей версии его пофиксили. Ну еще проблема с переходом из 16-разрядного сегмента в 32-разрядный, используя 16-разрядные селектор и смещение, из-за чего приходилось после
mov eax,cr0
or al,1
mov cr0,eax
делать
db 0EA
dw small offset start32
dw offset code32selector
вместо простого
jmp far code32selector:start32
А по скорости трансляции TASM пока еще никто не догнал. Конечно, нынешняя Borland - не та, что делала TC++ 1.0 и BP 6.0. Но говорить, что они всегда делали отстойные инструментальные средства - нехорошо.

nobody, а как объяснить что одна и та-же прога, совершенно по разному ведет себя скомпилированая BC[2|3], TCPP (в плане проблем с памятью) и 4 года без единого сбоя отработавшая будучи откомпилированой на Watcom ?

здесь, безусловно, прекрасный брландовский компилер не при чем.

PS. ошибке в трансляторе ASM это вообще :) лучшего варианта сказать "борланд отстой" придумать сложно :)

2nobody: возьми nasm и ни в чем себе не отказывай :) серьезно, лучший асемблер для x86, и синтаксис интельный и правила имхо гораздо проще/логичнее, чем у любого другого x86 асемблера... gas не предлагать --- >10 лет привычке :)

по поводу собственно борланда имхо они всегда славились своей оболочкой и отстойным кодогенератором(особенно для 32битного кода), а также странным отношением к стандартам языка/библиотек... видимо дурной пример большого брата M$

в общем все как обычно, или быстро ваять или хороший результат :)

меня прикалывает то что все говорят о C++ и gcc как одно и то же - НО как насчет g++ ? или просто ПРАВИЛЬНО использования gcc опций ?

Что и имею в виду когда говорю "ПРАВИЛЬНОГО" - гы - по умолчанию gcc без опций - по определению не правильно юзает STL например - в отличии от g++ без опций - а что многие используют доп опции ??

И это - когда говорят "зачем" я что то не пойму - это от Вас что ли зависит "зачем" ?????? Или Вы готовы помочь в чем то , например Borland'у ??? :D

2anonymous(2002-01-26 02:46:13.0): соврамши вы, батенька :)

1. вы, батенька, в курсе, что gcc сам по себе ничего не делает, а на C-код пускает cc1 ? аналогично на C++ код.

2. имеючи очевидный hello.c и hello.cc имеем: gcc --verbose -c hello.cc Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011006 (Debian prerelease) /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.cc /tmp/ccnkUduo.ii GNU CPP version 2.95.4 20011006 (Debian prerelease) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3 /usr/local/include /usr/lib/gcc-lib/i386-linux/2.95.4/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include End of omitted list. /usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/ccnkUduo.ii -quiet -dumpbase hello.cc -version -o /tmp/ccQukfrF.s GNU C++ version 2.95.4 20011006 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011006 (Debian prerelease). as -V -Qy -o hello.o /tmp/ccQukfrF.s GNU assembler version 2.11.92.0.12.3 (i386-linux) using BFD version 2.11.92.0.12.3 20011121 Debian/GNU Linux

g++ --verbose -c hello.cc Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011006 (Debian prerelease) /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.cc /tmp/ccquE7Dp.ii GNU CPP version 2.95.4 20011006 (Debian prerelease) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3 /usr/local/include /usr/lib/gcc-lib/i386-linux/2.95.4/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include End of omitted list. /usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/ccquE7Dp.ii -quiet -dumpbase hello.cc -version -o /tmp/ccKW3QSH.s GNU C++ version 2.95.4 20011006 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011006 (Debian prerelease). as -V -Qy -o hello.o /tmp/ccKW3QSH.s GNU assembler version 2.11.92.0.12.3 (i386-linux) using BFD version 2.11.92.0.12.3 20011121 Debian/GNU Linux

теперь найди 7 отличий.

PS. может батенька просвятит нас непосвященных, на предмет "ПРАВИЛЬНО использования gcc опций" ?

PPS. _любой_ проект > чем "hello, world!" использует "доп опции" хотя хбз дополнительные к чему :Р

> В качестве теста напиши чего-нибудь с использованием stl, gcc при этом стандартно сходит с ума.

фигню гоните про stl; пишу давно, проблем не видел, особенно с новыми gcc (типа 2.96 )...

Да и куда им тягаться с Intel или KAI...

Так то не багланд виноват, а твои кривые ручки. Надо же додуматься - асм в Си вставлять...

>нормальный компилер был оччень затрудителен из-за огромного количества асмовых вставок, а

Вообще-то С для того и создали, чтобы асмой не страдать. Или ты был в команде по написанию чего-то типа Doom-][ и оптимизировал наиболее ресурсоемкие участки?

2nCryer: Тысячестрочный проект на Си переписывается за _один_ день. Вместе с отловом ошибок. Асмовые ставки всегда выносились в .asm, бо нефиг. А лучше нафиг. Для проверки корректности _своего_ кода всегда лучше иметь несколько разных компилеров, чтобы между ними проверить насколько у тебя совместим/переносим и вообще правилен код. Во времена DOS я стабильно пользовал Watcom C + Zortech C + TopSpeed C + Borland C, некоторые ошибки в программе находились именно благодаря использованию разных компилеров. Ладно, культура программирования на Си приходит с годами, может к тебе еще придет.

2lb.
> nobody, а как объяснить что одна и та-же прога,
> совершенно по разному ведет себя скомпилированая
> BC[2|3], TCPP (в плане проблем с памятью)
> и 4 года без единого сбоя отработавшая
> будучи откомпилированой на Watcom ?
Объясняется это, по-видимому, использованием разных библиотек (разных версий libc от разных производителей). Даже если ты возьмешь одного и того же производителя (например, FSF), то в разных версиях libc найдешь разные баги (потому что старые фиксятся, а новые - добавляются). Возможно, ты столкнулся с каким-то багом, связанным с распределением динамической памяти, который проявляется при сочетании (редко встречающемся) определенных условий. Что это за баг, я сказать не могу, т.к. сам с ним не сталкивался. Зато могу совершенно точно сказать, что компилятор здесь не при чем (возможно, ты, говоря "компилятор", имел в виду IDE в целом?).

> PS. ошибке в трансляторе ASM это вообще :)
> лучшего варианта сказать "борланд отстой"
> придумать сложно :)
Ошибки есть в любой достаточно большой и сложной программе (за ну очень уж редким исключением). Дело не в их наличии. Важнее то, насколько часто они проявляются и насколько страшны. И еще немаловажна оперативность их устранения. Так вот, та ошибка в TASM 3.1, о которой я говорил, проявляется исключительно редко. Только в том случае, если ты пишешь операционную систему или что-то типа того (вспомни, в 92г. еще не были широко распространены 32-разрядные ОС на x86). И при этом хочешь использовать повторяющийся макрос для создания таблицы в сегменте 32-разрядного кода.

2anonymous (*) (2002-01-26 00:33:30.0).
Да я, в общем-то, не спорю, что под линуксом NASM - лучший транслятор. Сам его юзаю (куда деваться?). Но некоторые его баги (которые авторы называют фичами) все же раздражают. И, будь у меня выбор, предпочел бы TASM.

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

Ну а писать на ассемблере, да ешё с уродским интелевым синтаксисом - просто позор и извращение. Нормальный человек постеснялся бы в приличном обществе упоминать о столько неприглядном этапе своей карьеры.

Максимализм обычно проходит с годами. Когда повзрослеешь и перестанешь повторять чужие глупости, тогда и поговорим.

To master (*) (2002-01-25 20:35:23.0):

>DigitalMars (ili D ono teper nazyvaetsya) perenosit poka nekuda -
>compilera net voobshe :) Nado govorit ne perenesut a napishut :)
Я не о языке D, D он уже лет наверно 7 пишет, и напишет ли - не известно ;)
Я имел ввиду его C++ компилятор, который уже в 3й раз меняет имя: Zortech C++, Symantec C++ и вот теперь Digital Mars C++.
>A voobshe ya posmotrel na spec. D nu kak-to ne lezhit k nemu dusha..
>I potom preprocessor v nem vykinuli - a mezhdu prochim ochen
>poleznaya vesh byla ! chtoby ni govorili.
Не стану спорить ;) Чем-то мне этот D джаву напоминает, и думается, что такой матёрый девелопер компиляторов как Брайт напишет всяко лучше, чем наляпала Sun во времена своего кризиса в этой области ;)

Qrot: что ты имел в виду про шаблонную функцию? BC++ что ли "export" поддерживает? В смысле, код не в хидере?

Типично флеймерский ебанутый приёмчик - взбзднуть не о чём, но чтоб показаться умным. Ты давай, ламеришко, рассказывай, в какую лужу тебя ещё посадить. А то тут давно клоунады не было.

лМНЦН КЕР ОХЬС МЮ C/C++ ЕЫЕ ЯН БПЕЛЕМ DOS.Turbo C ЧГЮЧ Я БЕПЯХХ 1.0.
оН ЯПЮБМЕМХЧ Я Microsoft,Watcom,Zortech ЙНЛОХКЪРНПШ Borland АШКХ
ЯЮЛШЛХ ЦКЧВМШЛХ.цКЧВМШИ ЙНДНЦЕМЕПЮРНП.с ЛЕМЪ ЕЯРЭ РЕЯРНБЮЪ ОПНЦПЮЛЛЮ,
ЙНРНПЮЪ ОПХ ЙНЛОХКЪЖХХ Borland C Я ОНКМНЯРЭЧ БЙКЧВЕММНИ НОРХЛХГЮЖХЕИ
ПЮАНРЮЕР Б 2 ПЮГЮ ЛЕДКЕММЕЕ,ВЕЛ АЕГ НОРХЛХГЮЖХХ.цЕМЕПХПСЕЛШИ ЙНД
ХГАШРНВЕМ,КХЬМХЕ НОЕПЮЖХХ ГЮЦПСГЙХ.нЬХАЙХ Б RTL ЛМНЦНЙПЮРМН
НАМЮПСФХБЮК ЯЮЛ.рЮЙНЕ БОЕВЮРКЕМХЕ,ВРН Turbo C ДЕКЮКХ ЯРСДЕМРШ,
Ю ГЮРЕЛ БЯЕ ЦКЧЙХ ОЕПЕЬКХ Б ЯРЮПЬХЕ БЕПЯХХ.бННАЫЕ,ОЕПБШИ Turbo C
АШК ЙСОКЕМ аНПКЮМДНЛ С ДПСЦХУ ПЮГПЮАНРВХЙНБ.дЮ Х Borland Pascal
АШК МЕ ЛЕМЕЕ ЦКЧВМШЛ.оПНДСЙРШ аНПКЮМД ОПНЯРН АШКХ АНКЕЕ
КЕЦЙХЛХ ДКЪ ХГСВЕМХЪ,НРЯЧДЮ Х ОНОСКЪПМНЯРЭ.