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

Труп мёртвого страуса... В топку быдлоподелие C++.

--- Это я говорю как программист который на этих самых С++ программировал больше 6 лет.

> Что мы тут будем шаблонизировать? Если кто-то напишет шаблон который произведение нескольких матриц превращает в параметризованный линейный оператор в compile-time, то это будет нормальным ответом.

хе-хе-хе. уже давно написали. http://www.oonumerics.org/blitz/

> Если фигней не заниматься, то ЦДТ работает нормально. Еще лучше он работает если писать код на Си - тут вообще без упрека.

хе-хе-хе. это называется добровольное анальное рабство.

>> Что мы тут будем шаблонизировать? Если кто-то напишет шаблон который произведение нескольких матриц превращает в параметризованный линейный оператор в compile-time, то это будет нормальным ответом.

>хе-хе-хе. уже давно написали. http://www.oonumerics.org/blitz/

Ну и как при помощи блица в compile-time собрать параметрический линейный оператор для осуществления одной конкретной операции - вращения точки вокруг произвольной оси? Ссылками кидаться я тоже умею.

> --- Это я говорю как программист который на этих самых С++ программировал больше 6 лет.

олололо!! Just another loser! Интересно, что же ты там такое программировал?

> Назови редактор получше, где "прыгнуть в имплементацию" по хоткею работало бы надежно.

Emacs + xrefactory очень надежно работает, т.к. содержит фактически front end компилятора для c++. Т.е. если код компилируется, то "прыжки" работают. Правда парсит он все довольно долго, из-за препроцессора (#ifdef) некоторые исходнкики по несколько раз парсит.

>> Товарищ обладает результатами тестов?

>Товарищ обладает 5 проектами и 27 патчами в сторону автора буста. anonymous (*) (29.06.2008 23:33:22)

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

Ты тупое неосилившее быдло. Иди быдлокодь на яве.

тебе понадобилось 6 лет, чтоб понять что язык тебе не подходит? кажется кто-то очень тормозит ;)

>Меня смешат выкрики быдлоанонимусов ...

>anonymous (*) (27.06.2008 23:19:05)

Какие ещё разновидности анонимусов известны науке?

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

> Вызывает operator*. Какая буква непонятна?

Из какого класса в каком файле?

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

> Ну и как при помощи блица в compile-time собрать параметрический линейный оператор для осуществления одной конкретной операции - вращения точки вокруг произвольной оси?

извини я не заметил слово compile-time. blizt предназначен для runtime операций. благодаря expression templates выражения типа:

Array<int,1> A, B, C, D; // ...

A = B + C + D;

раскрываются в: for (int i=A.lbound(firstDim); i <= A.ubound(firstDim); ++i) A[i] = B[i] + C[i] + D[i];

D?

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

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

>Что мы тут будем шаблонизировать?

Например, тип данных в матрице (float, double, complex<float>, complex<double>). Кроме того, expression templates легко позволяют несколько равноприоритетных операций выполнять в одно действие.

>Если кто-то напишет шаблон который произведение нескольких матриц превращает в параметризованный линейный оператор в compile-time, то это будет нормальным ответом. Иначе лучшее решение - перемножить эти матрицы на бумажке и закодить результат отдельной функцией.

Упс, а откуда появилось требование compile-time? Разговор шел в рамках противопоставления C++ чистому C, мол в C понято, что пишешь и mul_matrix читается лучше, чем a*b. И как в вашем любимом C или даже не менее любимой Java решается эта задача в compile-time?

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

>Ну а как мне вернуть std::fstream в С++? Наверно по указателю, разместив его в куче, да?

А вы думаете, в Java происходит как-то по другому?

C++ не нужен.
Набот нечитаемых конструкций и костылей.

>но пока времени нет

Когда появится, не трать егео понапрасну.

>дебил - это тот, кто говорит в таком тоне о том, о чем ничего абсолютно не знает, хоть я бустом и не пользуюсь - но 27 принятых патчей для столь популярной библиотеки о чем-то да говорят lester ** (*) (30.06.2008 7:07:40)

Можно конкретнее, для кокой именно библиотеки из тех что есть в boost, были патчи ? Очень хочется посмотреть. Вот список библиотек включеных в TR1 http://open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html, очень хочется узнать в какие из них, автор сделал 27 патчей. Не говоря о том, что он boost считает одной библиотекой и считает что у boost 1 автор. Это бред сивой кобылы.

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

Теперь рекурсивно смотрим на на ваш пост уважаемый lester.

> Упс, а откуда появилось требование compile-time? Разговор шел в рамках противопоставления C++ чистому C, мол в C понято, что пишешь и mul_matrix читается лучше, чем a*b. И как в вашем любимом C или даже не менее любимой Java решается эта задача в compile-time?

известно как ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v

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

>>Что мы тут будем шаблонизировать?

>Например, тип данных в матрице (float, double, complex<float>, complex<double>). Кроме того, expression templates легко позволяют несколько равноприоритетных операций выполнять в одно действие.

Зачем это надо если мы пишем рендер на даблах и завязаны на SSE/3DNow в критических местах?

>>Если кто-то напишет шаблон который произведение нескольких матриц превращает в параметризованный линейный оператор в compile-time, то это будет нормальным ответом. Иначе лучшее решение - перемножить эти матрицы на бумажке и закодить результат отдельной функцией.

>Упс, а откуда появилось требование compile-time? Разговор шел в рамках противопоставления C++ чистому C, мол в C понято, что пишешь и mul_matrix читается лучше, чем a*b.

Оттуда. Я написал что поворот точки вокруг произвольной оси я бы написал в виде отдельной функции. Вылез анальный раб копипаста-геинга и сказал что это неправильно, надо воспользоваться operator* на матрицах шесть раз. Я ответил, что он возможно прав если эту серию умножений можно развернуть в compile-time и получить из нее параметризованный линейный оператор.

>И как в вашем любимом C или даже не менее любимой Java решается эта задача в compile-time?

А я бы вообще не стал ее решать в compile-time. Разговор шел о том что operator* - это слишком мелкая операция. Я настаивал на том что логику надо раскладывать на более "крупные" блоки.

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

>>Ну а как мне вернуть std::fstream в С++? Наверно по указателю, разместив его в куче, да?

>А вы думаете, в Java происходит как-то по другому?

В Жаве есть некое единообразие как можно вернуть объект.

>известно как ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v ctrl-c ctrl-v anonymous (*) (30.06.2008 11:46:36)

Долой индуизмы !!!!!

>>Например, тип данных в матрице (float, double, complex<float>, complex<double>). Кроме того, expression templates легко позволяют несколько равноприоритетных операций выполнять в одно действие.

>Зачем это надо если мы пишем рендер на даблах и завязаны на SSE/3DNow в критических местах?

Не видел я здесь ограничений на счет рендера именно на даблах.

>>И как в вашем любимом C или даже не менее любимой Java решается эта задача в compile-time?

>А я бы вообще не стал ее решать в compile-time. Разговор шел о том что operator* - это слишком мелкая операция. Я настаивал на том что логику надо раскладывать на более "крупные" блоки.

Тогда какие претензии к С++? Он что, не дает вам решать задачи крупными блоками?

>>А вы думаете, в Java происходит как-то по другому?

>В Жаве есть некое единообразие как можно вернуть объект

В Java вообще нет возможность вернуть объект. Максимум, что вы можете вернуть -- это либо экземпляр элементарного встроенного типа (вроде long), либо _ссылку_ на объект.

Не знаю даже, что и читать: 8 страниц интервью или 12 страниц комментов...

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

ай ай как некрасиво. я прочитал всю ветку и не нашел такого поста.

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

>ай ай как некрасиво. я прочитал всю ветку и не нашел такого поста.

http://www.linux.org.ru/view-message.jsp?msgid=2882514&page=9#2888474

ЗЫ: А почему "анальный раб копипаста-геинга" поскипал? Я твои квотинги не редактирую.

> В Жаве есть некое единообразие как можно вернуть объект.

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

оба способа уродские, как и впрочем сама жаба.

> http://www.linux.org.ru/view-message.jsp?msgid=2882514&page=9#2888474

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

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

и где здесь написано про шесть раз? из поста совершенно очевидно следует, то что операции умножения и прочую векторную арифметику вручную пишут только м@даки.

>> В Жаве есть некое единообразие как можно вернуть объект.

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

InputStream[] getStreams(...)

>передачи по ссылке-то в жабе нет.

Нафиг такое уродство?

>> http://www.linux.org.ru/view-message.jsp?msgid=2882514&page=9#2888474

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

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

>и где здесь написано про шесть раз?

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

>из поста совершенно очевидно следует, то что операции умножения и прочую векторную арифметику вручную пишут только м@даки.

А как их писать если язык не может параметризованные линейные операторы выводить сам?

> InputStream[] getStreams(...)

а если типы разные? getPipe() // нужно вернуть InputStream и OutputStream

> Нафиг такое уродство? project_to_surface(const Point &from, double &u, double &v);

ты штоже выходные u и v тоже как массив double[] возхвращать будешь?

> А как их писать если язык не может параметризованные линейные операторы выводить сам?

да какие в ж-пу линейные операторы? из твоего поста совершенно ясно что ты против обычных векторных операторов *+- и т.п.

Цитата: >>> Кроме того, операции типа умножения - это слишком мелкие операции

вручную такие вещи пишут только копипаста-геи в терминальной стадии

>> А как их писать если язык не может параметризованные линейные операторы выводить сам?

>да какие в ж-пу линейные операторы? из твоего поста совершенно ясно что ты против обычных векторных операторов *+- и т.п.

Да, я против векторных операторов, так как это слишком мелкие операции. Нужно делать семейство функций которые будут формировать матрицы под конкретные преобразования.

>> Кроме того, операции типа умножения - это слишком мелкие операции

>вручную такие вещи пишут только копипаста-геи в терминальной стадии

А внутри operator* ты не вручную умножаешь? Что такое "вручную"?

>> InputStream[] getStreams(...)

>а если типы разные? getPipe() // нужно вернуть InputStream и OutputStream

Нужно возвращать oбъект Pipe с двумя полями. Это был бы довольно слабый ответ если бы в С++ не требовалось сделать то же самое.

>>> Нафиг такое уродство?

>>project_to_surface(const Point &from, double &u, double &v);

>ты штоже выходные u и v тоже как массив double[] возхвращать будешь?

Я бы вообще project_to_surface для одной точки не делал. Оно большими батчами должно оперировать. BTW ты как последний мудак пользуешься ссылками, которые являются костылем дла работы перегруженного operator[] и подобных.

> А внутри operator* ты не вручную умножаешь? Что такое "вручную"?

дебилом прикинутся решил?

Point p = o + v*f(t); // перегруженный оператор

// элитный сишный код ручной работы p.x = o.x + v.x*f(t); p.y = o.y + v.y*f(t); p.z = o.z + v.z*f(t);

> Я бы вообще project_to_surface для одной точки не делал. Оно большими батчами должно оперировать.

ты с темы-то не спрыгивай.

> BTW ты как последний мудак пользуешься ссылками, которые являются костылем дла работы перегруженного operator[] и подобных.

ЛОЛЧТО? какие еще операторы [] при возврате двух даблов?

капча boneras неспроста

>> А внутри operator* ты не вручную умножаешь? Что такое "вручную"?

>дебилом прикинутся решил?

>Point p = o + v*f(t); // перегруженный оператор

>// элитный сишный код ручной работы p.x = o.x + v.x*f(t); p.y = o.y + v.y*f(t); p.z = o.z + v.z*f(t);

Сравниваешь один вызов (если результат f(t) занести в переменную конечно же) с четырьмя явными и парой неявных конструкторов копирования?

PS: inline функции в С99 есть, если разговор вести дальше в эту сторону.

>> Я бы вообще project_to_surface для одной точки не делал. Оно большими батчами должно оперировать.

>ты с темы-то не спрыгивай.

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

>> BTW ты как последний мудак пользуешься ссылками, которые являются костылем дла работы перегруженного operator[] и подобных.

>ЛОЛЧТО? какие еще операторы [] при возврате двух даблов?

OUT - параметры по указателю надо делать. Ссылками пользуются одни мудаки.

> Сравниваешь один вызов (если результат f(t) занести в переменную конечно же) с четырьмя явными и парой неявных конструкторов копирования?

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

>> Сравниваешь один вызов (если результат f(t) занести в переменную конечно же) с четырьмя явными и парой неявных конструкторов копирования?

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

Я видел код который генерирует Intel C++ для перемножения матриц - меня не впечатлило, честно. Если заменить m[i][j] на m[(i << 2) | j] то немного лучше, но все равно не фонтан.

> OUT - параметры по указателю надо делать.

в жабе указателей тоже нет. пользуйся возвращаемым double[] и enjoy your AIDS

> Я видел код который генерирует Intel C++

конструкторов копирования сколько насчитал?

>> Я видел код который генерирует Intel C++

>конструкторов копирования сколько насчитал?

Столько же, сколько и в теории их должно быть.

> C++ не нужен. Набот нечитаемых конструкций и костылей.
> не трать егео понапрасну

да у вас то и русский такой же набор "ечитаемых конструкций" :)

>И это при том, что несоблюдение гарантий черевато в любом языке программирования (да, в C++ они самые тяжелые, но и в C#/Java легко оставить класс в некорректном состоянии после возникновения исключения).

в С++ они не более тяжелые чем в где либо. неконсистентные объекты, которые могут образоваться в результате ЛЮБЫХ неатомарных опраций над ними в результате возникновении исключения во время этих операций - очнь хреновая вещьбудь то жабА будь то ассемблер ибо поведение программы становится непредсказуемым. у жабАистов [у 99.(9)% ] правда таких проблем нет - они пишут просто ( что то типа ) 'catch (Exception e) { e.printStackTrace(); }' и нормально!

единственно преимущество жабА и .нет, это то, что там автоматом есть basic guarantee и это одно из отличий от С++, другое - это то, что обеспечить и потдерживать strong guarantee в С++ значительно легче.

>Но только в C++ об этом открыто говорят.

они просто не доросли (интеллектуально ) до этого. подавляющее большинство жабистов таких слов вообще незнают ( это из личных многолетних наблюдений ). под exception safety они понимают то, что в жабА можно отловить NullPointerException и написать волшебный 'e.printStackTrace();' а вот а галимом С++ av catch-ем не отловишь...

>Аналогия с Java. Обработки Exception, RuntimeException, Error дают разные степени уверенности в правильности кода и состояния объекта после них.

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

2vada
> C++ не нужен.

аватара говорит об обратном :)

> Бьярн Страустрап

4.2 Бьярне Строуструп

для аплогетов профессора Луговского
на домашней страничке BS есть
"короткий" список программ, библиотек написанных на C++
http://www.research.att.com/~bs/applications.html
(btw, упомянута прога, со-автором которой являюсь :)

>> Вызывает operator*. Какая буква непонятна?

> Из какого класса в каком файле?

А вот на это ответил принятый в вашей команде coding style и лично Ваше знание того языка, на котором Вы программируете.