Чем плох С++

>Довольно много высказываний против C++ Объясните чем же плох

ничем он неплох - сколько людей, столько и мнений...

...дело ещё и в компиляторе...

Было такое шуточное интервью с Бьярни, в котором он рассказал зачем
он придумал ``C с классами''. Оказывается для того, чтобы программисты
работаль над своими проектами дольше и соответственно получали бы
бОльшие гонорары. В этом что-то есть.

Ведь C++ это не полностью объектно-ориентированный язык это и есть
``C с классами''. Просто возможность запаковывать (инкапсулировать)
многое в описание своего типа.

На практике, дальше классов, конструкторов и деструкторов, максимум
наследования (гуевые тулкиты например) мало кто что пользует из
всего обилия вещей, реализованных в C++.

Инкапсуляция это хорошо и полезно в принципе в любом проекте. А
шаблоны? А RTTI? А виртуальные функции с полиморфизмом? Математики
рукоплещут. Это да. Но системный программист скажет: "Нафига мне ваш
полиморфизм, когда мне нужен полный контроль над приложением. Мне
нужна безопасность, локаничность и надежность языковых конструкций.
Мне лень разбираться с extern C и прочей херней. Я пишу на C".

Лично мне это видиться так.

> Реализовал я немного из матричной алгебры...

А причем тут С++? Матрицы придумали давно, и реализовать их можно хоть на спичках.

> Это плохо или как ???

Какой тип float или double? В любом случае лучше посмотреть на Atlas и/или Intel MKL перед изобретением велосипедов.

>Мне нужна безопасность

хахаха. си самый взрывоопасный язык. со своими char*

Взрывоопасность не в языке, а в кривых руках программиста. Сам по себе char* ничем не плох. А Си хорош тем, что все под контролем программиста, а если кто не в состоянии или не хочет контролировать все, то Python/Java/Haskell/etc ему в руки.

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

> хахаха. си самый взрывоопасный язык. со своими char*

тут про C++ говорится - string.

а шаболны - рульная вешь, повышают процесс кодирования очень сильно. RTTI - не нужно, не используй, кому-то это надо, иначе не было бы в стандарте.

> Ведь C++ это не полностью объектно-ориентированный язык это и есть ``C с классами''.

нет, он как раз ООП.

> Но системный программист скажет: "..."

ну, для этого собственно и предназначен C - драйвера и модули на C++ писать смысла нету :)

> Ведь C++ это не полностью объектно-ориентированный язык это и есть ``C с классами''.

>нет, он как раз ООП.

вот тут разреши не согласиться: на с++ реально написать програмулину без словечка class /cout, cin - скрытая кухня, поэтому не берём в счёт/, а на жабе - никак! я думаю именно это имелось в виду автором поста 'C++ это не полностью объектно-ориентированный язык'.

О чём вы спорите? C++ гибридный язык.

Да собственно ни причем. Просто решил попробывать. Вроде получилось. При использовании языков не допускающих перегрузку операторов как-то не естественно выглядит все. Использовал double. Знаю что велосипед но интересно посмотреть что и как.

>На практике, дальше классов, конструкторов и деструкторов, максимум наследования (гуевые тулкиты например) мало кто что пользует из всего обилия вещей, реализованных в C++.

Их не используют _кодеры_(не профессиональные программисты). Таких сейчас как грязи. Именно они кричат что C++ ацтой.

И вообще как можно сравнивать C - язык низкого уровня(да это почти ассемблер) с С++ который являеца языком высокого уровня? А кто не видит огромных различий между этими двумя языками просто не знают C++ даже на 10%.

И вобще Страуструп допустил ошибку, когда сделал язык C++ совместивым с С. Уже надоело видеть в файлах гордо заканчивабщихся на .cpp небезопасные функции типа printf scanf и т.д.

2nobody: >Сам по себе char* ничем не плох

Вычисление длины строки медленное. Надо вручную выделять память, причём в куче, для безопасности. При копировании нужно всё время заботица чтобы в буфере было достаточно места и еще туева хуча всякого гемороя.

Всё это делает std::string. И без всякого гемора. Потому что это динамическая структура данным с автоматическим перераспределением памяти :)

> Вычисление длины строки медленное.

Используй свою любимую библиотеку строк.

> Надо вручную выделять память, причём в куче, для безопасности.

Шас.

> При копировании нужно всё время заботица чтобы в буфере было достаточно места и еще туева хуча всякого гемороя.

См. выше

> Потому что это динамическая структура данным с автоматическим перераспределением памяти

Это наверное жутко дешево и быстро?

>Это наверное жутко дешево и быстро

мне это тоже в голову пришло

но ничё не поделаешь - надо всё быстро и дёшево /'сердито' отпадает/

>Используй свою любимую библиотеку строк.

А я и использую. называеца STL. Причем это стандарт. А не левая либа.

>Шас.

Да, ну?

>Это наверное жутко дешево и быстро?

а ты всё равно это делаеш. только руками. кроме того в std::string есть capacity

> Их не используют _кодеры_(не профессиональные программисты). Таких
> сейчас как грязи. Именно они кричат что C++ ацтой.

Честно говоря я не нашел в этой фразе никакого отношения к обсуждаемой
теме, и более как риторической ее назвать не могу...

> И вообще как можно сравнивать C - язык низкого уровня(да это почти
> ассемблер) с С++ который являеца языком высокого уровня?

Почему вы сделал твкое заключение? Язык ассемблера это действительно
язык низкого уровня, поскольку состоит из команд процессора. Язык C
формально не является языком низкого уровня уже только потому, что
использует машинно-независимые абстрактные языковые конструкции. С++
расширяет C и является языком еще немного более высокого уровня. Но
говорить, что C++ -- язык высокого уровня, а C -- низкого неверно.

> И вобще Страуструп допустил ошибку, когда сделал язык C++
> совместивым с С

Страуструп добавил в C классы, честно спизженные у Modula2. Больше
он ничего не делал.

> небезопасные функции типа printf scanf

scanf действительно не производит проверку на длину буфера, а printf
то там причем?

2nobody: >Сам по себе char* ничем не плох
> Вычисление длины строки медленное.
??? Будто string в STL это что-то более серьезное, чем

class string {
  char *str;
  int length;
  string();
  string(char *s);
  и т.д.
};

Там длина вычисляется каждый раз как вы изменяете *str, а в C
длина вычисляется тогда когда она нужна. И кстати такой тип данных
описать тоже труда не составит. Как известно C++ смог появиться
только благодаря указателю this...

> Надо вручную выделять память, причём в куче, для безопасности

char str[MAXPATHLEN];

Вот и не в ручную. Кстати на счет хипа -- там все динамические данные
болтаются и в C и в C++, да и вообще везде -- это не язык это
организация пространства памяти такое.

> Потому что это динамическая структура данным с автоматическим 
> перераспределением памяти

Это все хорошо, но не всегда нужно.

Вспоминаю прошлую лекцию по C# (да, приходится знакомится и с такими
технологиями...). Так вот. Преп полчаса распинается, рисует 
кружочки на доске, двадцать раз обводит  надпись ``.NET'' и с
трепещущим голосом заявляет, что это панацея. Потом я его спрашиваю
Насколько безопасны приложения, запускаемые на CLR (или как их там),
и насколько хорош код .Net Framework (преп сказал, что он то ли
открытый или около того). И преп зависает. потом говорит, что шел
бы я лесом и нихера он в безопасности не разбирается. Так дискуссия
и закончилась.

Так что Кесарю кесарево, а ... ну дальше Вы и сами знаете...

>Язык C формально не является языком низкого

я бы сказал что он среднего уровня

>*нные у Modula2

а не у симулы 67?

>Вспоминаю прошлую лекцию по C#

небольшой оффтоп по этому поводу

у меня лабораторные работы по C# ведёт тот же препод, что в прошлом году вёл лабораторные по комп. архитектуре /ассемблер кароче/ и такое чувство что он от обоих предметов балдеет, но чего между ними общего? :)

> А я и использую. называеца STL.

Мрак.

> Причем это стандарт.

А str* - тоже стандарт. Стали ли строки Си от этого лучше?

> А не левая либа.

Реализация - в любом случае левая. STLPort там какой-нить.

> Да, ну?

Ну да. man alloca

> а ты всё равно это делаеш. только руками.

Я делаю это лучьче для каждого конкретного случая.

> кроме того в std::string есть capacity

Дерьмом от этого оно быть не перестает...

Antihrist'a на вас нету.

Ну сколько можно уже эту тему мусолить?

>Страуструп добавил в C классы, честно спизженные у Modula2. Больше он ничего не делал.

аха, exceptions & namespaces & inline из воздуха паявились?

>а printf то там причем?

не производит проверку типов

>Там длина вычисляется каждый раз как вы изменяете *str

длина не вычисляеца а прибавляеца и отнимаеца при измении длины. при измениее символов строки она не вычисляеца. ибо нефиг.

>длина вычисляется тогда когда она нужна

Чтобы сделать конкатенацию в C нужно вычислить(именно _вычислить_, тоесть проитерировать по двум строкам до \0), а если строки большие, то это тормоз. причём линейный

>Как известно C++ смог появиться только благодаря указателю this...

Можно я здесь буду смияца? :)

>char str[MAXPATHLEN];

Выделение памяти в стеке. Прямая дорога к bufferowerflow и експлойтам. У тибя нет опыта написания защищеных программ на C :)

>Вот и не в ручную. Кстати на счет хипа -- там все динамические данные болтаются и в C и в C++, да и вообще везде -- это не язык это организация пространства памяти такое.

Что? :)

>Вспоминаю прошлую лекцию по C# (да, приходится знакомится и с такими технологиями...). Так вот. Преп полчаса распинается, рисует кружочки на доске, двадцать раз обводит надпись ``.NET'' и с трепещущим голосом заявляет, что это панацея. Потом я его спрашиваю Насколько безопасны приложения, запускаемые на CLR (или как их там), и насколько хорош код .Net Framework (преп сказал, что он то ли открытый или около того). И преп зависает. потом говорит, что шел бы я лесом и нихера он в безопасности не разбирается. Так дискуссия и закончилась.

Да, рульно :) я плакала :)

>Ну да. man alloca

The alloca function returns a pointer to the beginning of the allocated space. If the allocation causes stack overflow, program behaviour is undefined.

Одним словом LOL. Еще один любитель поджарить стек.

>А str* - тоже стандарт. Стали ли строки Си от этого лучше?

нет

>Мрак. >Дерьмом от этого оно быть не перестает...

С тобой у меня разговор окончен. Ибо неистересно. И не аргументировано.

> The alloca function returns a pointer to the beginning of the allocated space. If the allocation causes stack overflow, program behaviour is undefined.

> Одним словом LOL. Еще один любитель поджарить стек.

Глупое ты.

> С тобой у меня разговор окончен. Ибо неистересно. И не аргументировано.

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

Для числодробилки C++ хорош. Плох он своей сложностью и неоднозначностью - крайне сложно верифицировать и доказывать C++-ный код. Так что я уж лучше предпочту язык попроще с трансляцией затем в C++. Тем более, что многие CAS и так умеют генерить C++-код.

Доброго времени суток.
Для числодробилок фортран подойдет лучше всего(я почему-то в этом уверен) /он для этого был и создан/.
По поводу "колеса" -)
Вы забыли о ScaLAPACK, о IMSL,о NAG.
Я знаю только одну программу, написанную на C++ ( в моей области) - mpqc, остальные титаны на 77-ом фортране.Хотя появились в последнее время пакеты, написанные на 90-м фортране ( к примеру ParaGauss ).
Но этом мое имхо, которое не претендует на общность.

> Я делаю это лучьче для каждого конкретного случая.

Так пиши на ASM'е. Сделаешь всё лучше для каждого конкретного случая. Даже, можешь учесть заполненность конвейера команд, обращения к памяти, попадания в кэш. Так что, C ваш - ацтой, а C++ - вапще полное фуфло :)

Только вот, голова у тебя будет болеть не о перемножении матриц 1000x1000, а будет забита конвейерами, кэшами, page fault'ами и прочей дребеденью. Это всё хорошо, когда тебе надо специализированное приложение на грани возможностей аппаратуры, да и то, если твоя зарплата не столь высока, или начальник недостаточно умён, чтобы купить ещё одну числодробильную железяку.

На самом деле, мне C++ не нравится своим ущербным ООП. Возможно, где-то чем-то он и хорош. Я даже скажу где и чем - нет проблем найти обезьянку, которая может на нём писать. Правда вот, найти обезьянку, которая умеет на нём писать хорошо, так же сложно, как и для других языков.

Меня вполне устраивают двуязычные связки (любимая - Python+C). Легко и свободно реализуется общая логика на Python, а time-critical части реализуются на C.

> Так пиши на ASM'е. Сделаешь всё лучше для каждого конкретного случая.

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

>На самом деле, мне C++ не нравится своим ущербным ООП

И в чёи же заключаеца его ущербность? Может в нем через жопу инкапсуляция реализована, как в питоне?

ИМХО, ругают С++ только те, кто его совершенно не знают. По крайней мере, из всех ругающих, которых я встречал - никто не владел нормально этим языком. Я сам не очень хорошо им владею, но мне ужасно нравится, что на С++ можно сделать все.

>ИМХО, ругают С++ только те, кто его совершенно не знают

это не ИМХО, это реальность :)

Ну и забавная у нас дисскуссия получается ;).  Отвечаю сразу на
несколько фраз...

>>*нные у Modula2
>
>а не у симулы 67?

А кто его знает. Лично мне до этого нет никакого дела. Но чего-то
всплывает в памяти. Да, скорее всего из симулы. Я сам когда написал
задумался.... Да скорее всего. Modula2 это из другой опреы -- это
Вирт там....

> но чего между ними общего?

Ничего, просто люди бывают разные. Я -- параноик. Еще и принципиальный.

> Antihrist'a на вас нету.

Антихрист математик и лично мне будет с ним не о чем говорить.

> аха, exceptions & namespaces & inline из воздуха паявились?

Это потом уже наросло, да я сомневаюсь, что Страус сам это сделал.
А может и сам :-\

>>а printf то там причем?
>
>не производит проверку типов

Это вы к чему? Зачем ему что-либо проверять, когда он печатает по
форматной строке и все ошибки вылезают на этапе компиляции. Я хочу
подчеркнуть -- ошибки программиста, а не printf.

>>длина вычисляется тогда когда она нужна
>
>Чтобы сделать конкатенацию в C нужно вычислить(именно _вычислить_,
>тоесть проитерировать по двум строкам до \0), а если строки
>большие, то это тормоз. причём линейный

Слушайте. Вы так говорите, как будто в C++ это делается иначе.
Внутри оно так и делается. Если Вы надеятесь, что встроенная в класс
длина строки это панацея, то я сочувствую Вам. Как насчет ситуации
когда строка имеет вид "str\0str\0". Я плохо себе представляю
алгоритм конкатенации такой строки с любой другой стредствами STL.
Потому что есть вероятность обламаться на разных реализациях или
получить неверный результат и т.п. (Да в C тоже не получится вызовом
1 функции решить проблему тоже не получится, но поскольку данные
не инкапсулированы, то к ним можно обратится и в цикле завершить
опреацию...)

С другой стороны, C предоставляет Вам 3 интерфейса к конкатенации
строк (strcat, strncat, strlcat) с описанным методом работы и понятным
(и разным) результатом. А как в C++ работает функция конкатенации?

>>Как известно C++ смог появиться только благодаря указателю this...
>
>Можно я здесь буду смияца? :)

Конечно. Свободные люди в свободной стране. Еще и веселые к тому же.
Чего ж запрещать-то?

> Прямая дорога к bufferowerflow и експлойтам.

Не всегда. И точка. Тут программист должен сам решать. Что ему надо.
Автор vsftpd для себя уже решил ;)

>это не язык это организация пространства памяти такое.
>
>Что? :)

Того. У процесса есть такие области виртуальной памяти (рисунок для ELF):

+------------------+
|                  |
| Dynamic segments |
|                  |
+------------------+
|       heap       |
+------------------+
|       data       |
|                  |
+------------------+
|       code       |
+------------------+
|       stack      |
+------------------+

Стек растет вниз, хип вверх. data хранит инициализированные данные
(статические) и BSS (неинициализированные данные заполненные нулями).

Так что это организация памяти. Когда делают malloc данные помещаются
в хип сами (опер. системой).

Ну до следующего раза что-ли...

> что на С++ можно сделать все.

А что же тогда еще ВСЕ на нем не переписали? По видимому может быть
все и можно сделать, но не нужно этого делать.

>Ну и забавная у нас дисскуссия получается ;)

:)

>Это вы к чему? Зачем ему что-либо проверять, когда он печатает по форматной строке и все ошибки вылезают на этапе компиляции. Я хочу подчеркнуть -- ошибки программиста, а не printf.

Нет. Если ты перепутал % спецификатор и написал агрумент с данными другово типа для это спецификатора, компилятор C тебе об этом не скажет. Так что

>все ошибки вылезают на этапе компиляции

Это не верно.

>Я хочу подчеркнуть -- ошибки программиста

А это верно.

>Как насчет ситуации когда строка имеет вид "str\0str\0". Я плохо себе представляю алгоритм конкатенации такой строки с любой другой стредствами STL.

Ну вот, окрываю я щас значит книгу "Стандартная библиотека C++ для профессионалов" :), и читаю: "Следует помнить, что в строках не существует специальной интерпретации символа \0, который в традиционных C-строках являеца признаком конца строки. Символ \0 может входить в строки наравне с любым другим символом."

>А как в C++ работает функция конкатенации?

нормально работает. :)

>Автор vsftpd для себя уже решил ;)

если не секрет, а что он решил? :)

>Стек растет вниз, хип вверх.

Хип никуда не растет ;) Хоть он и куча :)

>Так что это организация памяти. Когда делают malloc данные помещаются в хип сами (опер. системой).

Когда делают malloc данные никуда не помещаюца, тем более опер. системой. И вобще что данные такие?

>>Это вы к чему? Зачем ему что-либо проверять, когда он печатает по
>>форматной строке и все ошибки вылезают на этапе компиляции. Я хочу
>>подчеркнуть -- ошибки программиста, а не printf.
>
> Нет. Если ты перепутал % спецификатор и написал агрумент с данными
> другово типа для это спецификатора, компилятор C тебе об этом не
> скажет. Так что
>
>>все ошибки вылезают на этапе компиляции
>
>Это не верно.

Как на днях сказал henning:

wrong wrong wrong wrong wrong wrong wrong wrong wrong!

Смотрите:

% cat test.c
#include <stdio.h>

int
main()
{
        char str[] = "str";
        int i = 0;

        printf("%s %i\n", i, str);
        return (0);
}
% cc -Wall -Werror -o test test.c                                              
cc1: warnings being treated as errors
test.c: In function `main':
test.c:9: warning: format argument is not a pointer (arg 2)
test.c:9: warning: int format, pointer arg (arg 3)

Так что сначала надо попробывать.

>>Как насчет ситуации когда строка имеет вид "str\0str\0". Я плохо
>>себе представляю алгоритм конкатенации такой строки с любой
>>другой стредствами STL.
>
>Ну вот, окрываю я щас значит книгу "Стандартная библиотека C++
>для профессионалов" :), и читаю: "Следует помнить, что в строках
>не существует специальной интерпретации символа \0, который в
>традиционных C-строках являеца признаком конца строки. Символ \0
>может входить в строки наравне с любым другим символом."

Я в это не верю. Покажите исходный код класса string.

>>Автор vsftpd для себя уже решил ;)
>
>если не секрет, а что он решил? :)

Он решил, что ``очень безопасный'' FTP сервер он будет писать на C.
Это так к слову....

>>Стек растет вниз, хип вверх.
>
>Хип никуда не растет ;) Хоть он и куча :)
>
>Когда делают malloc данные никуда не помещаюца, тем более опер.
>системой. И вобще что данные такие?

Словами Henning'а Brauer'а Вы опять не правы.

Я не хочу говорить в пустоту и зря расходовать байты дискового
пространства сервера linux.org.ru. Почитайте что-нибудь о формате
ELF, виртуальнойпамяти и т.п.

Cum principia negante non est disputandum, знаете ли....

>test.c:9: warning: format argument is not a pointer (arg 2) test.c:9: warning: int format, pointer arg (arg 3)

и что? компилятором это определяеца как warning а не ошибка. а ты писал <все ошибки вылезают на этапе компиляции>

>Я в это не верю. Покажите исходный код класса string.

vi `locate basic_string.tcc`

>Он решил, что ``очень безопасный'' FTP сервер он будет писать на C. Это так к слову....

Ну он афтор vsftpd, ему можно :)

>Я не хочу говорить в пустоту

я тоже не хачу

>Почитайте что-нибудь о формате ELF

причём здесь вобще ELF?

И вообще зачем ты мне начал расказывать как устроена куча? Я это и так прекрасно знаю. И с форматом файла ELF это не как не связано.

Я тебя сказала что размещать C строки в стеке не безопасно. А ты мне пишеш

>char str[MAXPATHLEN];

и начинаеш расказывать лекцию :)

>Cum principia negante non est disputandum, знаете ли....

И мне пожалуста передайте косяк.

> > На самом деле, мне C++ не нравится своим ущербным ООП

> И в чёи же заключаеца его ущербность?

В отсутствии аналога MOP. Все остальное - уже следствия.

> Так пиши на ASM'е. ... числодробильную железяку.

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

> 2nobody: >Сам по себе char* ничем не плох

> Вычисление длины строки медленное. Надо вручную выделять память, причём в куче, для безопасности. При копировании нужно всё время заботица чтобы в буфере было достаточно места и еще туева хуча всякого гемороя.

Во-первых, речь шла про "взрывоопасность", а не про скорость и геморройность. char* геморройнее чем string -- да, не спорю. Но если говорить про геморройность, то есть менее геморройные (по сравнению с С++) языки. Тот же Haskell, например.

Во-вторых, насчет выигрыша в скорости у С++ по сравнению с С -- прогон. Что мы имеем в С++:

string str = "my string";
fn(str);

А вот это в С:
const char *str = "my string";
fn(str);

Ну и кто быстрее? У С++ масса накладных расходов при работе со строками по сравнению с С (в случае использования класса string, естественно; если без него, то все как в С).

Насчет конкатенации:
int my_open(const char *path, const char *file)
{
size_t pl = strlen(path), fl = strlen(file) + 1;
char pathname[pl + 1 + fl];
memcpy(pathname, path, pl);
pathname[pl] = '/';
memcpy(pathname + pl + 1, file, fl);
return open(pathname, O_RDONLY);
}

Сравни это с реализацией string в С++, и увидишь невооруженным взглядом, что накладных расходов у my_open на конкатенацию меньше, потому что нет очень дорогой операции выделения и освобождения памяти. Вот для сравнения с использованием string:
return open((path + '/' + file).c_str(), O_RDONLY);

Двойной new/delete. (аналога realloc-то в С++ нету).

string str = "my string"; fn(str);

В какой именно строчке здесь тормоза?

const char *str = "my string"; fn(str);

Я тоже так могу.

static string c("my string");

string *str = &c; fn(str);

>потому что нет очень дорогой операции выделения и освобождения памяти.

у std::string есть capacity.

>Двойной new/delete. (аналога realloc-то в С++ нету).

Это я не знаю. Надо будет посмотреть.

>Тот же Haskell, например.

Он компилируемый? По скорости он может сравница с C++?

> и что? компилятором это определяеца как warning а не ошибка. а ты
> писал <все ошибки вылезают на этапе компиляции>

Как бля насчет ман по gcc почитать на предмет того что делает опция
-Werror?

> vi `locate basic_string.tcc`

Нахуй. Мне что занятся больше нечем?

> причём здесь вобще ELF?

притом бля. иди книжки читай. заебало меня отвечать.

> Я тебя сказала что размещать C строки в стеке не безопасно.
> А ты мне пишеш

Это я написал до этого. К тому же на факт, что эти данные пойдут в
стек. Из контекста это не видно. Если так объявить в функции -- да
будет использоваться стек. Если это объявить глобально, тогда это
BSS.

>>Cum principia negante non est disputandum, знаете ли....
>
>И мне пожалуста передайте косяк.

Я с одними наркоманами работал. Меня заебало. И Вам советую бросить.

> Я с одними наркоманами работал.

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

>Нахуй. Мне что занятся больше нечем?

Страный ты какойто, сам же просил.

>иди книжки читай.

я уже все необходимые книшки прочитала, в отличие от тебя :)

И формат исполняемого файла к распределению памяти не имеет ни малейшего отношения.

Короче достал ты меня своим ELFом.

Иди читай Липмана. 8 главу. про "время жизни сущности в программе"

>Если это объявить глобально, тогда это BSS.

аааа. ты наверно все буферы под строки глобально выделяеш. оригинально.

и вобще, чё это ты разматерился? не чего сказать? %)

> В какой именно строчке здесь тормоза?

Имелось в виду следующее: лишние накладные расходы на оборачивание в класс строки текста, содержимое которой известно при компиляции (и не изменяется при выполнении). Нафига эту строку вообще заворачивать в класс string? По идее -- ни для чего. Однако, если аргументами функций у нас являются string (а не char*), то придется делать эти лишние действия. Ты говоришь, что длина строки хранится в классе. Значит при создании string из const char* придется считать длину строки. А функции, которая принимает этот аргумент, длина может вообще не нужна. Имеем лишние действия. Это все к твоему заявлению по поводу меньших накладных расходов на runtime у класса string по сравнению с char*.

> у std::string есть capacity.

Чем оно поможет в приведенном примере? Ведь один хрен придется создавать новый объект (при операции string+string), а потом его удалять. Объединенная строка будет лежать в heap, а не в стеке, значит лишний new/delete.

> Это я не знаю. Надо будет посмотреть.

Я тоже не знаю. Просто предполагаю, что реализация string+char+string приведет к созданию 2 объектов класса string, а значит к двойному new/delete.

> Он компилируемый? По скорости он может сравница с C++?

Мы про геморрой или про скорость? Если про скорость, то да, Haskell можно компилить, но, даже будучи скомпилена, программа на нем обычно (не всегда) уступает по скорости программе на С++, если последняя написана проф.программером, не поленившимся убить кучу времени на тестирование, оптимизацию и отладку. А если сравнить трудозатраты на разработку и сопровождение, то себестоимость программы на Haskell будет ниже, чем на С++. Точных цифр у меня нет, просто IMHO: цена "софт на Haskel + новая мощная машина" окажется ниже, чем у "софт на С++", в случае достаточно сложных вычислительных задач. (HelloWorldы, естественно, в расчет не берем).

ЗЫ: еще по поводу класса string: IMHO, это лишняя сущность. Во всяком случае, лично я не знаю, где имеет смысл его применять вместо char*. Все равно строки нужны только для ввода/вывода, а он (ввод/вывод, осуществляемый ядром) юзает массивы типа char, а не классы string. Т.е. имеем просто лишние трансформации в/из char*. Для чего, спрашивается?

Фортран для числодробилок лучше всего по одной причине - существуют компиляторы, которые особо сильно под это дело заточенные. И пока что никакие C++ Фортран по производительности не догоняют. Плохо только то, что как целевой язык при компиляции Фортран малость хероват. Хотя, та же Математика и его умеет.

Я уж точно на порядки лучше тебя владею C++. Но ругал и буду ругать. Потому как C++ - ублюдочное говно. А сейчас - дуй читать Joyner-а. (в Google найдёшь, "Ian Joyner C++").

" Плохо только то, что как целевой язык при компиляции Фортран малость хероват." какая-то запутанная мысль -) Поконкретнее можно ?
"Хотя, та же Математика и его умеет." а не имеет ли фортран математику?) ...

> Ведь C++ это не полностью объектно-ориентированный язык это и есть
>``C с классами''.
C с классами - это другой язык. См. "Дизайн и эволюция C++" Б.Страуструп. C++ полностью объектно - ориентированый язык ибо все три необходимых и достаточных условия для того чтобы назвать его объектно-ориентированым есть. мало того даже C является объектно-ориентированым языком (так как на нем можно писать объектно ориентированый код). C++ не объектный язык - это да, но его таковым и не считают и не преподносят как объектный.

> А шаблоны? А RTTI?
Каким боком это относится к объектно ориентированности?

> А виртуальные функции с полиморфизмом?
Вот то что в C++ есть виртуальные и невиртуальные функции - это первый косяк (это противоречит принципу сокрытия реализации).

> Математики рукоплещут.
Это язык для математики не удобный. Потому язык не предоставляет готовых примитивов для работы с вышкой. А при наличии нормальной библиотеки быть удобным для математиков может любой язык.

PS: C++ плох тем, что его часто применяют не там где он на самом деле нужен. см. Забивать гвозди микроскопом.

И зачем это Луговский ник поменял на baklan, a? :)

Затем, что модераторы - подонки.

Это не мысль запутанная, это ты глупый. Компилировать что либо в Фортран дюже напряжно (в отличии от того же C++). Wolfram Mathematica умеет генерить код на Фортране, но качество всё же оставляет желать лучшего.

Вообще, если кто не догнал по тупости или безграмотности, мысль была такая - для любой числодробильной задачи надо сначала использовать какую либо аналитическую систему, которая даст все возможные на этом этапе оптимизации, с последующей автоматической генерацией кода на Фортране или C++. Фортран хорош, но компилять в него сложно. C++ - тормоз, в сравнении с Фортраном, но он хорош как целевой язык. Так понятнее? Или ещё полечить надо?

дети, вы ещё здесь?

по домам!

"Компилировать что либо в Фортран дюже напряжно (в отличии от того же C++)." У Вас проблемы с ключами компилляции или с отладкой кода ? Вам нужны makefil`ы ? Ну так и скажите - PGI, IFC, F, g77 ... скину ). Ну если отладка, то тут увы - только от незнания... Бартеньев для начала.

Ядро математики на фортране писано / причем тал либо NAG`ие либы, либо IMSL - точно не помню/... Все Ваше незнание и голословность.

Про оптимизацию - как напишешь, так и будет у Вас работать код ... Ключи ничем помочь не смогут. Вот про аналитическую систему не догнал ... А если задача в аналитическом виде не решается ?)))) только численно ... зайцев в поле ловить ?
Лечитесь сами, пора - осень уже на дворе.