Что у тебя будет деструктор, что финализатор. Какая разница?

Вообще-то большая. Деструктор связан с конкретным объектом, а финализатор болтается в вакууме. Соответственно RAII можно легко использовать в иерархиях объектов, не боясь, что что-то где-то потеряется.

Ну так если объект живёт только в этой области. Как иначе надо-то?

Он живет не только в этой области. Он может жить в if'е, в while'е или в любом другом блоке, который я руками укажу.

Вот так например:

    // send data to the worker thread
    {
        std::lock_guard<std::mutex> lk(m);
        ready = true;
        std::cout << "main() signals data ready for processing\n";
    }
    cv.notify_one();
 
    // wait for the worker
    {
        std::unique_lock<std::mutex> lk(m);
        cv.wait(lk, []{return processed;});
    }
    std::cout << "Back in main(), data = " << data << '\n';
 
    worker.join();

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

http://en.cppreference.com/w/cpp/thread/condition_variable

Ну да, ты прав.

т.е. .. читать не удобно, а .. удобно или что имелось в виду?

Да. Вот более близкий к реальности пример

 a = some_long_name
       || other_very_long_predicate_name
           && extra_condition
           && one_more_condition
       || short_func
           ...
       || final_case;

и

 a = some_long_name ||
       other_very_long_predicate_name &&
           extra_condition &&
           one_more_condition ||
       short_func ||
             ...
       final_case

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

Аккуратно написанный код и G1 с правильными настройками дают хорошие показатели.

да-да, вот такие

We would like to recommend G1GC someday, but for now, it is simply not stable enough to meet the demands [..]

PS не Java-хейтер, просто всплыло в памяти

Ну мало ли что у тебя в памяти всплывает. Сегодня G1 вполне стабилен и рекомендуем.

И на вопрос ответил, и статеек интересных дал, и лисп похвалил :)

Спасибо. Есть пища для размышления.

не у меня, а у Elasticsearch

вы комплексуете что-ли?

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

не так страшен чёрт

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

Всё это работает только для сферического проекта в вакууме. То есть до первого использования сторонней библиотеки. Другому коллективу (который пишет ту самую библиотеку) свои «правила игры» навязать не получится. Или в мире эльфов все библиотеки идеальны?

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

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

Написал жизнь на sdl

Как это потыкать/собрать?

Это понятно. Ну вот представь, пишите вы проект. Понадобилось - подключили библиотеку, сделали для неё обертки и разделительные интерфейсы. А потом, через год в ней обнаружился баг. Авторы навстречу не идут, а внутри шаблонная магия, ад угар и содомия. Чем в этом случае помогут «собственные правила»? Или понадобился от этой библиотеки новый функционал, а там - смотри выше.

Go очень простой язык. Использовал я в проекте библиотеку, мне понадобился от неё новый функционал - я запилил и сделал пуллреквест. Конец истории.

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

Чем бы ни маялись, лишь бы на Ди не писать!

...а что касается смерти си, то этот мастодонт пережил...

В отношении Си должна быть более точная терминология. Он не «пережил», потому что фактически не живёт, а выживает.
Современное состояние Си можно сравнить с дёгтем на асфальте, который НИКАК не удаётся удалить. А чтобы дорога выглядела равномерно, нужно либо этот дёготь убрать, либо... правильно - «домулевать» остальное тоже дёгтем! ВОТ ПОЭТОМУ этот высокоуровневый ассемблер до сих пор жив - из-за кучи идиотов, которые вместо выпила асфальта, пытаются «домулёвывать».
Ну и что, что math.lib написана на Си?! Включи её в проект, но сам-то проект зачем на Си писать? Есть Go, Rust, D, C# (теперь уже компилябельный), много чего! Но нет, мы будем жрать кактус, вытирать слёзы и рассказывать про «ещё живой» Си! Гениально.

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

Но нет, мы будем жрать кактус, вытирать слёзы и рассказывать про «ещё живой» Си! Гениально.

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

Если изначально заточен на долголетие - выбора особо нет.

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

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

Почему я должен захотеть копаться в её потрохах?

То есть лучшая политика - спрятать голову в песок? Обложить баг костылями?

Hint: не все и не всегда оперативно правят баги из своего багтрекера.

Вы противоречите сами себе, я так и не понял, мы math.lib выпиливаем или как? Кто от кого зависит?

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

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

Ну по этому параметру плюсы далеко не на первом месте.

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

Нет, это не английский текст, тебя обманули. Английский текст выглядит совсем иначе. Это — пример кода на языке Ruby, и без знания Ruby это понять невозможно.

Пока в го такие «прорывы» каждый релиз, очевидно, что его сборщику ещё развиваться и развиваться до взрослых устоявшихся реализаций.

Ну мне не очевидно. Наличие прорывов не (обязательно) значит, что всё плохо.

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

и обычно только положительные отзывы.

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

А кто по-твоему на первом (только не из маргинальных языков вроде CL)?

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

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

А кто по-твоему на первом (только не из маргинальных языков вроде CL)?

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

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

Ну и пишу я на С++, если что.

а всякие Rust-ы лишь завидуют

Учитывая, что в сообщении на которое ты отвечал о расте ни слова, то похоже что завидует кто-то другой. Хотя чему?

И хорошо, когда это видно сразу.

this. Далеко не всегда это так.

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

Здесь спорить не буду.

Почему-то вспоминается комикс.

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

Использовал я в проекте библиотеку, мне понадобился от неё новый функционал...

...а внутри сишные биндинги.

Было и такое. Сишные биндинги и внезапные паники. Оказалось проще переписать без сишных биндингов.

На языке вертится просто, устал, что о нём пишут зачем-то в каждом топике про Го

Возможно, главное не зацикливаться на Go, и смотреть по сторонам.

а комикс хороший

Возможно, главное не зацикливаться на Go, и смотреть по сторонам.

У каждого инструмента есть своя ниша. Я не буду писать ядро ОС на go - для этого есть более подходящие инструменты.

да

всёж отличай «Карузо напел» и то же оригинальное сообщение об Алголе60

С++ это алгол68 который взлетел :(

С++ это алгол68

Тебе уже говорили, что ты упорот?

У каждого инструмента есть своя ниша.

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

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

Забыл вбросить

Go не нужен из-за убогих коллекций.

Жиденько. Чем именно коллекции в go убоги?

Нет кортежей, нет простых списков, нет множеств.

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

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

Да

Ну вы и балбесы....

дык жизнь это прекрасно.

у Gо действительно выдающийся сборщик мусора

а как же не выдающийся? 10мс vs 300мс. на 30% в 30 раз быстрее. и так же в каждом новом релизе.

Ну многое упирается в отсутствие дженериков. Но кое-что накостылили.