Интервью с Бьярном Страустрапом

>> std::string - хороший пример плохо спроектированного класса

>хороший он или плохой дело десятое. само желание наследования от value типа - идиотизм

Был value, стал не value а базовым классом.

> Заявленную тобой цитату в этом треде разложили по полочкам, и опять же логично объяснили.

Какую цитату? http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11 И ее "разложили по полочкам и объяснили"? Спциально для тебя - там было 8 вещей, в которых ксеня облажался на протяжении первых 10 страниц, он отмазался от 6 и проигнорировал 2. _Здесь_ Абсурд упомянул только про физику игр, и даже он не назвал ее "адским позорищем".

> Ты же не привел обратных аргументов.

Ыыы... обратных _чему_? Ксеню ткнули носом в чушь, которую он нес, а он сказал "да это же очевидно, что я прав".

Впрочем, ладно. Если тебе его "доводы" показались весомыми - твое право. Не перетирать же на ЛОРе древний тред с sql.ru

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

Гентушникам плюсовые программы приходится часто компилировать. Так что в одном флаконе это с трудом может уместиться.

> Был value, стал не value а базовым классом.

хе-хе-хе. добро пожаловать в FAIL.

>_Здесь_ Абсурд упомянул только про физику игр, и даже он не назвал ее "адским позорищем".

Взаимопроникновения объектов, неуклюжее падение ragdoll моделей, и пр увы часты. Это зависит от того насколько быть критичным

Вот тут вполне достаточный отчет по пунктам:

http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11#458...

Насчет языков - это все зависит от того что понимать "языком".

В дискретной математике "язык" - это AFAIK форма записей связных графов который принимает алгоритм.

>Какую цитату? http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11 И ее "разложили по полочкам и объяснили"? Спциально для тебя - там было 8 вещей, в которых ксеня облажался на протяжении первых 10 страниц, он отмазался от 6 и проигнорировал 2.

Специально для остальных - http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11#458... - таки он ответил. И что же проигнорировал? "Пачками в день"? Это и так не ясно что преувеличение?

>_Здесь_ Абсурд упомянул только про физику игр, и даже он не назвал ее "адским позорищем".

> Не перетирать же на ЛОРе древний тред с sql.ru

Уныло, очень уныло. Вместо того, чтоб выяснять, кто что лучше назвал и придирок к словам и давности лет, гораздо проще привести реальные примеры преимущества плюсов перед всем остальным. К счастью, таких видимо нет, правда?

> К счастью, таких видимо нет, правда?

Они таки есть, мне их хватает! ::))

> Вот тут вполне достаточный отчет по пунктам:

Достаточный для членов фан-клуба.

> Насчет языков - это все зависит от того что понимать "языком".

Ну совершенно же понятно, что в данном случае "язык" - это захваченный в плен военнослужащий противника, а ксеня служит в разведке.

>>>_Возвращать InputStream_ в Яве - обычное дело.

>>Жалко, что вы продемонстрировали свой настоящий уровень настолько поздно. В бесполезном общении с вами было потеряно слишком много времени :(((

>Метод для выфетчивания blob'а в драйвере Оракла возвращает InputStream. Apache http клиент возвращает ответ сервера в виде InputStream. Разобрался бы в вопросе.

Помогите мне разобраться: InputStream в Java -- это value-тип или reference-тип? А std::fstream в C++ value- или reference-тип?

> Уныло, очень уныло.

Даже не знаю, что тебе посоветовать. Поплакать? В цирк сходить?

> проще привести реальные примеры преимущества плюсов перед всем остальным. К счастью, таких видимо нет, правда?

Правда, Перед _всем_ преимуществ и правда нет. И никто не утверждал, что они есть.

>Достаточный для членов фан-клуба.

>Ну совершенно же понятно, что в данном случае "язык" - это захваченный в плен военнослужащий противника, а ксеня служит в разведке.

Виляния.

> Объясни, какие функции ООП нужны в рендере? > обьясняю: / C++ Point c = a + b;

Да, производительность рендера явно вырастет... вы уверен что в коммерческих рендерах это используется?

> обьясняю: / C++ Point c = a + b;

Кроме школьного учебника по программированию, вообще зачем это надо. А если я вместо перегруженного оператора использую другое решение, по-моему это не будет иметь значения нигде кроме библиотек типа (STL) и т.п. Но даже Страуструп был удивлен появлением STL, так как на такое использование языка он явно не ожидал. Кстати, как Бъярн зарабатывает себе на жизнь? А то вид у него какой-то помятый.

>С++ если можно так выразиться перемудрили. А потом запутанность и плохую читаемость кода объяснили крутостью. Реально, С++ код - один из наиболее трудночитаемых, уступаю наверно только Perl и Tcl(хотя в в последнем случае этого можно избежать).

Где перемудрили ? Кто перемудрил ? В отличае от питона, код С++ читается легко, приятно и редко  изобилует индуизмами.
Запутанность кода ? Это от кодописателя, на каком угодно индусодоступном языке, можно накорябать такое, что сам чёрт ногу сломит.

>Кроме школьного учебника по программированию, вообще зачем это надо. А если я вместо перегруженного оператора использую другое решение, по-моему это не будет иметь значения нигде кроме библиотек типа (STL) и т.п. Но даже Страуструп был удивлен появлением STL, так как на такое использование языка он явно не ожидал. Кстати, как Бъярн зарабатывает себе на жизнь? А то вид у него какой-то помятый.

Вы, не считаете STL частью языка С++ ? А почему собственно ? БС очень мягко назвал таких программистов "пугающимися отличного от привычного" см: http://www.linux.org.ru/view-message.jsp?msgid=2882514&page=8#2887271

> Виляния.

Не нравится игра с терминами - не начинай ее.

Он забыл еще одну причину - сигнатуры в несколько мегабайт.

C: с = add_point(a, b);

Все прекрасно реализуется структурами. ООП нужно только в случае, когда нужно наследование, но и тут можно обойтись указателями на функции и приведением типов для структур. Реально сипипишное ООП вообще не нужно, оно там слабое. Нормальное ООП в Smalltalk.

> C: с = add_point(a, b); Все прекрасно реализуется структурами.

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

>>гениально, даёшь C++ на препроцессоре C

>частично это называется GTK ;)

Это называется GObject.

А Гослингу надо воздвигнуть памятник за то, что он спас нас от этой заразы и повел по разумному пути, навстречу разработчикам. И все быдлы, которые кричат, что С++ это свобода пусть сдохнут. Нет у вас никакой свободы. Вы жалкое убогое ламерье, которое думает, что баловство с ссылками и конструкторами копий это свобода. А свобода - это когда до хера библиотек, свободных, закрытых. Свобода это востребованность на рынке с реальными зарплатами. ПС. А страуса надо закопать.

______________________________________ обезъяна из клетки jvm

Вообщем перегрузку оператора + для класса my_class можно заменить на создание функции add_my_class(по сути перегруженный оператор функцией и является.

Как вариант: пишем mul_matrix, которая на входе принимает пару матриц и указатель на функцию обработки ее элементов(например, многочленов). Отдельно пишем функцию перемножения многочленов. Потом делаем inline-обертку mul_matrix_of_mnogochlen, вызывающую mul_matrix с указателем на нужную нам функцию.

> Вообщем перегрузку оператора + для класса my_class можно заменить на создание функции add_my_class(по сути перегруженный оператор функцией и является.

> Как вариант: пишем mul_matrix, которая на входе принимает пару матриц и указатель на функцию обработки ее элементов(например, многочленов). Отдельно пишем функцию перемножения многочленов. Потом делаем inline-обертку mul_matrix_of_mnogochlen, вызывающую mul_matrix с указателем на нужную нам функцию.

Я же сказал: "не потеряв читабельности". Читабельным кодом будет c=a*b, что со структурами-процедурами сделать _нельзя_.

p class=MsoNormal - это читать невозможно!

>> Объясни, какие функции ООП нужны в рендере? > обьясняю: / C++ Point c = a + b;

>Да, производительность рендера явно вырастет... вы уверен что в коммерческих рендерах это используется?

От того, что рендер с C++ переписать на C, производительность рендера тоже не вырастет. И не упадет. ;)

ООП - техника для увеличения производительности труда программиста, а не программы. Я думаю, независимо от языка программирования, на котором пишется рендер, используется приемы ООП (инкапсуляция, наследование, полиморфизм).

К тому же нет сильной надобности оформлять рендер в виде библиотеки, рендер вполне может быть отдельной программой, которой скармливают файл с описанием сцены, и получают от него картинку. Поэтому писать рендер на C вместо C++ особого смысла нет.

> От того, что рендер с C++ переписать на C, производительность рендера тоже не вырастет. И не упадет. ;)

Перегруженные операторы, конструкторы присваивания и копирования вместо макросов и структур точно не меняют скорость??

> ООП - техника для увеличения производительности труда программиста, а не программы. Я думаю, независимо от языка программирования, на котором пишется рендер, используется приемы ООП (инкапсуляция, наследование, полиморфизм).

Вы точно не переели ООП в ВУЗе, судя по перечню типовых штампов?

> И вообще, будет ли сегодня новость на главной об отставке Билла?

гы
не смешите мои копыта

>> ООП - техника для увеличения производительности труда программиста, а не программы. Я думаю, независимо от языка программирования, на котором пишется рендер, используется приемы ООП (инкапсуляция, наследование, полиморфизм).

> Вы точно не переели ООП в ВУЗе, судя по перечню типовых штампов?

А в чем он неправ? Штампы или нет - без разницы.

>Читабельным кодом будет c=a*b, что со структурами-процедурами сделать _нельзя_.

Код c=a*b в С++ абсолютно не читаем. Невозможно просто глядя на этот код определить что же делает эта конструкция.

mul_matrix(&a, &b, &c) - читаемо. Тут происходит вызов mul_matrix.

> Код c=a*b в С++ абсолютно не читаем. Невозможно просто глядя на этот код определить что же делает эта конструкция.

> mul_matrix(&a, &b, &c) - читаемо. Тут происходит вызов mul_matrix.

А mul_matrix, чисто по приколу, делит матрицы :D

>> Код c=a*b в С++ абсолютно не читаем. Невозможно просто глядя на этот код определить что же делает эта конструкция.

>> mul_matrix(&a, &b, &c) - читаемо. Тут происходит вызов mul_matrix.

>А mul_matrix, чисто по приколу, делит матрицы :D

Что он делает, можно найти grep'ом. В отличие от всяких operator*.

>> А mul_matrix, чисто по приколу, делит матрицы :D

> Что он делает, можно найти grep'ом. В отличие от всяких operator*.

Правда? Вот тебе вызов grep для поиска operator*: grep -E "operator[ \t]?\*"

зачем вы травите программиста?

>>> А mul_matrix, чисто по приколу, делит матрицы :D

>> Что он делает, можно найти grep'ом. В отличие от всяких operator*.

>Правда? Вот тебе вызов grep для поиска operator*: grep -E "operator[ \t]?\*"

И сколько разных векторов, смартуказателей и частичных специализаций оно найдет?

>>>> А mul_matrix, чисто по приколу, делит матрицы :D

>>> Что он делает, можно найти grep'ом. В отличие от всяких operator*.

>> Правда? Вот тебе вызов grep для поиска operator*: grep -E "operator[ \t]?\*"

> И сколько разных векторов, смартуказателей и частичных специализаций оно найдет?

Это ХЗ. Намекаеш, что тебе не нравятся перегруженные имена функций? Что ж, тяжело тебе. Такие имена сейчас разве что Си не поддерживает.

>>> Правда? Вот тебе вызов grep для поиска operator*: grep -E "operator[ \t]?\*"

>> И сколько разных векторов, смартуказателей и частичных специализаций оно найдет?

>Это ХЗ. Намекаеш, что тебе не нравятся перегруженные имена функций?

Мне не нравится невозможность нажать хоткей когда курсор на функции и получить список возможных ее реализаций в данном контексте для перехода к просмотру/редактированию. CDT например это освоил только в коде на Си. Кроме того, операции типа умножения - это слишком мелкие операции. Функция должна быть для большой операции - типа повернуть объект на заданный градус вокруг заданной точки.

>Макросы полезная и правильная вещь. И замечу, что очень быстрая.

Макросы == "язык для языка". Костыли, которые позволяют хоть как-то двигаться недоразвитому недоязычку.

> Мне не нравится невозможность нажать хоткей когда курсор на функции и получить список возможных ее реализаций в данном контексте для перехода к просмотру/редактированию.

Ы? Там частица "не" лишняя?

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

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

_ля сочинил мудатня какую-то и типа гений. Говно язык, говно его концепция. Без него б лучше все было, я уверен.

>Ы? Там частица "не" лишняя?

Опять виляния. Ты отлично знаешь о чем идет речь. Я тут пару недель назад делал стресс-тест для Эклипса CDT, написав обобщенный примитив для сетевых сокетов и начал его разбивать на статические стратегии как у Александреску. Хоткеи у Эклипса сразу сдохли.

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

Все эти операции можно изначально запрототипировать с помощью специализиированного инструмента. Их немного.

C++ не нужно. BrainFuck - наше фсио! Капча plained намекает, что анонимус прав.

>> Ы? Там частица "не" лишняя?

> Опять виляния.

Удачи тебе на жизненном пути. С такой неспособностью понимать других, она тебе понадобится.

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

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

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

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

Повоняй еще, плюсовая пидрилка.

Матрица вращения на заданный угол вокруг точки c заданным направляющим единичным вектором выглядит так:

[T][R(x)][R(y)][R(z)][R(y)]^-1[R(x)]^-1[T]^-1

Где T - матрица переноса, а R - матрица вращения. Можно их перемножить и получить матрицу с параметрами, которая делает искомую операцию. Ее и положить в функцию. Можно асмовой вставкой SSE подключить к этому делу.

Давай-ка выведи шаблонами эту матрицу чтобы не было повторения одних и тех же операций по 10 раз.

> А в чем он неправ?

К сожалению, правоту можно определить только видя сурсы рендера.

Однако, лично я например не вижу полиморфизма и наследования в сурсах крупного проекта на С в виде линукса, возможно это я плохо вижу. Хотя в ВУЗе у нас есть штамп что там реализовано ООП на Си.

>Матрица вращения на заданный угол вокруг точки c заданным направляющим единичным вектором выглядит так:

>[T][R(x)][R(y)][R(z)][R(y)]^-1[R(x)]^-1[T]^-1

>Где T - матрица переноса, а R - матрица вращения. Можно их перемножить и получить матрицу с параметрами, которая делает искомую операцию. Ее и положить в функцию. Можно асмовой вставкой SSE подключить к этому делу.

И что вас заставляет сомневаться в том, что на C++ можно написать шаблонную функцию именно для этого случая?

Впрочем, если вы не видите разницы между возвратом InputStream в Java и std::fstream в C++, то можете и не знать, что это возможно.

> Однако, лично я например не вижу полиморфизма и наследования в сурсах крупного проекта на С в виде линукса

Нунихренасебе.

> возможно это я плохо вижу.

Это не "возможно", это совершенно точно. grep 'struct .*_ops' *.h в include/linux, и наслаждайся невозбранным полиморфизмом. С наследованием дела похуже, но посмотри на libfs.

> Хотя в ВУЗе у нас есть штамп что там реализовано ООП на Си.

Это не штамп.

> В любом случае, это лучше чем mono

Лучше всего был бы C++ под Mono.

> Java - калл, но приходиться использовать так как пока не осилил на нужном уровне C++ (имхо).

Всё намного хуже. Приходится использовать, потому как жизнь заставляет. Библиотек под C++ просто нет (тех, которые нужны). Вся надежда на то, что GCJ когда либо поумнеет. :(

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