Вышел Boost 1.35

>Зачем? Мне достаточно того, что у меня есть основания так думать

в том-то и дело, что нет, а тебе только так кажется =)

а вот возможность обрабатывать в одной функции разные типы параметров ты потеряешь безвозвратно. Напомнить тебе про костыль с названием Variant? =)

>Интересные мне языки изучаю потихоньку.

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

>Блин, еще и ты решил побыть Капитаном Очевидность?

вот ещё. Просто я на минтуку представил что произойдет с питоновскими __getattr__ и __setattr__ в случае статической типизации =)

>Всё это хорошо (quicksort на темплейтах действительно работает быстрее сишного кода), но при упоминании слов "научный расчёт" и "скорость" я почему-то сразу думаю про распределённые вычисления ;) А тут уже совсем другой огород

распределённые или параллельные ? если первое - то тут тебе ZeroC ICE и тот же Blitz++, либо Erlang с его аналогом FFI (ну либо тот же MsgCourier). если второе - то тут да, параллелить вычисления на C++ занятие неблагодарное. я бы писал на Haskell :)

> Александреску уже пол года как не появляется в конфах.

нет. месяца 2 назад был.

> Вы утверждаете, что он же предлагает вернуть вариант C++?

не вернуть, а сделанть немного подругому.

>Ну он и про плюсы жизнерадостно пишет

Александреску надо врачу показать

>Чисто конкретная аргументация. Для пацанов. ;)

есть мысль что это была шутка

>Александреску надо врачу показать

emacs doctor'у ? :)

>> Еще раз бугага. Ошибка может сильно зависить от потока исполнения, который зависит от данных. Здесь помогу скорее unit-тесты, но 100%-покрытия тестами не бывает, а 100%-проверка компилятором - обычное дело.

> можно подумать, ты сегфолтов никогда не видел. И то что сегфолты - это в том числе и обращение по неправильному указателю, возникающее из-за того, что в функцию передали не то - никогда не слышал, да? Причем не "не то значение" а именно "не тот тип структуры/объекта".

Блин. Сегфолтов я видел меньше, чем {Name,Attribute}Error. По приведенным тобой причинам обычно возникает не сегфолт, а молчаливое искажение памяти/неверная работа (что еще хуже). Сама передача в указателе адреса объекта не того типа в Си возможна только при насильном приведении типов, это решается runtime-поддержкой, которая есть в Питоне.

> Или в твоем уютном мирке все параметры передаются по значению? =)

Не удержался от наезда, ага? :D

> я на минтуку представил что произойдет с питоновскими __getattr__ и __setattr__ в случае статической типизации =)

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

>>Ну он и про плюсы жизнерадостно пишет

>Александреску надо врачу показать

Кстати, Алекс Степанов рыбой фугу передознулся в японском ресторане и лежал в отделении интенсивной терапии в состоянии дилириума (тяжелого болезненного бреда). Тогда ему и пришел в голову концепт STL.

> распределённые или параллельные ? если первое - то тут тебе ZeroC ICE

Distributed. ICE - это всё равно наполовину ручная работа, вносящая, к тому же, посторонние элементы непосредственно в расчёты.

> Кстати, Алекс Степанов рыбой фугу передознулся в японском ресторане и лежал в отделении интенсивной терапии в состоянии дилириума (тяжелого болезненного бреда). Тогда ему и пришел в голову концепт STL.

А Ньютон черепно-мозговую получил :) А Менделеев алкогольное отравление получил. Надо же как-то от бремени реальности отрываться ;)

>Блин. Сегфолтов я видел меньше, чем {Name,Attribute}Error

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

>По приведенным тобой причинам обычно возникает не сегфолт, а молчаливое искажение памяти/неверная работа

в 90% это все равно приводит к сегфолту. Эффект домино никто не отменял =)

>Сама передача в указателе адреса объекта не того типа в Си возможна только при насильном приведении типов

насильственное приведение типов - обычная практика. Более того - без этого _никуда_ в программах сложнее чем printf("йакреветко\n"); =) так что твои 100% эффективности статической типизации - это, увы, всего лишь фантазии =)

>Не удержался от наезда, ага? :D

окстись, ты прекрасно знаешь, что такое _наезд_ с моей стороны =)

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

что значит "что должен позволять" ? типа "вот это у нас статически типизируется, а вот это - динамически" ? С таким подходом я гарантирую тебе непрекращающуюся головную боль =)

>Кстати, Алекс Степанов рыбой фугу передознулся в японском ресторане и лежал в отделении интенсивной терапии в состоянии дилириума (тяжелого болезненного бреда). Тогда ему и пришел в голову концепт STL.

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

> Просто я на минтуку представил что произойдет с питоновскими __getattr__ и __setattr__ в случае статической типизации =)

А ведь кто-то предлагал добавить такую штуку в D со статической типизацией. И даже подробно описал как оно будет работать. К счастью его быстро заткнули.

>Distributed. ICE - это всё равно наполовину ручная работа, вносящая, к тому же, посторонние элементы непосредственно в расчёты

а что ты предлагаешь в таком случае ?

> а что ты предлагаешь в таком случае ?

Язык, более удобный для расчётов (каких, кстати?) и прозрачно поддерживающий распределённость.

>>Блин. Сегфолтов я видел меньше, чем {Name,Attribute}Error

>я думал что ты девелопер =)

Я аккуратный девелопер.

>>Сама передача в указателе адреса объекта не того типа в Си возможна только при насильном приведении типов

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

Даже в Си - нет (исключаем специальный случай void * как generic pointer). Тем более, что речь о Питоне, с RTTI и reflection.

> без этого _никуда_ в программах сложнее чем printf("йакреветко\n")

Я начинаю понимать, где ты видел эти тонны сегфолтов.

> твои 100% эффективности статической типизации - это, увы, всего лишь фантазии =)

Еще раз повторю - это так _в Си_.

> типа "вот это у нас статически типизируется, а вот это - динамически" ?

Возможно. У меня нет дизайна языка.

> С таким подходом я гарантирую тебе непрекращающуюся головную боль =)

Меньше, чем сейчас.

>Язык, более удобный для расчётов (каких, кстати?) и прозрачно поддерживающий распределённость

о том и вопрос. что это за чудо-язык ?

>> Язык, более удобный для расчётов (каких, кстати?) и прозрачно поддерживающий распределённость

> о том и вопрос. что это за чудо-язык ?

Прозреваю Occam3 8)

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

ключевой момент ... пользователям свою программу покажит... они иногда умудряются так использовать программу, что диву даешься ... и будет тонна Name,Attribute}Error-ов, стопудова ...

>Я аккуратный девелопер.

это фантастика. Нет, правда.

>Даже в Си - нет (исключаем специальный случай void * как generic pointer). Тем более, что речь о Питоне, с RTTI и reflection.

в си - да. Всё-таки =) Видимо, аккуратные девелоперы программируют только в тех областях, где можно программировать аккуратно без приведения типов =))))))

в питоне - пожалста пример: список разнотипных объектов. И foreach + print :) . И что делать? :)

>Еще раз повторю - это так _в Си_.

видимо, плюсовые программы, которые, к слову падают чаще просто потому что работа с памятью там сложнее - на самом деле не падают, а просто присаживаются отдохнуть =)

>Возможно.

по рукам. Линейкой. Чугуниевой :)

>Меньше, чем сейчас.

больше =)

>>Создаёшь 2 объекта с методами __del__, и делаешь между ними циклическую ссылку.

>а зачем ТАК делать? О_О

- Доктор, когда я вот так делаю, у меня тут болит

- А Вы так не делайте!

=)

>> Хм.... ACE?

>Ice?

http://www.cs.wustl.edu/~schmidt/ACE.html

Ну они и названия генерят: Ace, Ice:))

А что, нельзя было? Там же прерывание по кондишену, насколько я понял..

>>Еще раз повторю - это так _в Си_.

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

У Си++ есть все проблемы Си и еще свои специфические. Так что практически всё, что я сказал о Си (кроме void *), относится и к Си++. Но вот работа с памятью в Си++ не сложнее.

> У Си++ есть все проблемы Си и еще свои специфические. Так что практически всё, что я сказал о Си (кроме void *), относится и к Си++. Но вот работа с памятью в Си++ не сложнее.

Даже проще за счет шаблонов и деструкторов (что позволяет получать вещи типа auto_ptr/shared_ptr).

>Ну они и названия генерят: Ace, Ice:))

всё-таки SFINAE круче всех :)

>> Ну они и названия генерят: Ace, Ice:))

> всё-таки SFINAE круче всех :)

SNAFU круче всех 8)

>__del__ и деструуторы питоне не нужны. И __init__ в каждом классе - тоже не нужен, если подумать.

да и питон не нужен. если подумать, конечно.

>Но вот работа с памятью в Си++ не сложнее.

в итоге - сложнее. Если угодно - компилятору _труднее_ проверить выверты программерского разума, потому что всякие втбл, конструкторы, перегрузки, виртуальные функции ВНЕЗАПНО превращающиеся в инлайны и прочие прелести языка =)

>Даже проще за счет шаблонов и деструкторов (что позволяет получать вещи типа auto_ptr/shared_ptr).

Вот что действительно раздражает это когда вылезает какой-то "Асиливший Сиплюсплюс" и начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали. Например, про аллокацию дополнительного объекта со счетчиком ссылок размером в четыре байта, что фрагментирует память так как malloc() расчитан на аллокацию блоков по несколько KB. Или про работу с тредами - ведь инкрементировать/декрементировать счетчик ссылок надо с помощью interlocked increment/interlocked decrement. И при этом как-то обмениваться этими shared_ptr с однотредовым бэкэндом где interlocked функции - это лишний оверхед.

>> __del__ и деструуторы питоне не нужны. И __init__ в каждом классе - тоже не нужен, если подумать.

> да и питон не нужен. если подумать, конечно.

Это у нас так преподаватель по С++ говорит, а он конечно же заблуждается %)

> Прикольная либа. Но причем тут CLOS?

Ну собсно CLOS - не причем, если строго судить.

> Насколько я понял, Intelib реализует Схему, а не CL.

Это пример стона продвинутых C++-ников и их латентного желания быть лисперами/сшемерами :

> начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали.

То, что ты в разговоре о "auto_ptr/shared_ptr" жалуешься исключительно на счетчик ссылок и фрагментацю, показательно.

> И лицензия у них приятная, без ГНУтых закидонов.

И тут меня осенило, почему же FreeBSD была в РФ долгое время популярнее GNU/Linux....

>>Даже проще за счет шаблонов и деструкторов (что позволяет получать вещи типа auto_ptr/shared_ptr).

>Вот что действительно раздражает это когда вылезает какой-то "Асиливший Сиплюсплюс" и начинает втирать про auto_ptr/shared_ptr. И эти асилившие не удосуживаются вникнуть в детали.

Да, я такой! :)

> Например, про аллокацию дополнительного объекта со счетчиком ссылок размером в четыре байта, что фрагментирует память так как malloc() расчитан на аллокацию блоков по несколько KB.

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

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

А если вам так жалко лишних 4-х байт, то ведь шаблоны в C++ позволяют реализовывать вещи типа intrusive_ptr из того же Boost-а.

> Или про работу с тредами - ведь инкрементировать/декрементировать счетчик ссылок надо с помощью interlocked increment/interlocked decrement. И при этом как-то обмениваться этими shared_ptr с однотредовым бэкэндом где interlocked функции - это лишний оверхед.

А вы посмотрите на ACE_Refcounted_Auto_Ptr и макрос ACE_SYNCH_MUTEX для случая, когда приложение компилируется под однопоточный режим. Опять же ACE_Refcounter_Auto_Ptr построен на C++ных шаблонах.

>Это пример стона продвинутых C++-ников и их латентного желания быть лисперами/сшемерами

блин, чувствую что жизнь проходит мимо. ну дайте ссылку на стоны ! :)

см. публикации и заметки Столярова на указанном сайте.

>см. публикации и заметки Столярова на указанном сайте.

*ушёл просвещаться*

>Я бы сказал что конструкторы в С++ по факту ненужны.

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

>ключевой момент ... пользователям свою программу покажит... они иногда умудряются так использовать программу, что диву даешься ... и будет тонна Name,Attribute}Error-ов, стопудова ...

и сегфолтов, происходящих раз в месяц, ты тоже огребёшь, как будто не знаешь :)

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

Если много напрограммить на С++, то может появиться мысль, что C++ - велик и могуч, а остальные языки - не нужны. То есть, думать человек в худщем случае совсем перестает >_<

>> питон не нужен. если подумать, конечно.

> Это у нас так преподаватель по С++ говорит, а он конечно же заблуждается %)

Человек, утверждающий, что пятон не нужен, не может заблуждаться.

> Человек, утверждающий, что пятон не нужен, не может заблуждаться.

Кирилл Леонидович, перелогиньтесь пожалуйста!

>Если много напрограммить на С++, то может появиться мысль, что C++ - велик и могуч, а остальные языки - не нужны.

А может и не появиться :)

>То есть, думать человек в худщем случае совсем перестает >_< Взрыв мозга бывает от самых разных симптомов, и язык здесь далеко не на первом месте :)

> о том и вопрос. что это за чудо-язык ?

Такого чудо-языка не придумали. Нет, конечно, есть QLisp, но сам автор называет его низкоуровневым. Хорошим приближением является NetCLOS, но полной прозрачности мешает отсутствие MOP для не-CLOS части языка. Соответственно, все динамические вещи не могут быть отрефлешкены и остаются на одном хосте. Что-то ещё схемное находил, но сейчас не могу вспомнить название ;)

> Если много напрограммить на С++, то может появиться мысль, что C++ - велик и могуч, а остальные языки - не нужны. > А может и не появиться :)

Однако, корреляция отличается от нуля :(

>Такого чудо-языка не придумали. Нет, конечно, есть QLisp, но сам автор называет его низкоуровневым. Хорошим приближением является NetCLOS, но полной прозрачности мешает отсутствие MOP для не-CLOS части языка. Соответственно, все динамические вещи не могут быть отрефлешкены и остаются на одном хосте. Что-то ещё схемное находил, но сейчас не могу вспомнить название ;)

не канает. если к вопросу именно о распределённых вычислениях, то есть erlang. но он так же как и LISP'ы не даёт производительности на каждом отдельном хосте, сравнимой хотя бы с C. т.е. на C++ + ICE написать приложение сложнее (хотя прямо скажем не так уж и сложно, благо система продумана хорошо), но оно будет заведомо производительней аналогичного на LISP'е. или нет ?

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

sS на вас нет.