Исследования показали, что пользователи Linux'a смогут стать опять приверженцами Windows.

2solom:

Я -- не о том. Вы затрагиваете совершенно другую тему, которая,
правда, здесь сейчас интенсивно обсуждается. Я лишь утверждаю,
что ИДЕАЛЬНО написанная программа на C ВСЕГДА меньше и быстрее,
чем ТАКАЯ ЖЕ по функциональности программа, написанная на C++.

И чем сложнее программа, тем больше выигрывает C.

Всем, кто хочет спорить: не пропускайте мои слова "ИДЕАЛЬНО
написанная". Хотя я уверен, что при одинаковом уровне интеллекта
программировать на C проще, чем на C++, тем не менее для удачного
использования чистого C требуется некая общепрограммистская культура,
в настоящее время отсутствующая у 99% программистов. Поэтому
спор C vs. C++ в том смысле, что содержится в реплике solom'а,
не представляется мне конструктивным.

Flawer

P.S.
> В любом случае С++ облегчает написание БОЛЬШИХ проектов

BTW, мой опыт говорит об обратном: написанные на C большие проекты
кажутся мне значительно более изящными, чем C++ аналоги.

Ха. Вот на тему "фотошоп" как раз весьма забавно - думаю, без guile этот самый GIMP до сих пор был бы полнейшей pre-alpha.

Редактор - это не та задача, где стоит "что-нибудь своё" сочинять. Это же детский сад, "hello, world"...

Это сугубо личное мнение, с мнениями трудно спорить. Я думаю, что написать нормальный редактор стоит больше усилий, чем написать хелловорлд. Но это не относится к сути вопроса.

To Flawer:
> Я лишь утверждаю,
>что ИДЕАЛЬНО написанная программа на C ВСЕГДА меньше и быстрее,
>чем ТАКАЯ ЖЕ по функциональности программа, написанная на C++.

A ya lish' utverzhdau, chto eto utverzhdenie ni stoit ni centa. Hotya bi potomu, chto pri gramotnom ispol'zovanii run-time izderzhki C++ -- minimal'ni. I Vash primer s "hello-world" zdes' ne katit -- edinstvennoe, chto on pokazivaet, tak eto to, chto realizaziya concretnoi function "puts" v konkretnoi biblioteke bistree, chem realizaziya streams. No blin, nashli chto sravnivat'. Eto tozhe samoe, chto sravnit', k primeru vremya vipolneniya 1000000 add i vremya vipolneniya takogo zhe kolichestva slozhenii zelih proizvol'noi dlini.
Hint: sravnivaite ne puts i ostream. A voz'mite, k primeru printf s bolee-menee normal'noi formatnoi strokoi (nu, hot' stroka+double+int) -- nado zhe imet' hot' kakuu-to equivalentnost'-- i sootvetstvuushii variant vivoda v std::cout -- i provedite Vash zhe strannii test -- i poglyadite na rezul'tati. Chto lishnii raz pokazhet bessmislennost' podobnih sravnenii.

> не менее для удачного использования чистого C требуется некая общепрограммистская культура,

Nu da, C --yazik dlya "nastoyashih" programmistov, a vse ostalnie -- lamers, ne imeushie "obsheprogrammistskoi kulturi". Eta samaya kultura, navernoe, proyavlyaetsya v Obfuscated C.

P.S.: Sleduya Vashei zhe logike, mozhno skazat', chto ideal'naya programma na ASM'e budet bistree, chem programma na lubom yazike programmirovaniya, realizuushaya takoi zhe algorithm. Mozhet bit', i budet -- no skol'ko v nei budet oshibok, i skol'ko vremeni na nee uidet.

2 anonymous (*) (2001-06-01 19:10:57.0)
>Ха. Вот на тему "фотошоп" как раз весьма забавно - думаю, без guile 
>этот самый GIMP до сих пор был бы полнейшей pre-alpha.

guile - это средство прикручивания лиспа к проге.
Без него в ГИМПЕ небыло бы script-fu

2 Flawer:
Прислушайся к AC - верно говорит. Могу от себя добавить 
по секрету (только никому не говори): любая прога, написанная на 
ассемблере будет всегда быстрее той, что написана на любом из 
языков...

2solom: "любая прога, написанная на ассемблере будет всегда быстрее той, что написана на любом из языков"
По секрету тебе скажу - в теории это так, а вот на практике надо добавить "при ничем не ограниченном времени и трудозатратах на оптимизацию"... Опять же - попиши на ассемблерах для RISC... Скорей всего прога, написанная на ассемблере будет медленней написаной на любом другом языке... Дело в том что ручками оптимизировать упаришся, а компилятор это сделает легко и просто...:)

2Irsi: Дык речь и идет о ИДЕАЛЬНО написанной программе. На асме вообще многое видится по-другому. И построения программ несколько иные. В свое время асм считался чуть ли не писком крутизны. Помню игрушку, которая еще на 286-ой шла про самолет, который бомбит тучу монстров - так она вся на асме написана. А написание игрушек - это вообще своя ниша программирования. Там столько хитростей в плане оптимизации. Сейчас с этим-то полегче - вышло много библиотек, которые всякую всячину берут на себя, а в те времена, когда писали под VGA - адаптер было конечно что-то.

2solom: дык, я помню... но сам понимаешь - под современные процы писать на асме это пустая трата времени...:)

2AC:
> edinstvennoe, chto on pokazivaet, tak eto to, chto realizaziya
> concretnoi function "puts" v konkretnoi biblioteke bistree, chem
> realizaziya streams.
Ну, не надо лукавить;). Первый пример представлял собой как раз В
ТОЧНОСТИ одинаковые программы, оттранслированные одним и тем же
компилятором => использующие ОДНИ И ТЕ ЖЕ системные вызовы.
Второй пример был, конечно, не совсем корректным, но был призван
проиллюстрировать идею "правильности" программирования (пример-то
был почти из Страуструпа, так же, как и первый вариант -- почти из
Кернигана и Риччи!)

> Hint: sravnivaite ne puts i ostream. A voz'mite, k primeru printf s bolee-menee normal'noi formatnoi strokoi (nu, hot'
> stroka+double+int) -- nado zhe imet' hot' kakuu-to equivalentnost'-- i sootvetstvuushii variant vivoda v std::cout -- i
> provedite Vash zhe strannii test -- i poglyadite na rezul'tati.
БЛЕСТЯЩЕ!!!

Сначала небольшая ремарка:
Я сравнивал puts с ostream, конечно, не совсем корректно: puts не
делает ни какого форматирования, а ostreams вынужден хотя бы
преобразовывать различные типы в строку. С другой стороны, функция
format, конечно, ОЧЕНЬ навороченная для того, чтобы быть быстрой --
она же ФОРМАТИРУЕТ!!!

Ok, сравниваем:

%%%%%%%%%%%%%%% hello.cpp %%%%%%%%%%%%%%%%%%%%%%%%%
#include <stream.h>

int main (void)
{
int i,j=2;
float f=1.1;
for(i=0; i<1000000; i++)
cout << form("Hello,world! %d, %f\n" ,j,f);
return(0);
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%% hello.c %%%%%%%%%%%%%%%%%%%%%%%%%
#include <stdio.h>

int main (void)
{
int i,j=2;
float f=1.1;
for(i=0; i<1000000; i++){
printf("Hello,world! %d, %f\n" ,j,f);
}
return(0);
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
g++ -o hellocpp helloc.cpp ; gcc -o helloc helloc.c

Честно?

Результат:
ls -l helloc hellocpp
-rwxr-xr-x 1 user users 11473 Jun 1 21:14 helloc
-rwxr-xr-x 1 user users 12258 Jun 1 21:15 hellocpp

time hellocpp >/dev/null
real 0m4.265s user 0m4.160s sys 0m0.030s

time helloc >/dev/null
real 0m2.755s user 0m2.710s sys 0m0.010s

Как, впечатляет??

> Nu da, C --yazik dlya "nastoyashih" programmistov, a vse ostalnie --
> lamers, ne imeushie "obsheprogrammistskoi kulturi".

Я так не говорил.

Ок, подробнее:
IMHO, ОБЩАЯ логическая структура C++ программы обычно прозрачнее,
чем у аналогичной C программы. Платой за это является "тормознутость"
и сложность улавливания тонких ошибок.

Это позволяет В ПРИНЦИПЕ писАть на C++ более сложные программы
"безкультурно", т.е., "ваять" их прямо в компьютер с помощью какого -
нибудь RAD билдера -- многие "тонкие" ошибки не возникают при таком
подходе, и (логическая) структурированность генерируемой программы
позволяет как - нибудь ее "допинать".

К сожалению, последние лет 6 люди так и делают. И C++ не спасает
от того, что мы видим -- всякие альфы- беты- гаммы релизы; дошло до
того, что общепринятой точкой зрения стало -- "не бывает программ без
ошибок!" (!!!)

Уверяю Вас, бывают! Небезысвестный (Вам, надеюсь) Кнут пообещал некую
сумму тому, кто найдет ошибку в его Метафонте -- лет 15 назад дело
было! Никто ж не нашел!

> Sleduya Vashei zhe logike, mozhno skazat', chto ideal'naya programma na ASM'e budet bistree, chem programma
> na lubom yazike programmirovaniya, realizuushaya takoi zhe algorithm. Mozhet bit', i budet -- no skol'ko v nei budet
> oshibok, i skol'ko vremeni na nee uidet.

Правильно!
Проблема в переносимости и, действительно, "накладных расходах" --
разработка программ на ASM'е не настолько увеличит производительность
(по сравнению с C), чтобы игра стоила свеч -- тем более в свете
переносимости. BTW, именно то, что UNIX был написан на C, а не на
ASM'е, и обеспечило его популярность.

Резюме: язык C стал тем водоразделом, что отделил ASM от
специализированных языков "сверхвысокого" уровня, типа SQL, или
Reduce, или PostScript, etc.

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

Flawer.

2 solom:
Ха!
Чуть ли не впервые согласен с Irsi!!!

Flawer

2AC(2001-06-01 20:13:17.0)
Извиняюсь,

Я опять был не совсем корректен в тесте.

По новой:
Файл "hello.cpp" остался тем же, а файл "hello.c" стал таким:
%%%%%%%%%%%% hello.c %%%%%%%%%%%%%%%%%%%%%
#include <stdio.h>

int main (void)
{
int i,j=2;
char buf[80];
float f=1.1;
for(i=0; i<1000000; i++){
sprintf(buf,"Hello,world! %d, %f\n" ,j,f);
puts(buf);
}
return(0);
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Результат чуть скромнее:
time hellocpp >/dev/null
real 0m4.221s user 0m4.100s sys 0m0.030s

time helloc >/dev/null
real 0m3.421s user 0m3.370s sys 0m0.000s

Flawer

To Flawer:
Esli ne sekret, u Vas kak s C++ -- minimal'nie znaniya imeutsya??
Chto eto za bred:
----------------------------------------------------------------
for(i=0; i<1000000; i++)
cout << form("Hello,world! %d, %f\n" ,j,f);
return(0);
-----------------------------------------------------------------
U Vas chto, deistvitel'no gripp? Kakoi-takoi form, kakie naher formatnie stroki v ostream C++????? Vi, tipa, izdevaetes' ili v samom dele ne v kurse??
A slabo napisat':
for(unsigned int i=0;i<10000000;++i) {
std::cout << "blablablah" << MyDobleNumber << MyIntNumber << std::endl;
}
A teper' voz'mite g++ i sravnite, i perestan'te, ya konechno ochen' izvinyaus', nesti purgu.

>IMHO, ОБЩАЯ логическая структура C++ программы обычно прозрачнее,
чем у аналогичной C программы. Платой за это является "тормознутость"
и сложность улавливания тонких ошибок.

Esli Vi ne znaete C++, to, tipa, i ne govorite.

>Я не понимаю, зачем мне пользоваться чем-то еще, кроме C, при
разработке "общесистемного" софта.

Zatem, chto C -- yazik "slishkom nizkogo urovnya".

2AC (*) (2001-06-02 01:02:39.0):
Увы, с Вами, оказалось, не о чем говорить:(

Flawer.

To Flawer:
>Увы, с Вами, оказалось, не о чем говорить:(

Sorry, ya ochen' izvinyaus' za ton, no menya eto nemnogo zadelo.
Chestnoe slovo, nu zachem Vi beretes' rassuzhdat', privodya v primer code s cout << form(...), i viskazivaya frazi tipa "ostream vse formatiruet v s stroku", kotorie prosto _vinuzhdaut_ podumat', chto Vi, esli mozhno tak virazit'sya, ne sovsem znakomi s predmetom.
Pravda, esli bi Vi privodili bolee korrectnie primeri, discussion imel bi bol'she smisla. Ya ved' tozhe mogu na C takoe nagorodit', chto programma budet ele sheveli'tsya.
Eshe raz izvinyaus', esli obidel Vas svoim tonom.

2AC (*) (2001-06-02 01:13:50.0):

> Sorry, ya ochen' izvinyaus' za ton, no menya eto nemnogo zadelo.
При чем тут тон? Если бы Вы хамили конструктивно, я бы стал
"отругиваться". Но, IMHO, Вы ... э-э-э ... не очень знакомы с
предметом разговора... И логика, того, ... страдает... Я ж Вам
дал ВСЕ исходники!!! Откомпилите, прогоните, если мне не верите...

Т.е., я не обижаюсь (ну, в смысле, обиделся:), но не в этом дело),
просто я завязываю с данной дискуссией.

Sincerely yours,
Flawer.

P.S.
Прошу прщения, если я Вас задел -- ничего личного.
Я, честное слово, очень оценил Ваши извинения.

To Flawer:
>Но, IMHO, Вы ... э-э-э ... не очень знакомы с
предметом разговора... И логика, того, ... страдает... Я ж Вам
дал ВСЕ исходники!!!

Nu da, Vi mne dali ishodniki. Nu Vi zhe daete _zavedomo_nekorrectnii_primer_. S kakoi-to sovershenno nenuzhnoi function form, kotoroi nikto ne pol'zuetsya, i kotoraya sovershenno neefectivna -- imenno potomu, chto parse'it format string na runtime'e. A zachem eto delat', esli est' _normalnii_ iostream, gde parse'it _compiler_, i runtime izderzhki ravni 0.

>Откомпилите, прогоните, если мне не верите...
Da, ya potratil 5 minut, prognal, proveril, deistvitel'no tak. A potom ya proveril _normal'nii_ primer dlya C++, kotorii ispol'zuet prinyatie v etom yazile mechanism'i vivoda. I poluchil sovershenno inie results. Pochemu ya imel na eto pravo -- potomu chto Vi utverzhdali, chto sravnivaete dve _ideal'nie_ programmi. Ya schitau, chto Vash primer dlya C++ daleko ne idealen.
Ya tozhe mogu napisat' _krivuu_ programmu na C, kotoraya budet ele shevelit'sya. Ya vse-taki nadeus', chto Vi ne stanete otrizat', chto Vash primer dlya C++ krivovat.
A na samom dele, deistvitel'no, zavyazivaem.

2Flawer: Ваша демострация с С и С++ доказала давно известный факт, что g++ не умеет компилировать С++. Я запустил тот же тест, только вместо form (А что это такое?) использовал cout << myint << myfloat << endl; и printf без всяких sprintf. Тест я делал на VC6.0 запускал несколько раз (чтоб было статистически точно, т.к. я не знаю как узнать сколько программа выполнялась, то я просто мерял сколько программа была внутри цикла) и как ожидалось разница составила в где-то тысячные секунды. Компилятор надо нормальный использовать...
Пусть g++ поддерживает больше фич от С++, но как я уже говорил для меня те фичи что кожанное сиденье в самолете.

"Карфаген должен быть разрушен", да?

Кстати, раз уж пошла такая пьянка, то и printf надо заменить на puts(gcvt()). Чтобы, тыкскыть, в равных условиях... А как ты после VC сделал >/dev/null? Сдается мне, досовский >NUL и юниксовый >/dev/null - немного разные вещи...

max

Гражданы, вы будете смеяться, но form - быстрее. Конечно, не cout << form (что вообще за конструкция), а cout.form. По крайней мере на "дерьмовом" g++. Или, по-моему, на линухе. Насколько я себе представляю, под виндой он буферизует сильнее. А тут небось на каждый << идет write.

Тогда точно - никакой разницы. Даже быстрее, если говорить fprintf(stdout,...)

max

to Flawer: "Уверяю Вас, бывают! Небезысвестный (Вам, надеюсь) Кнут пообещал некую сумму тому, кто найдет ошибку в его Метафонте -- лет 15 назад дело было! Никто ж не нашел!"

Однако нашёл. Не то что бы ошибку, но чек от Кнута получил. На меньшую, правда сумму. http://www.truetex.com/knuthchk.htm

2flawer
>тем не менее для удачного
>использования чистого C требуется некая общепрограммистская >культура,
>в настоящее время отсутствующая у 99% программистов.

Жму руку :) Именно "программисткая культура" определяет мышление и подход к языкам и архитектуре. Просто многие до сих пор полагают, что GUI и MFC - это главное :)))О себе - первую программу я написал еще в далеком 1982 году :))) Для М-222 на Фортране-66. И понеслось :))) Для меня С + asm - это единственно возможное сочетание для высокоэффективного программирования. С учетом платформы, для которой программируешь :)))

ЗЫ: Ник - это от Стругацких ?

[521].Andrew

2anonymous (*) (2001-06-02 17:05:11.0): "Студент изначально орентированный на Бейсик вырастает никуда негодным програмистом, в смысле програмирования мозговым кастратом" (с) Дейкстра. Как известно Фортран и Бейсик - близнецы братья...:)
Я первую програму написал в 83м на PL/1 для EC1022... :) И тоже очень любил С... Пока не столкнулся с програмированием экспертных систем, после чего я С/С++ резко разлюбил...:)

Никакого преобразования типа cout << не делает. он просто просит линкер прилинковать к тому оператору <<, который работает со строкой. И вообще, почти все новшества в С++ по сравнению с С являются compile-time вещами, просто компилер делает за вас работу по преобразованию С++ конструкций к С. Это не касается только exceptions и runtime casting'a. Если g++ не дает таких-же результатов на двух прогах, которые используют одни и те-же сис-вызовы, то проблема в компилере, а не в языке.

2Irsi
Я первую програму написал в 83м на PL/1 для EC1022...
Ну блин, ноу комментс... На PL/1 именно на ЕС1022 и именно в 1983... Я в это время на 2-м курсе был. А ты ?

[521].Andrew

2anonymous (*) (2001-06-02 19:00:52.0): эээ... я несколько помоложе... 9й класс матшколы...:)
Поясняю - машинка разумеется не в школе стояла, а на заводе, который над школой шевствовал...:) Раз в неделю ходили туда на практические занятия...:)

А вот результат на SUN :
>uname -a
SunOS FFTXXX00 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-Enterprise

> cc 1.c -o c.out -xO3
> CC 1.cpp -o cpp.out -xO3

> time ./cpp.out > /dev/null

real 0m1.285s
user 0m1.250s
sys 0m0.030s
> time ./c.out > /dev/null

real 0m1.339s
user 0m1.320s
sys 0m0.000s
>

Ну и какой вывод ?
на SunOS надо использовать С++ ??????

Для Gcc разница между C и C++ объясняется очень просто -

загрузка STL - libstdc++.so.xxx библиотеки и её инициализация.

Если её засунуть в LD_PRELOAD - цифири получаются одинаковые;
либо собирать без оной.

Так-что никаких чудес.

2max: "А как ты после VC сделал >/dev/null? Сдается мне, досовский >NUL и юниксовый >/dev/null - немного разные вещи..." Во-первых, с чего бы это им быть разными, во-вторых я компилировал и запускал оба теста под Виндовс, т.е. обе программы работали в одинаковом окружении, так что сравнивалось как VC компилирует С и С++, и как ожидалось разницы не было ни какой. Я не говорю, что VC делает хуже или лучше чем g++, тем более, что приведенный пример просто не годится для такого эксперемента.

Ну и ещё exception frame ....

Правда в такой программе он только один,
много не должен занимать.....

2[521].Andrew:
> ЗЫ: Ник - это от Стругацких ?
От hotmail:)

Подряд пробовал все, что в голову приходило -- это оказалось первым
не занятым ( из пришедшего в голову)

Flawer

2iliyap :
Спасибо за ссылку!
"Век живи, век учись":)

Ну, все же, пример Кнута -- очень положителен.

Если бы Билл Гейтс за каждый ТАКОЙ баг платил по $2.56, он бы давно
стал нищим...

Flawer

2Ogr :
> Ваша демострация с С и С++ доказала давно известный факт, что g++
> не умеет компилировать С++
Ну, в принципе, тут я с Вами согласен...

С другой стороны, у меня есть сильное подозрение, что VC изначально
"заточен" под C++. Т.е., грубо говоря, он "не умеет компилировать С"
(утверждение сие абсолютно голословно).

> Я запустил тот же тест, только вместо form (А что это такое?) использовал
> cout << myint << myfloat << endl; и printf без всяких sprintf.

Я же, вроде, объяснил:

?printf форматирует, т.е., разбирает форматную строку и осуществляет
ОЧЕНЬ сложную работу по преобразованию различных типов в строковые
эквиваленты. В Вашем примере операция << на cout делает только один
шаг -- преобразует myint и myfloat в некий умолчательный (I mean,
лидирущие пробелы/нули/кол-во цифр и т.п.) строковый формат. Разбор
форматной строки (ОЧЕНЬ дорогая операция) тут не производится.

Штатным средством форматирования выводимой в поток информации,
аналогичным ?printf в C, в C++ является функция form,
см. Страуструпа. Поэтому я ее и использовал. По-моему, тест был
вполне справедливым.

Flawer

2[521].Andrew :
> первую программу я написал еще в далеком 1982 году :))) Для М-222
> на Фортране-66.
. . .
> Для меня С + asm - это единственно возможное сочетание для
> высокоэффективного программирования.

Кстати, интересно, а как Вы СЕЙЧАС относитесь к ФОРТРАНу?

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

BTW, свою первую программу я написАл в 1980 году (школьник)
для БЭСМ-6 на FORTRAN DUBNA. 300 строк, решение кубического
уравнения по формуле Кардано (комплескная арифметика была
самодельной). С тех пор НЕНАВИЖУ этот язык, хотя иногда приходится
на нем писАть и сейчас...

Flawer

>Штатным средством форматирования выводимой в поток информации,
аналогичным ?printf в C, в C++ является функция form,
см. Страуструпа. Поэтому я ее и использовал. По-моему, тест был
вполне справедливым.

Shtatnim sredstvom formatirovaniya vivodimoi v potok informazii, analogichnim printf v C, v C++ yavlyautsya manipolyatori potokov (iomanips). AFAIK, v standarte C++ net nikakoi functii ?form, eto GNU-extension. Kstati, ya seichas special'no posmotrel Stroustroup'a, i nikakoi funckzii form ne obnaruzhil. Esli Vam ne trudno, tknite menya, pls., nosom v stranizu.
BTW, ya pomeryal i C printf versus implementation of iostreams from STLport. C++ -- viigrivaet, pravda, estestvenno pri uvelichenii razmera executable.
Tak chto, Vash primer taki nekorrecten. Levaya nesvoistvennaysa C++ function kak sposob testirovaniya ne goditsya. A pri normal'nih variantah poluchaetsya libo ekvivalentnoe bistrodeistvie, libo proigrish C -- imenno potomu chto v nem _principial'no_ otstustvuut sposobi bistrogo _type-safe_ vivoda, i vagon raboti perekladivaetsya na runtime-razbor formatnoi stroki. Razbor manipulators na runtime stoit 0.

2AC (*) (2001-06-03 01:27:21.0):
> Esli Vam ne trudno, tknite menya, pls., nosom v stranizu.

Бьярн Страуструп, 1995 г.

"Введение в язык С++"

8.2.3 Форматированный Вывод
(самый конец параграфа)

Flawer

2All:Sorry, off-topic... 2AC: fla_wer@hotmail.com You are welcome! Flawer

2anonymous (*) (2001-05-30 15:40:59.0)Ж
Конечно, проехали уже...
Извиняюсь перед All, меня возбудила сия дискуссия ;)

Просто комментарий:

> Между прочим, разработчик VAX VMS - руководитель
> разработки Microsoft Windows NT.

IMHO, не "разработчик VAX VMS", а "один из разработчиков
VAX VMS" -- будем спорить?

Flawer

To Flawer:

>Бьярн Страуструп, 1995 г.

>"Введение в язык С++"

Vi bi esche na pervoe izdanie soslalis' -- 1986 goda:) Esli chestno, vtoromu izdaniu ot 1995 goda mesto -- tozhe ne na stole i ne na knizhnoi polke, v silu ego polnoi neaktual'nosti. Kak obichno, pol'zovanie ustarevshimi istochnikami mozhet tol'ko zaputat', i privesti k nepravil'nim vivodam. Ya zhe, dlya C, ne ssilaus' na old K&R, esli ya ne oshibaus', eto tak nazivaetsya?, style.
P.S.: Podrobnii otvet ushel milom

2Flawer: "?printf форматирует, т.е., разбирает форматную строку и осуществляет ОЧЕНЬ сложную работу по преобразованию различных типов в строковые эквиваленты. В Вашем примере операция << на cout делает только один шаг -- преобразует myint и myfloat в некий умолчательный (I mean, лидирущие пробелы/нули/кол-во цифр и т.п.) строковый формат"
Come on... cout как и printf преобразует различные типы в их строковые эквиваленты, используя параметры форматирования. Разницы быть не должно ни какой.
Кстати посмотрел я книгу "The C++ Programming Language Special Edition" by Bjarne Stroustrup (ISBN: 0201700735) и знаете ни чего подобного form я там не нашел, весь параграф 21 перечитал, все сплошь width и прочая...

> Come on... cout как и printf преобразует различные типы в их строковые > эквиваленты, используя параметры форматирования. Разницы быть не > должно ни какой. Ну ты профи, блин.. Такую же чушь спорол, как и про симлинки.. У << нет никакой форматной строки - ничего парсить не надо.

>> Ваша демострация с С и С++ доказала давно известный факт, что g++
>> не умеет компилировать С++
>Ну, в принципе, тут я с Вами согласен...

Кому известный факт ?
И с чего вы взяли, что не умеет ?

2anonymous (*) (2001-06-03 13:19:52.0): "Такую же чушь спорол, как и про симлинки.. У << нет никакой форматной строки - ничего парсить не надо"
Марш изучать класс ios на предмет функций precision, setf и width, а так же изучи русский язык, чтоб до тебя дошло значание фразы "преобразует различные типы в их строковые эквиваленты, используя параметры форматирования" а то я там слова parse не писал. А так же Flawer писал "форматирует, т.е., разбирает форматную строку и осуществляет ОЧЕНЬ сложную работу по преобразованию различных типов в строковые эквиваленты", разобрать %-4f большого труда не представляет, только вот С++ подставит соответсвующий опператор для вывода float во время компиляции, а не во время исполнения, что говорит о более нормальном дизяане языка.

anonymous (*) (2001-06-03 15:55:05.0): "
>> Ваша демострация с С и С++ доказала давно известный факт, что g++
Кому известный факт ?
И с чего вы взяли, что не умеет ?"
Известно любому, кто хоть раз пробывал откомпилировать программу скажем Сановским компилятором и g++, а потом сравнить скорость. Мы такое делали, потому как было жалко выкладывать почти по $2000 за лицензию на место. Сравнив скорость, пришлось денежки выложить, т.к. какой бы гадостью этот сановский компилятор не был, но код под спарки он делал куда быстрее чем g++. Возможно с тех пор что-то изменилось (я надеюсь, что это так, но веры в это нет).

>какой бы гадостью этот сановский компилятор не был, но код под спарки он делал куда быстрее чем g++. Возможно с тех пор что-то изменилось (я надеюсь, что это так, но веры в это нет).

Net, nichego s teh por ne izmenilos'.
No nikto i ne rassmatrivaet g++ kak compiler dlya proizvodstva final'nogo koda. g++ horosh dlya promezhutochnoi razrabotki i otladki koda, kotorii potom otdaetsya kommercheskomu compiler'u. Dlya g++ versus KAI na Linux'e -- otstavanie g++ po skorosti -- v srednem 15%, otstavanie po razmeru -- esche bol'she.

2Ogr (*) (2001-06-03 05:44:59.0):
> Come on... cout как и printf преобразует различные типы в их строковые эквиваленты, используя параметры
> форматирования. Разницы быть не должно ни какой.
Вы меня поняли -- я говорил про runtime разбор форматной строки.

> Кстати посмотрел я книгу "The C++ Programming Language Special Edition" by Bjarne Stroustrup (ISBN:
> 0201700735) и знаете ни чего подобного form я там не нашел, весь параграф 21 перечитал, все сплошь width и
> прочая...

"AC" объяснил: в более поздних изданиях Страуструпа эта функция
исчезла.

Кстати, я тут попробовал несколько разных C++ компилеров (CC для
SPARCов, сxx на Альфе для True64 и Linuxа) -- все они функцию form
проглотили.

Flawer

Ogr:
> ... куда быстрее чем g++

Я вот сейчас их любопытства сотворил два executable на Альфе
(Линукс)

g++ -o hellogpp -O2 -mcpu=21264 hello.cpp
cxx -o hellocxx -fast hello.cpp

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

169700 hellogpp
294200 hellocxx

Затем я решил проделать то же на СПАРКе (4 процессора Super SPARC
II 85 MHz). Результат меня потряс!!!

g++ -O2 -o hellogppSUN -msupersparc hello.cpp
CC -O2 -o helloCC hello.cpp

Опять GNUтый вариант размера оказался чуть меньше:
6456 Jun 3 23:48 hellogppSUN
8940 Jun 3 23:48 helloCC

Но по скорости ОНИ ОКАЗАЛИСЬ ОДИНАКОВЫ!!! GNUтый executable
все же чуть медленнее, наверное, но -- практически в пределах
статистич. погрешности.

Затем я стал гонять ЭТИ ЖЕ executable на другом SUNе
(2 процессора Ultra SPARC 200 MHz, 2 MB secondary cache)
И получил, что GNU медленнее на 10%...

executable были ТЕ ЖЕ, ЧТО И В ПРЕДЫДУЩЕМ СЛУЧАЕ!!!



Flawer

2Flawer: "hellocxx оказался быстрее на прибл. 10%, что, в общем-то,
пренебрежимо для большинства приложений"
Да для большенства приложений, скорость не важна, но когда скорость важна, как в том случае когда меряли скорость, каждый процент важен.

2Flawer:
2[521].Andrew :
> первую программу я написал еще в далеком 1982 году :))) Для М-222
> на Фортране-66.
. . .
> Для меня С + asm - это единственно возможное сочетание для
> высокоэффективного программирования.

Кстати, интересно, а как Вы СЕЙЧАС относитесь к ФОРТРАНу?

Извиняюсь за задержку :)
Честно говоря, последнюю программу на Фортране я написал в 1984 году - ок 2-х тыс.строк :) После чего перешел на PL/1... Аж до 1991 года :) Естественно, после перехода на РС - только С (и асм по потребности:). Сейчас программирование - не основное занятие, а хобби (может, этим и объясняется моя стойкая привязанность к данной паре, несмотря на веяния программистской моды :) Ну, а мой друг в институте (декан :) до сих пор на Фортране программирует :)

>Известно любому, кто хоть раз пробывал откомпилировать программу

Хороший ответ ;)
Очень аргументированный. Как и почти всё
что несёт г. Ogr