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

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

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

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

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

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

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

mgu>>>

mgu>>>if( demands < 3 )
mgu>>>    demands = 1;
mgu>>>else
mgu>>>    demands -= 2;
mgu>>>

mgu>Я просто имел в виду тернарную операцию (входит даже в пещерные стандарты С++).

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

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

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

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

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

mgu>>>

mgu>>>    unsigned int m_current_position = 0;
mgu>>>    bool m_current_tick_processed = false;
mgu>>>

mgu>Виноват, я был слишком высокого мнения о создателях С++11: думал, что раз они содрали инициализацию динамических членов класса, то догадаются их инициализировать по умолчанию. Ан нет.

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

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

my_class::my_class(bla-bla-bla)
  : m_current_position(), m_current_tick_processed(), ...
  {}

Либо при описании поля (что доступно с C++11):

class my_class {
  ...
  unsigned int m_current_position{};
  bool m_current_tick_processed{};
};

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

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

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

Причины, действительно, были. Сначала под захваченным mutex-ом из общего списка таймеров выделяется подсписок таймеров, для которых уже наступило время исполнения. Затем mutex освобождается и у всех таймеров из подсписка вызывается заданный пользователем callback. После чего mutex захватывается вновь для того, чтобы была возможность вернуть периодические таймеры обратно в общий список. Вызов callback-ов нужно делать при освобожденном mutex-е по двум основным причинам:

• эта операция может быть длительной (особенно если таймеров сотни тысяч), в это время нужно позволить параллельно работающим нитям работать с общим списком таймеров (выставлять новые или отменять существующие);
  
• внутри callback-а могут быть свои операции с общим списком таймеров. И такая политика работы позволяет избежать использования recursive_mutex (эффективность работы которого может отличаться от эффективности работы обычного mutex-а).

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

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

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

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

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

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