Здравствуйте, VladD2, Вы писали:

ГВ>>Тут на самом деле не в C++ всё упирается, а в фон-неймановскую модель компьютера. Хорошо бы от неё свалить, но — увы, увы. Пока что.
VD>Да не причем тут абстрактные машины. Кто хотел свалил. Есть и дотнет, и ФЯ/ЛЯ и много чего еще.

От фон-неймановской модели — свалить?

ГВ>>Ну, я так думаю, что это будет способствовать развитию языка. Почему? Потому что меньше бестолкового шума будет подниматься. И потому, что останутся те, кто не думает расставаться с подобной культурой программирования. Хотя может быть, что C++ в конечном итоге вообще исчезнет с программистского горизонта. Значит — появится что-то, что намного лучше. Ну и фиг тогда с ним будет.
VD>Да они появляются причем некторые ооочень давно...

Угу, поверю на слово, ибо глазам своим уже давно не верю. Вроде была разработка C++ с ограничениями — D, что ли...

ГВ>>Проблема не в этом. Проблема в том, что C++ на сегодня чуть ли не единственный, кто позволяет оптимизировать программу вплоть до уровня, сопоставмимого с ассемблером.
VD>Да что-то я тут разницы с паскалем (дельфи) не замечаю. Да и до ассемблера С++-у далеко. А оптимизация она зависит не от языка, а от оптимизатора. А его можно почти для всего улучшать до предела. Достаточно сравнить оптимизаторы того же VC6 и VC8.

Можно... Нельзя... Да, вообще-то можно почти всё. Но есть разница. В одном случае я могу всё сделать сам не дожидаясь реакции производителя, а вот в остальных... И почему-то совсем не каждый юзер желает немедленно обновлять парк техники по случаю выхода очередной версии Windows, .Net или JDK... Doom3 как-то лучше стимулирует.

ГВ>> При этом — оставаясь яыком высокого уровня, от культуры и основных принципов которого ни Java ни C# на сегодня очень недалеко ушли.
VD>Да ушли, ушли. Их уже постоянно называют языками высокого уровеня в том, смысле что это уровень выше чем у С++.

Абстракции над железом-то? Да, верно. В том-то и проблема.

ГВ>> А если называть вещи своими именами — то ещё и не догнали.
VD>Ну, это если совсем уж потерять связь с рельностью.

Виртуальной? Ну может быть. Если да, то скажи — с какой именно? А то их много тут развелось.

ГВ>> Вот когда я смогу гладко вписать в C# (а равно и в Java) регистровую модель процессора — вот там и поговорим.
VD>Да нет смысла в 21 веке вообще говорить о регистрах и процессоре. 21 век — век абстракции. А процессоры и их регистры — это удел тех немногих кто пишит оптимизирующие компиляторы и имподобные вещи, а так же драйверы (хотя там уже не факт).

Однако — приходится. И с этим уже ничего не поделаешь.

VD>Миф о тормознутости дотета или явы устаривает с каждым годом. Они и сейчас не уступают многим компиляторам. А завтра вообще превзойдут всех их из-за возможности динамической оптимзации.

Знаешь, в чём проблема Java на самом деле? Не в плохом оптимизаторе, а в мифе, что "... больше не ресурс" и "в 21 веке ...". И эти два мифа напрочь срезают весь хот-спот. Отказаться от этих мифов — потерять преимущества Java. Не отказываться — потерять в скорости продукта. Может быть и не так резко, но примерно так.

ГВ>>...Выводы, как грится, делайте сами. Для ленивых выскажу кое-какие из своих.
VD>Так и что твой рассказ то доказывает? Что медленную реализацию можно ускорить? Или ты считашь что доказал несостоятельность Явы таким макаром?

Главный вывод — что Java способствует мифотворчеству о возможности игнорирования физики компьютеров. Спору нет, это всё возможно — но только до определённых пределов.

ГВ>>1. Java — неплохое средство (не скрою — во многом она мне нравится своей стройностью), но увы. С управлением памятью всё пока ещё не слишком гладко.
VD>Да все там ОК с памятью. Просто думать нужно как эффективнее алгоритмы делать. Единственное что в Яве с памятью не здорово, так это отсуствие структур. А так...

Правильно, Влад. Думать. А это становится принято всё менее и менее. Не в Java, естественно, дело, а в прокладке. А прокладка формируется в том числе и инструментом. Т.е. — языком прорамирования. Чуешь, к чему клоню?

VD>Сдается мне, что вера в скорость плюсов тебя подводит.

Да какая ещё "вера"? Реальность, дружище. Реальность в виде микросекунд и мегабайтов. И наблюдения за оной с линейкой и секундомером.

VD>Разбираться нужно или достконально, или вообще не разбираться. На уровен "вот одна реализация работает лучше другой на другом языке" можно наделать любых выводов. С Явой я особо не работаю. Знаю ее по тестам. Но скажу, что она медленнее дотнета всего чуть, чуть. А дотнет мало чем уступает тому же 6-ому VC. Так что если хочешь доказать обратно, то приводи конкретный код и тесты. Поглядим... сравним... поправим и перемерим.

Ну так встань, да посмотри... Если не путаю — www.log4j.apache.org и www.log4cpp.apache.org. Кроме того, ИМХО, log4j вполне даже показательный пример. Apache foundation, как-никак, почти наверняка много неглупого народу руки приложило. Всё — чин-чинарём.

ГВ>> Как следствие того, что имеются:
ГВ>>а) небесконеченость конкретного компьютера;
VD>Серьезный аргумент. Я его даже не понял.

Да не, всё в порядке. INFINITE_LOOP.Duration == 7 seconds. Memory is infinite. Sky is blue. Go to sleep, everything is all right.

ГВ>>б) модель уважаемого Фон-Нефймана, которая, к сожалению — рулит;
VD>О! Еще белее серьезный аргумент. Жаль связь не просматривается.

Ну как. У нас есть один процессор. Есть ограниченное количество памяти. Есть долговременное хранилище. Добавим, что есть пространство адресов процессора и т.д, и т.п. Впрочем — да, INFINITE рулит, я и забыл. Даже синхронизация кэшей процессоров — так, чушь на ровном месте.

ГВ>>в) необходимость культуры програмирования компьютеров на том же C++. А не вой относительно "ОО — рулез форева" или "темплейты — рулез там же".
VD>Ну, культура она конечно и производительность поднимает и сложность задачи понижает. Вот только почему-то код на плюсах особо быстрее от этого не становится, и глюки в нем так тоннами и остаются. Как не спросишь С++-программиста, так у него ошибок нет. Это все у других. А как запустишь какую С++-программку так она все глючит и глючит.

Ещё раз. Я не знаю причин по которым log4j обладает той архитекторой, которой обладает. Возможно, что архитектуру можно было сделать другой. Выбрали ту, что выбрали. Но её аналог на C++ даже с учётом того, что там фигачатся std::string по значению и сплошняком virtual — практически вдвое быстрее.

Да, кстати, о глюках речи и не было. Любая программа может глючить. RSDN@Home тоже глючит, но тем не менее мне вот он нравится.

ГВ>>А потом уже — тесты на шустрость. И вот тут поглядим: кто — кого, откуда, куда, почему и откуда издержки.
VD>Да мы уже поглядели. Да не раз. И что-то никак не разглядим. А вот упрощение и ускорение разработки видно довольно четко.

Если ты сделал что-то быстро, но плохо, то люди быстро забудут о том, что ты сделал это быстро, но будут помнить о том, что это было плохо. А если сделал хорошо, но медленно — люди тоже забудут о том, что ты сделал медлено, но будут помнить о том, что это было — хорошо. (c) пословица.

Здравствуйте, VladD2, Вы писали:

ГВ>> Вот когда я смогу гладко вписать в C# (а равно и в Java) регистровую модель процессора — вот там и поговорим.

VD>Да нет смысла в 21 веке вообще говорить о регистрах и процессоре. 21 век — век абстракции. А процессоры и их регистры — это удел тех немногих кто пишит оптимизирующие компиляторы и имподобные вещи, а так же драйверы (хотя там уже не факт).

Внесу свои пять копеек. Забудем о регистрах, тем более, что я и сам стараюсь никогда не опускаться до такого уровня. Программист, использующий .NET или Java, существенно зависит от разработчика соответствующего Framework`а, потому что без него родимого вы практически ничего сделать не сможете. Сложность нестандартной задачи — задачи, не решаемой напрямую или косвенно фраймоворком, возрастает многократно. Скажем, если в том же .NET`е не реализована какая-нибудь функциональность операционной системы, вам приходится решать совершенно отвлечённые задачи: куда в вашу иерархию классов встроить класс, на который будут мапироваться нативные вызовы к операционной системе, какие именно функции ОС вам придётся импортить, выполнить импорт этих функций и при этом не ошибиться при декларации их параметров и наконец отладить всё это... Может быть со временем вся винда будет на .NET и в MSDN`е описание функций будет приводиться для C# (хотя я в это не верю), но до тех пор увы...

VD>Миф о тормознутости дотета или явы устаривает с каждым годом. Они и сейчас не уступают многим компиляторам. А завтра вообще превзойдут всех их из-за возможности динамической оптимзации.

Всё это домыслы. Вот если вы напишете какой-нибудь реальный проект в 2-ух экземплярах на 2-ух языках, на плюсах и шарпе, вот только тогда можно будет говорить о сравнении производительности. Тесты ничего не показывают, я видел кучу тестов, которые показывают что Java медленнее плюсов и такое же количество, демонстрирующих обратное. С помощью тестов можно на заказ продемонстрировать и достоинства и недостатки.
Кстати, ответьте мне вот на какой вопрос. Почему-то когда говорят о том, что динамическая оптимизации может существенно увеличить быстродействие программы, написанной на шарпе, по сравнению с плюсами, забывают о нижеследующей вещи. Код нативных программ мапируется в память непосредственно из своего файла, следовательно процедура выгрузки страниц кода, при нехватке памяти, не будет приводить к операциям чтения/записи с винчестера. Нативный код, получаемый из байт-кода JIT`ом, будет располагаться в общей памяти и следовательно при необходимости выгрузки страниц, они будут явно выгружаться в страничный файл, что будет сопровождаться активными операциями чтения/записи данных с жёсткого диска. При большом размере программы, это может свести на нет всю динамическую оптимизацию... Или я где-то ошибаюсь, или кое-кто умалчивает об этой "возможности".

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хммм... так. Сейчас как раз этим примерно и занимаюсь. Возможно, что я и ошибаюсь. Во всяком случае — кое что для солярки по части манагёра памятей я уже делал. Ты, кстати, какую версию Solaris имеешь ввиду? И какой компилятор? GCC или Forte? И кстати — что-то я не помню проблем при передаче std::string из одного .so в другой...
С сошками другая проблема. Если хочешь могу по почте рассказать о истории пререхода с gcc на Sun C++. Про прыжки вокруг двух STL'ей
в Sun C++ и строк в gcc. Здесь это уже офтопиком будет.

AC>>Таки Альксандреску вбивает читателям именно эту идею. Не надо забывать, что шаблоны (статическая параметризация) это ОДИН из МНОЖЕСТВА вариантов решения задачи, не единственный и не всегда самый лучший.
ГВ>ИМХО, он вбивает чертовски правильную идею: "Товарищи! Переносите контроль на компилятор, а не на тестеров!" И только-то... Что
Хм, тоесть ты хочешь сказать, что параметризация шаблона стратегией боле типоустойчива, чем параметризация конструктора обьекта интерфейсом стратегии? Задачу динамического конструирования или оптимизации через инлайнинг не рассматривает, рассматриваем именно типоустойчевость. Типоустойчевость вообще очень интересное понятие.... о нем долго можно говорить. То о чем ты говоришь, это проблемы студентов которые пошли в индустрию Которые, кстати, очень часто вспоминают перечисленных авторов, по поводу и без.

ГВ>Да, кстати, а Алексндреску-то тут при чём?
На него чаще всего ссылаются, причем не на то, что он придумал и/или развил, а на то, что 'круто' изложил. И иcходя из твоих слов, если я не согласен, что его идеи 100% истина, я плохой программер. С этого топик и начинался.

ГВ>PS. Кстати, ты уж прости, но всё-таки — пробовал. Не сочти за наезд, но это тот случай, когда я готов получить свой законный moderatorial "+". (c) FIDO.
Мне жена все время об этом говорит, а я каждый раз забываю.

Здравствуйте, Шахтер, Вы писали:

AC>>>Александреску и Маерс это плохие специалисты, я про то, что их книги это популизация методик
K>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг.
K>>А вот Саттера и Мейерса очень рекомендую.
K>>Именно как популизацию грамотного стиля и методик программирования на C++.

Ш>Все трое -- ламеры.

Один ты — крутой кулхацкер?

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

И понимаешь, насколько нам эта песня "строить и жить помогает"

Здравствуйте, Шахтер, Вы писали:

Ш>Здравствуйте, jazzer, Вы писали:

J>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>Не судьба мне у тебя работать.

Ну, если ты предпочитаешь писать свои велосипеды — да.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, WolfHound, Вы писали:

WH>Ну там тоже есть приятные библиотеки. Например boost/preprocessor иногда очень полезна и ее использование вобщем ни чего не стоит.

Хотя мне и нравится буст, не удержусь от подколки.
Результат препроцессирования

#include <boost/preprocessor.hpp>

— это 85 тысяч строк (большей частью — пустые), файл размером 295 килобайт, если оставлять #line, или 170 килобайт, если не оставлять.

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, jazzer, Вы писали:

JJ>>И все потому, что в той фирме как раз и сидят такие люди, которых жутко прет писать свои классы, а гемор, который потом придется разгребать пользователям их чудо-класса — это уже не их дело, даже наоборот — пока есть баги, нужна их поддержка, т.е. к ним приедет еще бабла, и т.д., и т.п.
AC>Что-то мне подсказывает, что STL и BOOST там не помогут, хотя возможно я и ошибаюсь
ошибаешься

а по поводу многопоточности и прочего — так проект так до сих пор и сидит в прошлом веке, потому что эти самые третьесторонние велосипеды и не думали ничего поддерживать и об этом задумываться.
Это при том, что существует не одна реализация STL, тот же упомянутый Sun C++ с какой-то версии идет с STLPort, и если есть бага в одной — заюзай другую, благо они нормально поддерживаются.

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

Кто там что говорил о типобезопасности?
Шаблонов в этой велотеке нет — все на макросах.
Что ты там говорил о хипе?
В контейнерах нашей велотеки можно хранить только указатели — угадай, где приходится размещать объекты, и сколько гемора потом с очисткой памяти. И это практически делает невозможным использование исключений. Что у нас от С++ в итоге осталось?

Еще нужны аргументы?

P.S. А рядом сидит проект, написанный с нуля на STL — и они горя не знают, и у них на марше и многопоточность, и многопроцессорность, и исключения, и все прочие радости жизни, и горя они с STL (STLPort) не знают. При том, что пишут они высокопроизводительный сервер.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Правильно, потому что ответом на "новое направление" часто может быть только новая группа шаблонов. Чего шум-то поднимать?

К>>Этак можно всё вообще свести к макросам. Например, базовые библиотеки TurboPascal 5.5 кто-нибудь видел? ООП на макроассемблере...
ГВ>Э, не путай калий с кальцием. Шаблоны и макросы — не одно и то же. Хм. Кодт, это я тебе рассказываю или у тебя дубль появился?

Не, я не путаю, а гиперболизирую.
Разумеется, С++ достаточно силён, чтобы выразить разнообразные вещи. Но цена будет разная. Местами — катастрофическая.

Здравствуйте, _alm_, Вы писали:

__>Фортран (насколько я знаю, общаясь с людьми, которые до сих пор предпочитают реализовывать алгоритмы на нем) живет за счет того, что несмотря на то, что его BNF грамматика была выведена тык-скыть "апостериори", дерево разбора проги на Фортране цитирую "лучше оптимизируется, чем С". Я — не могу понять (если честно) как так может быть. Но (в качестве косвенного доказательства) — Ватком до последнего развивал как С/С++, так и Фортран.

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

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Alexey Chen, Вы писали:
J>а по поводу многопоточности и прочего — так проект так до сих пор и сидит в прошлом веке, потому что эти самые третьесторонние велосипеды и не думали ничего поддерживать и об этом задумываться.
Удивительно как люди разделяют эпохи — до STL и после STL, другого не дано в принципе. Эта ограниченость мышления тоже ведь последствие безальтернативного наследия популистов

J>Это при том, что существует не одна реализация STL, тот же упомянутый Sun C++ с какой-то версии идет с STLPort, и если есть бага в одной — заюзай другую, благо они нормально поддерживаются.
И обе в чем-то криво, каждая в своем. Это не предположение, это факт.

J>Что ты там говорил о хипе?
J>В контейнерах нашей велотеки можно хранить только указатели — угадай, где приходится размещать объекты, и сколько гемора потом с очисткой памяти. И это практически делает невозможным использование исключений. Что у нас от С++ в итоге осталось?
Я вообще-то конкретный пример привел, а ты как обычно скатился в общности.... сувать STL, как и буст во все щели не есть верное решение.
В своем рвении твой подход мало отличается от подхода людей писавших ту лбу, это просто другая крайность.

J>Еще нужны аргументы?
ИМХО, это не аргументы, это эмоции по поводу того как все плохо. Впрочем, мой топик тоже эмоции

Здравствуйте, jazzer, Вы писали:

J>>>Так что как только я слышу слова: "STL большая и страшная, и что еще хуже — модная, давайте лучше быстренько напишем свой класс списка" — я очень жалею, что я не менеджер и не могу этого человека немедленно уволить.

Ш>>Не судьба мне у тебя работать.

J>Ну, если ты предпочитаешь писать свои велосипеды — да.

Может STL конечно и супер. Но вот класс списка в ней воистину отстойный. И класс string тоже. Про iostream можно не говорить — это только для hello word годится. Двумерного массива в СТЛ нет видимо из за того что не вписывается в концепцию итераторов. И вообще хорошо бы ей всю кровь сменить и все органы пересадить, тогда авось и выйдет че-нить путное.

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

Здравствуйте, jazzer, Вы писали:

J>А я вот вспоминаю свои собственные впечатления, когда в однострочной формуле из квантовой механики разбираешься месяц.
Ну ты крут! Мало кто может за месяц понять сакральный смысл E=Hф

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, jazzer, Вы писали:

J>>А я вот вспоминаю свои собственные впечатления, когда в однострочной формуле из квантовой механики разбираешься месяц.
S>Ну ты крут! Мало кто может за месяц понять сакральный смысл E=Hф

Щас я обьясню сакральный смысл. Сакральный смысл состоит в том что:
1) сначала смотришь на формулу и ломаешь голову что же это такое?
2) месяц разбираешься что же это такое
3) когда разобрался думаешь, а зачем разбирался? что получил?

Т.е. в итоге имеешь геморой вначале, геморой в середине, геморой в конце. Вот такой сакральный смысл.

Здравствуйте, VladD2, Вы писали:

VD>Все нижесказанное мое личное мнение:

VD> и на сегодня С++ не отвечает современным требованиям рынка.

А в чем конкретно не отвечает не мог бы рассказать подробнее?

VD> Шарп/дотнет и Ява уже отъели немалый кусок рынка у С++ и отъедание продолжается. Если С++ не будет развиваться дальше, то все Бусты и Алексондреску ему не помогут.

Что значит развиваться дальше и в каких различных направлениях?


Мне здесь вообще сам подход к оценке языка неприятен. Как я понял, основным критерием оценки языка у автора является фактор его распространенности на рынке. Ну, соответственно, и развитие понимается также как отвоевание большего места на этом самом рынке. С этой точки зрения все логично: два основных критерия — это простота и надежность. Простота, потому что программисты у нас такие — сложного не поймут, а надежность — тоже потому, что программисты у нас такие, дай волю, такого понапишут, что сам страуструп с кнутом без бутылки не разберутся. Вот это и есть развитие. Но, с другой стороны, такой язык уже есть и завоевал свое законное первое место на рынке, доказав наглядно свое преимущество, это бейсик. Отвечает обоим критериям в высшей степени.

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

Здравствуйте, Alexey Chen, Вы писали:

AC>Здравствуйте, jazzer, Вы писали:

J>>Здравствуйте, Alexey Chen, Вы писали:
J>>а по поводу многопоточности и прочего — так проект так до сих пор и сидит в прошлом веке, потому что эти самые третьесторонние велосипеды и не думали ничего поддерживать и об этом задумываться.
AC>Удивительно как люди разделяют эпохи — до STL и после STL, другого не дано в принципе. Эта ограниченость мышления тоже ведь последствие безальтернативного наследия популистов :)

ну почему же
STL не появилсь на пустом месте, были же общепризнанные библиотеки от Rogue Wave, например

Удивительно, что люди, зная о существовании нормальных оттестированных библиотек, пишут свои велосипеды, которые дай бог чтобы на 30% покрывали возможности этих библиотек и давали хотя бы 40% их устойчивости, и кричат на всех углах, что они круче всех. И их крикам верят все, кроме несчастных пользователей их велосипедов.

J>>Это при том, что существует не одна реализация STL, тот же упомянутый Sun C++ с какой-то версии идет с STLPort, и если есть бага в одной — заюзай другую, благо они нормально поддерживаются.
AC>И обе в чем-то криво, каждая в своем. Это не предположение, это факт.
охотно верю.
Только вот пользователей (и, соответственно, тестеров) любой "всеобщей" библиотеки типа STL, причем доступной в исходниках, ибо шаблоны, и ее конкретных инкарнаций типа STLPort на порядки больше, чем может теоретически быть у пользователей любого самописного велосипеда, особенно если он поставляется еще и без исходников.
Соответственно чисто статистически надежность ее выше, особенно при том, что библиотека постоянно обновляется (вон, даже Павел Кузнецов туда чего-то закинул).

J>>Что ты там говорил о хипе?
J>>В контейнерах нашей велотеки можно хранить только указатели — угадай, где приходится размещать объекты, и сколько гемора потом с очисткой памяти. И это практически делает невозможным использование исключений. Что у нас от С++ в итоге осталось?
AC>Я вообще-то конкретный пример привел, а ты как обычно скатился в общности.... сувать STL, как и буст во все щели не есть верное решение.

Я же в самом начале сказал, что работаю (сам, лично) в таком проекте. Конкретика хуже некуда :(

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

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

J>>Еще нужны аргументы?
AC>ИМХО, это не аргументы, это эмоции по поводу того как все плохо. Впрочем, мой топик тоже эмоции :)

Для меня это — более чем осязаемые агрументы, потому что я уже почти три года все никак не могу вытащить свою штанину из жвалов нашего велосипеда.
И это при том, что, как я уже говорил в удаленном тобой тексте, рядом сидит успешный проект на STLPort, живущий около трех лет, и у них не уходит 80% рабочего времени на сражение с собственной библиотекой; они делают дело и очень довольны жизнью.

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Кодт, Вы писали:

К>Есть же ряд вещей, которые удобнее, будучи свойствами языка, а не извращениями библиотек.
К>Примеры — лямбда-исчисление, развитое RTTI, мультиметоды несчастные...

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

И потом, а кто мешает развивать си++? Берешь, дополняешь язык новыми конструкциями, делаешь компилятор и пускаешь его в свободное плавание. Вопрос только в том, приживется ли такой язык или нет. Если кто помнит, параллельно со Страустром было несколько проектов ОО си языка. Но си++ люди приняли, а другие никто и не помнит. Вот реализация языка и есть реальный способ проверить, действительно ли твое понимание "развития" си++ совпадает с реальностью или нет.

Здесь еще вопрос, стоит ли вообще дополнять си++ новыми синтаксическими конструкциями или нет. На самом деле, язык уже очень сложен, и такое добавление его только еще больше усложнит. Может быть поэтому, начиная с определенного момента, перестали пополнять си++ новыми конструкциями и обратились к расширению библиотек?

Вопрос на самом деле стоит так: каждый ли программист (человек) может (должен?) изучить си++ или для кого-то это невозможно ввиду его ограниченых способностей? Мне думается, что не каждый, кто-то все же на бейсике и шарпе програмировать будет. Что мне не понятно, почему этот факт возмущает. Ведь не возмущает никого то, что из большей части человечества математиков хороших не получится? Си++ вероятно продолжает ту старую традицию, умершую в конце 80-х годов, когда программирование считалось областью математики и программист также считался и математиком тоже. Сейчас этого нет, но вот в си++ осталось. И многих этот факт возмущает. Т.е. вопрос: почему ты такой умный, слава Создателю, актуален до сих пор.

Здравствуйте, Геннадий Васильев, Вы писали:

[]

ГВ>Ну я, разумеется, бардак почуял, ковырять пальцем в носе не стал, да и накатал свой. Так... по-быстрому. С внутренними издержками ~3 микросекунды (опять-таки, важно соотношение — ~1:6 по отношению к log4cpp). Функциональность — та же. Т.е. — конфигурирование и т.п. На C++, разумеется. Само собой — свои схемы управления памятью и параметризацией логгирования. Кстати — и то и то с привлечением темплейтов и у-у-ужасного пугала — множественного наследования. Ну ещё немного здоровой програмистской наглости и игнорирования авторитетов ОО (впрочем, это у меня уже давно "на автомате"). Потратил я на это, чтобы тебе не соврать, примерно 2 дня, работая "с пятого на десятое", т.е., не особо вдаваясь в детали оптимизации и высокого штиля софтостроения. Но не скажу, что решено всё было тривиально — уж извините, мы не из этой группы детского сада.

А поглядеть можно?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Если ты сделал что-то быстро, но плохо, то люди быстро забудут о том, что ты сделал это быстро, но будут помнить о том, что это было плохо. А если сделал хорошо, но медленно — люди тоже забудут о том, что ты сделал медлено, но будут помнить о том, что это было — хорошо. (c) пословица.

(c) Королев С.П.
http://www.rtc.ru/encyk/bibl/golovanov/korolev/52.html

Здравствуйте, Alexey Chen, Вы писали:

AC>Угу, компонентная архитектура маст дай? Что, обычный полиморфизм скончался от старости и теперь в ходу только статический, а прогу мы перекомпиливаем каждый раз полностью и по новой? Таки Альксандреску вбивает читателям именно эту идею. Не надо забывать, что шаблоны (статическая параметризация) это ОДИН из МНОЖЕСТВА вариантов решения задачи, не единственный и не всегда самый лучший.

Да нет там этого ничего блин Не вбивает он там никакие идеи — он просто приводит примеры (одни из множества возможных) того, как могут а не должны или иные задачи.


AC>Нет не смешно, мне грустно, поскольку эту книгу превозносят как символ кул-программинга. О чем собственно и топик.

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

ГВ>>А точнее можно? Ты всех полпулистов не любишь или только С++-ных?
AC>Ну еще проповедников не люблю, эффект очень похожий.


AC>А рамках разных или в рамках команды? Я понимаю что многие верят, что использовать тяжёлый трактор в котором без механика не разберешся, когда нужен именно велосипед, это круто! Только не понимаю почему.

Никто тебя не заставляет использовать буст или стл. Опять же — это одни из многих решений. Не нравятся контейнеры стл — юзай мйц-шные, или свои пиши. Это ж дело вкуса. Однако некоторые вещи оказываются настолько удачными и широко применимыми (стл например) что число людей их пользующих возростает многократно. поэтому у тебя очевидно сложился какой-то стереотип относительно того что тебе чтото навязывают.