Торвальдс широко известен своими неадекватными и не в меру мудаковатыми высказываниями.

я его, кстати, практически не читал.
ни в речах, ни в сорсах :-)

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

тон его высказываний конкретно о с++ очень далёк от компетентности и профессионализма.

Там, кстати, как, построение вручную таблиц виртуальных функций не практикуется еще в больших проектах?

практикуется, натурально.  вот в том же линуксе, собственно, всю дорогу.
а что? :)

да так, ничего. там Линус и ООП ругает по ходу дела заодно.

)))

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

* что такое "ООП" вообще никому не известно!

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

да-да :)

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

так вот: хрен бы даже с ним с самим сиплюсплюсом, а вот с сиплюсплюсниками каши не сваришь!

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

Да фсё ж наоборот!
От наследования одни прамблемы, инкапсуляция (как её обычно юзают) - зло, а вот полиморфизьм - это весч! Только если он статический :-р.

да, статический полиморфизм - вещь.

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

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

Пральна. А для всего остального есть питон!

питон тоже надо перевести на с++ темплейты и все остальные языки тоже. то есть все языки должны вычисляться в результате раскрытия темплейтов в С++.

Практикуется.
Вообще виртуальные функции с точки зрения программиста, любящего контролировать каждую инструкцию микрокода - бардак и бедлам, не говоря уже о том, что page faults могут случится в совершенно невинных с точки зрения кода местах.
В действительно больших (50-100 человеко/лет и больше) проектах, тянущихся 5-10 лет, попытка писать весь код в Ace-стиле, согласно последним указаниям С++ комитета, приводит к жуткому и неподдерживаемому коду, хуже которого может быть только проект написанный на Perl людьми, свободно на нем общающимися.

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

А с т.з. программиста, любящего контролировать напряжение на каждой ноге каждого транзистора, "инструкции микрокода" - бардак и бедлам ;-)

Транзисторы - это уже другой факультет. Настоящие программисты железками не занимаются :)

> попытка писать весь код в Ace-стиле, согласно последним указаниям С++ комитета

:-О
это что за указания?!
пруфлинк не подкините?

В смысле ? Пруфлинк на стандарты С++ ?
Ну тут вроде должны быть - http://www.open-std.org/jtc1/sc22/wg21/

А где там про "Ace-стиль"?

Фраза "писать весь код в Ace-стиле, согласно последним указаниям С++ комитета"
подразумевает что "Асе стиль" написания кода, в том числе, включает в себя написание кода использующего последние фичеры языка, стандартизованные (раз последние) - в последних указания (стандартах) комитета.

Пруфлинк на формальное определение Асе-стиля, комитета вообще и С++ комитета в частности, обязательности следования каким либо рекомендациям / указаниям, равно как и документированное доказательство непричастности вышеозначенного комитета к Заговору Сионистских Мудрецов - искать не буду.

Гм. Я считал, что выражение "АСЕ-стиль" означает как раз таки ровно противоположное "коду использующему последние фичеры языка", а именно, эдакий говнокод в стиле жёсткого фреймворка на "Cи-с-классами", с кучей макросов, собственных велосипедов и прочих радостей.
А "код, использующий последние фичеры языка" - это, скорее, asio-стиль ;-). И вот он как раз весьма элегантен и очень просто поддерживается.

С asio отдельно не встречался, если это вариация/часть Буста - то Буст мне не понравился :)
С Асе в производстве встречался - и он мне не понравился :)
Вообще после .Нет (на Java не работал, возможно похоже) для больших проектов трудно найти что-то более подходящее (это не повод для холивара) - можно быстро с группой 3 умных, 10 серых и 5 тупых сделать нечто вполне приличное.
На различных вариациях С++ фреймворков надо больше народа в целом, и больший процент умных.

Мы пишем на этом - http://www.mprest.com/Products_mCore.aspx
Судя по всему какие-то общие идеи (асинхронность, как минимум) с asio перекликаются.

> (это не повод для холивара)

отчего же :-р

> можно быстро с группой 3 умных, 10 серых и 5 тупых сделать нечто вполне приличное

В общем, да. Только эти трое умных от дотнета за полгода изрядно отупеют :))). Придётся каждые полгода брать новых!

не, ну наверное можно и на дотнете что-то очень нетривиальное залудить.

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

Народ тупеть не будет в предметной области. Т.е. если человек - спец в какой-нить там комп.лингвистике или в вижене, то ясень пень, его специализация ни от какого дотнета не пострадает. Но есть ведь ещё такой зверь как программер an sich. И с ним от дотнета обязательно произойдёт что-то нехорошое.


> Но это не означает, что на Java или C# нельзя залудить очень серьезный проект

Джаву вообще вынесем за скобки, это на редкость мудацкая хрень.
А что касается C# мы его любим явно не за сборщик мусора и множественное наследование интерфейсов )). А за лямбду, за генераторы, за linq, наконец. Т.е. за... костыли - в твоём определении :-р.

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

Т.е. конечно от борьбы с ветрянными мельницами в С++ можно тоже неплохо прокачать интеллект, но весь этот онанизм с ловлей очередного memory-corruption, потерянной или преждевременно освобожденной памятью и изысками темплейтного недо-метапрограммирования изрядно задолбал.

> но весь этот онанизм с ловлей очередного memory-corruption, потерянной или преждевременно освобожденной памятью

Мля, ты уже 125-й раз упоминаешь memory management. Да нету в 2011 г. в c++ ручного управления меморями!! А если кто-то кое-где у нас порой таким занимается, то вывести его в чисто поле, поставить лицом к стенке и пустить пулю в лоб!

> и изысками темплейтного недо-метапрограммирования

А вот это очень даже приятственный онанизм. Главное совмещать его со свежим воздухом :-р.

* Да нету в 2011 г. в c++ ручного управления меморями

я долго долго смеялся.

Ну и здря.

точно так же ты мог 20 лет назад написать смартпоинтеры, кто мешал? при чем тут С++ 2011?

Я не говорил ничего про c++ 2011!
Я говорил о подходах, которые применяются сейчас чаще, чем раньше. Ну, типа, люди немного научились писать на этом мостре, knowledge-base поднакопился, компиляторы стали нормальные, и т.д..

* Я не говорил ничего про c++ 2011!

А это? " нету в 2011 г. в c++ ручного управления меморями"

)))

* люди немного научились писать на этом мостре

ага. В первую очередь Страуструп научился, судя по эволюции тех книг, что он издавал.

> А это? " нету в 2011 г. в c++ ручного управления меморями"

Читат умеэш, да? В 2011 г., а не в c++11.

> В первую очередь Страуструп научился, судя по эволюции тех книг, что он издавал.

а он ещё и книги издавал?
во гад, нажывался на простом трудовом народе!!

ты понимешь, что смарт-поинтеры можно уже в 96-м писать и не чесаться? Что в 98-м уже все практически программисты Вындоуз знали AddRef-Release решение в DCOM? то ж мне америку открыл.

А ты понимаешь, что одно дело "могли писать", а другое - распространение идей в массах? В 96-м это, может быть, делали александрески и саттеры, а сегодня написана туева хуча книг и статеек, которые не читал только совсем ленивый ламер. Массовая психология, знаешь ли.
Я уж не говорю о том, что в 9х-м, конечно, каждый мог изобрести свой shared_ptr, weak_ptr, bind и т.п., но сегодня они УЖЕ ЕСТЬ out of the box.

ну объясни мне, как мне заиметь конструкт вроде new, возвращающий шаред поинтер, что-то вроде

shared_ptr< IBase > ptr= shared_new CDerived(arg1, arg2);

не понял, зачем тебе именно "конструкт вроде new"?
Вот так пойдёт?
shared_ptr< IBase > ptr(new CDerived(arg1, arg2));
Или, если ты беспокоишься о фрагметации хипа, то:
shared_ptr< IBase > ptr = make_shared< CDerived > (arg1, arg2);

Или ты хочешь "идеальный форвардинг" арг1, арг2?
Поясни, в чём, такскать, поинт.

как зачем?

Теоретически, чтобы в С++ не было поинтеров в юзер-коде )))

Практически, чтоб в аргументы функции передавать, которая ожидает смарт-поинтера.

Скажем

f( shared_new CDerived(arg1, arg2) ) - я согласен видеть, а

f( shared_ptr< IBase >(new CDerived(arg1, arg2) ) уже не согласен по целому ряду обстоятельств.

> shared_ptr< IBase > ptr = make_shared< CDerived > (arg1, arg2);

Ух-ты! Это то что надо. Теперь расскажи мне, как я мог бы подобное написать скажем, в 2009-м году, не говоря уже о 1999-м. Внимательно тебя слушаю.

* Или ты хочешь "идеальный форвардинг"

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

> f( shared_ptr< IBase >(new CDerived(arg1, arg2) ) уже не согласен по целому ряду обстоятельств

Я тут вижу только одно обстоятельство: в более общем виде (если, например, таких аргумента 2) это будет не exception-safe. Но кто тебе мешает присвоить это сперва временному shared_ptr, я так и не понял. Именно так это обычно приличные люди и делают :).


> Теперь расскажи мне, как я мог бы подобное написать скажем, в 2009-м году, не говоря уже о 1999-м.

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

* Я тут вижу только одно обстоятельство: в более общем виде (если, например, таких аргумента 2) это будет не exception-safe.

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

* Это же твои слова были, что мол уже 96-м можно было писать всё что хош.

Так я ж и говорю, что куча моих проектов в 99-м - 2001-м пролетели именно потому, что всё, что многое из того, что можно было С ВИДУ написать в С++, реально было не юзабильно.

Т.е. дело совсем не в том, что появились библиотечные стандартные смартпоинтеры, а в том, что и с ними всё было практически грустно вплоть до последнего времени. Ну а теперь со всяким вашим идеальным форвардингом, r-value reference, l-value reference, referenct им. левой пятки и прочим всё будет совсем монструозным, стоит чуть-чуть отойти от юзеровского кода. И сам понимаешь, каждый нормальный юзер захочет написать всё же что-то своё в подобном стиле, т.е. вся эта монструозная многословная хрень потечет в проекты как по трубам.

> Так я ж и говорю, что куча моих проектов в 99-м - 2001-м пролетели именно потому, что всё, что многое из того, что можно было С ВИДУ написать в С++, реально было не юзабильно.

Ну слихуйте. Вообще-то эта ветка была про memory-management, а не про решение задачи форвардинга. То, что в до C++0x-ные времена решения у этой задачи в общем случае не было, никак не пасулит raii вообще и shared_ptr в частности.
Мой же поинт заключался всего лишь в том, что раньше эти подходы юзали только спецы вроде тебя, а сейчас их юзает каждый лох (типа меня). Распространилось, такскать, высокое знание в народе.

Ну ты меня похож обогнал в знании плюсов, не прибедняйся уж.

И не юзал я эти подходы ни разу, почему - долгая история, но, возможно, это было ошибкой. При том, что сейчас всё это юзаю и не особо в восторге, кстати.

* Но кто тебе мешает присвоить это сперва временному shared_ptr, я так и не понял.

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

* Именно так это обычно приличные люди и делают :)

"приличный человек", синоним "терпила"

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

эхх
мля...
либо у тебя проблемы с пониманием прочитанного, либо у меня с написанием написанного :))

да всё нормально, я так, гоню слегка.

в целом, nice talk, хорошо пообщались, как в добрые старые времена )))

ага, только плова "самаркандского" не хватало ))

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

Мне б её лет так 10 назад - это было бы очень круто. Но, возможно, и сегодня она где-то потянет.

Если хочешь, готов приватно поделиться )))

Давай, делись скрытым комментом )).
А скока бабла я на этой идейке смогу срубить? :-Р

я лучше в чате, или по скайпу или письмом.

увы, за такие мелочи денег не платят.

Я, кстати, еще один момент припомнил.

Допустим, есть у тебя вся из себя навороченная с++ программа с шаред-поинтерами. Только вот беда, у объектов в С++ бывают члены - тоже объекты. Как такой объект передать куда-то? По указателю или ссылке - нельзя, ведь кто-то эту ссылку может запомнить, а объект потом пропадёт. Шаред-поинтер, опять же, вроде бы такие изыски не поддерживает.

Опять же, представь себе, что ты создаешь объект на стеке. И хочешь передать его в функцию. А функция, вот беда, написана в лучших традициях и принимает только шаред-поинтеры, или референсы на константные шаред поинтеры, но никак не простой референс или указатель.

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

> я лучше в чате, или по скайпу или письмом

ok :)

>Только вот беда, у объектов в С++ бывают члены - тоже объекты. Как такой объект передать куда-то? По указателю или ссылке - нельзя, ведь кто-то эту ссылку может запомнить, а объект потом пропадёт. Шаред-поинтер, опять же, вроде бы такие изыски не поддерживает.


Гм. Вот так пойдёт?

#include < boost/shared_ptr.hpp >

struct inner
{
int i_;
};

struct outer
{
int o_;
inner i_;
};


int main()
{
using boost::shared_ptr;
shared_ptr< outer > o(new outer());
shared_ptr< inner > i(o, &o->i_);
// i and o manage the *same* object!
}


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

Несогласный я. Принятие функцией (константной) ссылки на объект - это один дизайновый "мессежд", а принятие шаред птра - другой мессежд. Если ф-ция принимает шаред птр, она говорит: "что я с ним буду делать - не твоё дело, на то он и *шаред*". Если же ф-ция, выходя, заканчивает работу с объектом, то никакого "дизайнового" смысла в принятии шареда нет, и это просто лишнее ограничение - сиречь проёб.

* Гм. Вот так пойдёт?

Ну так, знаешь, кривовато выглядит. Но лучше чем ничего. Сойдет. Хотя, кривовато.

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

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

По-моему, помнить о том, какая функция заканчивает работу с объектом, а какая нет, и давать им в зависимости от этого разные прототипы - довольно утомительно. Это, кстати, еще одна особенность работы с памятью в С++ без garbage collector.

И заметь, ты сам признался, что в твоём дизайне raw-поинтеры будут использоваться в 80-90% случаев.

Как-то всё это стрёмно выходит.

> По-моему, помнить о том, какая функция заканчивает работу с объектом, а какая нет, и давать им в зависимости от этого разные прототипы - довольно утомительно. Это, кстати, еще одна особенность работы с памятью в С++ без garbage collector.

Я что-то потерял нить. А как в языке с GC ты собрался передавать в функции "объекты на стеке"??
Как ты понимаешь, чисто технически нет никакой проблемы передать в f(const shared_ptr< void > &) объект, созданный на стеке. Проблема здесь именно дизайнового плана.


> ты сам признался, что в твоём дизайне raw-поинтеры будут использоваться в 80-90% случаев

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

* А как в языке с GC ты собрался передавать в функции "объекты на стеке"??

А в чем проблема? GC прекрасно может разобраться, что объект сидит на стеке, а не в хипе, и освобождать его не актуально.

* Как ты понимаешь, чисто технически нет никакой проблемы передать в f(const shared_ptr< void > &) объект, созданный на стеке.

Не-а. Не понимаю.

* Я говорил, что можно "окказионально" передавать raw-поинтеры в те места, где они заведово используются синхронно

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

>> * Как ты понимаешь, чисто технически нет никакой проблемы передать в f(const shared_ptr< void > &) объект, созданный на стеке.
> Не-а. Не понимаю.

yourFunction(shared_ptr(&stackObj, null_deleter));

чудесно. спасибо за ликвидацию безграмотности!

стёб detected

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

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

Кстати, это уже давно tr1 и даже некоторое время std (msvc10) :).

Всё это хорошо, конечно.

Вот только одно "Но". Как минимум одно. Есть куча ситуаций, когда надо детерминированно закрывать ресурс. Вся эта игра в garbage collection построена на том, что мы притворяемся, что у нас есть неограниченная память, и нам всё равно, когда реально кто-то там подчистит то, что не использовуется больше. Шаред-поинтеры - ущербная имплементация того ж garbage-collector.


Однако, в ситуациях, когда деструктор объекта выполняет нетривиальную работу, или когда эта работа тривиальна, но есть другая "закрывающая функция", скажем, как "close" в файлах, которая делает нетривиальную работу и должна быть вызвана "во время", все эти концепции смарт-поинтеров пролетают. Т.е. мы почти избавились от memory-corruptions и "как бы" почти избавились от memory-leaks, но всё равно где-то как-то нам придется следить за тем, кто кем владеет и кто в каком порядке что освобождает. И снова возникает явное управление ресурсами, если не их "освобождением", то их "закрытием".

Вот такая фигня.

Таки ровно наоборот, имхо: шаред-поинтеры - это не "ущербная имплементация того ж garbage-collector", а схема, при которой у тебя, с одной стороны, есть возможность автоматического управления временем жизни, а с другой стороны, - это время жизни остаётся абсолютно детерминированным. Т.е. решаешь - на этапе дизайна - сколько кому жить.
Да, конечно, проёб в дизайне приведёт к (псевдо)утечке, но:
1) с GC он приведёт к тому же гораздо быстрее, потому что там надо вручную вообще всё финализировать (не считая левых примочек типа дотнетовского using).
2) без GC и без шаред-поинтеров такие проёбы обычно приводят к крэшу, и чинить его гораздо сложнее, чем псевдоутечку.

Т.о., шаред-поинтеры - оптимальный вариант.
А такой схемы, чтоб программа сама писалась всё само как надо закрывалось и не корруптилось, кажется, ещё не придумали ;-).

т.е. по сути, та же проблема возникает снова, на этот раз она чревата не memory corruption and leaks, а использованием закрытых ресурсов и незакрытыми вовремя ресурсами.

"Те же яйца, вид сбоку".

Хотя, конечно, в целом приятнее дело иметь со вторым, а не с первым.

мда... а ведь и вправду мог бы быть стёб. Оказывается, как мне объяснили опытные люди, это решение сосёт.

Подробности в приват.

А чего в приват? Коммерческая тайна? :)

причины привата - снова в приват )))

Ну давай, пиши в приват :)

* А вот это очень даже приятственный онанизм.

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

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

Мда... МК52 плохо темплейты компилировал :)).

я пока-что ничего не говорил про компиляторы. только про С++ сам по себе.

Aa, "из-за кривого дизайна С++" - это вообще до стандарта 98-го года?
Меня тогда ещё не было :)).

98-го, 2003-го, 2009-го.

А, ну тогда не знаю... В бусте всё работает.

Работает то, что СМОГЛИ написать, продравшись через тонны проблем.

а что ты имеешь в виду под изпользованием последних фичеров C++ в asio?

В плане интерфейса - мувабельные и/о объекты, мувабельные хэндлеры, "вариадики". В плане имплементации - всё, что только можно :).
Ну и вообще, асио само по себе - "последний фичер c++", потому что он в tr2 и, по мнению страуса, в следующем стандарте будет в std.
Но я имел в виду даже не только это, а то, что аффтар называет "a modern C++ approach", т.е. хорошая интероперабильность с STL-ем и вообще с std, отсутствие всяких "наследий тяжёлых времён" в дизайне, типа глубоких иерархий наследования, продвижение полезных идиом типа shared_from_this, "фукционального" подхода и т.д., и т.п..

о, как я отстал от культуры и балета!

чем же полезно shared_from_this? Очередной же мудацкий костыль.

Ладно, спасибо за ответ, надо будет всё это почитать.

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

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

> чем же полезно shared_from_this?

Дык это просто применение старого-доброго raii на благо асинхронных систем. Типа, биндишь хэндлер асинхронной подсистемы не куда попало, а на shared_from_this, и потом оно всё само когда надо умирает и отваливается.
Или даже такая разновидность: биндишь на нормальный поинтер, а weak_ptr передаёшь в качестве трэкера.
Оченно это всё помогает управлять временем жыздни.


> Очередной же мудацкий костыль

Смотри, с тем же успехом "мудацким костылём" можно обозвать и всякие псевдофункциональные примочки типа лямбды или даже тривиального бинда и трэйты, не говоря уж об TMP в целом. А кто-то называет это "множественностью парадигм" :)).


> По секрету, я очень плохо знаю буст

Да там и знать нечего, нет такой библиотеки :)). Буст - это просто брэнд. Означает, что либу не на помойке нашли, а грамотные люди сваяли и проверили.
А всё "ядро" буста уже в любом случае в std или на крайняк в tr1.

> а меня, помнится, еще в 98-м году уволили из одной хай-тек фирмы

Той фирмы уже сто лет как нет. И, видимо, неспроста! :-Р

* Той фирмы уже сто лет как нет. И, видимо, неспроста! :-Р

Удивишься, но есть и вполне себе процветает.

Ск-к? Фигасе, мне казалось, он давно издохъ.

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

"Linus T" - это псевдоним юзера yosefk :))

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

Современный язык, решающий проблемы C и не страдающий дефектами C++ --- Go (http://golang.org).

я не уверен, что проблема именно в этом и только в этом. Компиляторы в теории можно написать, STL доработать (это естественно, что универсальные имплементации контейнеров будут работать медленнее, чем заточенные под конкретные ограничения задач. В какой-то старой и на момент выхода достаточно нетривиальной книжке "Scientific and Engineering C++" John J. Barton, Lee R. Nackman вроде бы как раз были продемонстрированы какие-то результаты по контейнеров, допускающих fine-tuning, но вроде в промышленные библиотеки те идеи не ушли.


Сам по себе язык неудобен и сложен (я говорю не о сложности понимания и изучения новичком, как раз новичок резво кидается в написание очередных С++ трюков и в восторге от всяких сложностей), а о практическом применении. Т.е., даже отбросив всвозможные книжки Mayers об Effective and More effective C++, до 90% содержания которых приличный программист должен додуматься сам, остаётся куча нетривиальных вещей, описываемых, к примеру, в серии книг Саттера "Exceptional C++". Это долгая история, я могу приводит примеры, но в кратце, я считаю, что язык, требующий для нормальной работы на нём экспертных знаний, знания уймы тонкостей и чтения уймы нетривиальных книг - достаточно неудачен.

Указанный дефект (чрезмерная сложность и запутанность),
тоже, несомненно, имеет место.

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

(И опять же, синтаксис Go существенно улучшен по сравнению
с C, тем более с C++.)

Я участвовал в проектах на пару миллионов строк С++ и мне очень тяжело представить, как это всё можно было бы писать на С (речь не об использовании С++ для GUI, а именно о написании на нём "потрохов" системы). То есть, безусловно, можно и на С, как можно было бы и на ассемблере.

Опять же, по МОЕМУ опыту, программисты не знающие ОО, но знающие С, пишут в целом очень плохой код. Даже когда этот код именно на С. Постоянные ничем не обоснованные type-casts, например. Летающие во все стороны void указатели. Готовность выдать спагетти-код любого уровня запутанности, лишь бы работало. Не владение базисными архитектурными идеями, вроде использования плаг-ин архитектур, а не жесткой привязки фичеров к главному коду. Итд итп.

Но безусловно, С++ имеет кучу недостатков, в том числе препятствующих его спокойному и эффективному использованию в low-level.

>Я участвовал в проектах на пару миллионов строк С++ и мне очень тяжело представить, как это всё можно было бы писать на С

Возможно, именно это имеет ввиду Torvalds?

А вообще говоря, способ избежать подобных проблем
(которые ООП не решает, кстати) известен давно:
Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Типичный пример программы, грубо нарушающей эту философию --- любой современный распространённый браузер
(FIrefox, Chrome, Opera, IE).
Неудивительно, что все они чудовищно глючат и постоянно крэшатся.

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

* Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

странный подход. Ну, напишите в таком духе графический интерактивный редактор, или практичную базу данных, или дебаггер.

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

В больших реальных, а не игрушечных демонстрационных проектах, есть уйма разных бизнес-требований довольно замысловатым образом взаимодействующих, а то и противоречащих друг другу. Разделить подобные требования, абстрагировать их , избавиться от их взаимодействия и противодействия порой не проще, чем отделить в человеке нервную систему от кровеносной, а мышцы от костей. Это еще вообще до ВСЯКОГО программирования. Те или иные технические решения имеют свои ограничения, и опять же в силу этих ограничений достаточно замысловатым образом взаимодействуют с бизнес-требованиями. Это опять же еще практически до всякого реального программирования, только на уровне результатов ресёча и отладки технических решений. Разговоры о разделении программ - фикция. Это нужно уметь делать, но далеко не всегда это сделать возможно.

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

Гм, вообще-то я просто процитировал Unix philosophy (https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy).

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

Не вижу препятствий.
В своё время весь Unix был так сделан, а затем и Plan 9.

Абзац про «бизнес-требования» довольно невнятный,
а конкретные примеры существуют?

> Гм, вообще-то я просто процитировал Unix philosophy.

да я знаю. осталось рассмотреть, какая часть ядра сделана по этой философии.

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

> Не вижу препятствий.

Ух-ты! А что, XLib в юниксе тоже построен как обработчк потока символов?

> Абзац про «бизнес-требования» довольно невнятный,
а конкретные примеры существуют?

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

>да я знаю. осталось рассмотреть, какая часть ядра сделана по этой философии.

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

>Ух-ты! А что, XLib в юниксе тоже построен как обработчк потока символов?

А вот X Window как раз писали не в Bell Labs,
и философии Unix он совсем не следует,
поэтому он такой кривой и плохо интегрирован
с остальным Unix.

Для сравнения, в Plan 9 управление графикой
осуществляется в текстовом формате через обычный файл,
поэтому, например, окнами можно управлять из скрипта
(что успешно и делается).

>кажется самим собой разумеющимся

Опять общие слова.
Единственное существенное препятствие
для философии Unix, которое видно сразу
— это производительность.
Учитывая, как глубоко нынешним программистам
наплевать на производительность
(что легко видеть на примере тех же браузеров),
этот аргумент не является очень сильным.

* Ведь загружаемые модули — это те же программы,
только память у них общая.

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

>кажется самим собой разумеющимся

* Опять общие слова.

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

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

Я уже объяснил в предыдущем комментарии,
что как раз по причине эффективности Linux не является микроядром
и взаимодействие осуществляется путём разделения памяти.

Впрочем, большое количество драйверов управляется
именно таким образом — через файловые системы
/proc и /sys.

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


Представил, как драйвер винта обменивается с контроллером xml-ями. :-Р

Те или иные технические решения имеют свои ограничения, и опять же в силу этих ограничений достаточно замысловатым образом взаимодействуют с бизнес-требованиями И ДРУГ С ДРУГОМ )))