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

mgu>>Ну не знаю я С++11, это и есть "замечательная невежественность"?

S>В контексте разговора про опыт "C++11; MSVS-2013; Qt5-древний опыт" -- да.

В таком случае признаю свою замшелось и ретроградство.

S>>>Ваше мнение по поводу стандарта C++ и уровня его поддержки в современных компиляторах очень ценно.

mgu>>Таки полностью не поддерживается:
mgu>>https://msdn.microsoft.com/ru-ru/library/hh567368.aspx

S>Какие-то у вас ограниченные источники информации. В современных реалиях для C++ника гораздо важнее черпать информацию из других мест.

Спасибо за полезную ссылку, но вот что меня беспокоит: при вашей политике распространения библиотеки в виде исходного кода, как бедные пользователи будут угадывать правильный компилятор? И что им делать, если их текущий сборщик не переварит всех нововведений?

S>А то получится как с AlexGin, который никак не может осознать, что сейчас разработка на Visual C++ для Windows -- это довольно узкая ниша. А соответствующий опыт можно считать довольно древним.

Да, узкая.

S>Уверяю вас, если бы было записано однострочником:
S>

S>demands = demands < 3 ? 1 : (demands-2);
S>

S>то нашлись бы ярые противники использования тернарных операторов. Книга одного из них, с большим опытом разгребания Windows-only говнокода, обсуждается сейчас в профильном форуме. Там как раз совет №4 звучит как "Бойтесь оператора ?: и заключайте его в круглые скобки".

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

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

( http://rsdn.ru/forum/cpp/6419326 )

S>Так что вы придрались к синтаксису.

Да нет, к подходу -- налицо излишняя многословность. Против инкрементов у вас же возражений нет?

S>К коду AlexGin сходу можно предъявлять претензии гораздо более серьезные.

Например?

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

S>Во-первых, фраза "динамические члены класса" применительно к C++ режет слух. Что еще больше утверждает в мысли, что вы пытаетесь судить о том, в чем не разбираетесь.

Ваш термин для не статических членов класса в С++?

S>Во-вторых, в C++ в угоду скорости исполнения поля объектов не инициализируются, если это не указано явно разработчиком. Посему даже инициализация поля дефолтным значением должна происходить явно. Либо в конструкторе (что работает, емнип, со времен C++98/03)

Всё верно, вот только цель сомнительна, особенно для примитивных полей.

S>Т.е. вы не разобрались с тем, что делает код и почему он это делает именно так, но претензии предъявили?

Да. Кто виноват в проблеме -- тупой пользователь или напускающий туман и опускающий комментарии разработчик?

S>Причины, действительно, были.
S>...
S>эта операция может быть длительной (особенно если таймеров сотни тысяч), в это время нужно позволить параллельно работающим нитям работать с общим списком таймеров (выставлять новые или отменять существующие);

То есть в то время как всё прогрессивное человечество пишет синглтоны с двумя if-ами, вы позволяете внешним акторам хулиганить? Всё-таки привычнее видеть операции должным образом изолированными.

mgu>>А std::abort() выкидывает без всяких очисток, это потенциальная мина, возможно, понадобится закрывать ресурсы или выбрасывать новое исключение в глобальный обработчик, а перед этим восстанавливать загадочный lock(). В общем, надо что-то делать либо с финализацией, либо при ошибке выставлять локальный флаг и выходить из while.

S>А известно ли вам, что в C++ не принято выбрасывать исключения из деструкторов?

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

S>Поскольку если такое исключение выскочит при раскрутке стека из-за ранее возникшего исключения, то сам ран-тайм тупо завет std::terminate (суть std::abort()). И это считается нормально: пользователь нарушил контракт, получил по рукам, ибо обеспечить восстановление после такого нарушения контракта возможно далеко не всегда. Так же и здесь -- нельзя выпускать исключения из callback-а. Поскольку некому его будет обрабатывать на отдельной рабочей нити, на которой и происходят вызовы callback-ов.

Не выпускайте, ещё раз: выставляйте локальный флаг и выходите из while.

S>>>Кроме того, вы наверняка не видели sqlite.c и не слышали про такую технику, как amalgamation.

mgu>>Не слышал, ознакомился, понял, что иногда сталкивался с подобной необходимостью, но термина не знаю. Зато с многотысячестрочными простынями (точнее, сари) имел дело. Предпочитаю вместо иллюзорного выигрыша в производительности делать разбиение на логические единицы.

S>Ну посмотрите на размеры заголовочных файлов random, regex, algorithm, vector из состава Visual C++ к примеру. Или на basic_string.h из libstdc++. Что предложите с ними сделать?

Взять всё и поделить! (с) Шариков.

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

S>Конкретно в моем случае определение всего в одном файле связано совсем не с вопросами производительности, а с удобством распространения библиотеки. Это header-only библиотека (не знаю, понимаете ли вы, что это такое). Посему отдать один заголовочный файл и подключить один-единственный заголовочный файл в другом месте гораздо проще.

А чем dll вам не угодили? Для любителей hardcore можно предоставлять версии с отладочной информацией. Или фишка в компилировании под конкретные платформы?

S>Кросс-платформенных и широкораспространненых менеджеров пакетов в C++ пока не завезли. Это тоже к вопросу опыта и его релевантности современным реалиям ИТ-шного рынка.

Не смог согласовать первое предложение со вторым.