Всё таки не просто ссылается как на левый документ. Многое оттуда берётся и в самом C++ уже не описывается.
C++ is a general purpose programming language based on the C programming language as specified in
ISO/IEC 9899:1999 (hereinafter referred to as the C standard). In addition to
the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces,
operator overloading, function name overloading, references, free store management operators, and additional
library facilities.
Да и Майкрософт, например, всегда говорит о поддержке C99, как это требуется (они заявляют, что реализовали C99 на 99.9% кроме tgmath.h, так как это к чистому C относится, для C++ есть ctgmath, который у них реализован).
Да и вообще, тот же restrict по этим причинам в C++11 не описан, но ровно один раз упомянут:
17.2 The C standard library [library.c]
1 The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to
ensure static type safety.
2 The descriptions of many library functions rely on the C standard library for the signatures and semantics
of those functions. In all such cases, any use of the restrict qualifier shall be omitted.
Эх, автор ещё явно такого не видел:
//Допустим, есть строка «abcd»,
//Как получить значение третьего элемента?
//Можно, например, так:
char c = «abcd»[3];
//а можно еще и так:)
c = 3[«abcd»];
С этим никто и не спорит. Поэтому я и говорю, что эти новые направления C# и линукс отвлекли разработку от C++. А если ещё Java, Brainfuck, и т.д. будут, то ещё больше времени от плюсов будет отниматься. Вот про что я говорил, когда вы со мной не согласились.
Главное, чтобы как Интел не сделали, чтобы анкету надо было заполнять только чтобы скачать триалку новой версии.
Или как постоянные посетители бара «Голубая устрица» компания Оракл — чтобы скачать что-то надо сперва зарегистрироваться на сайте, при попытке регистрации должно сперва письмо придти для окончания регистрации, а письмо-то и не приходит…
Линукс так же отвлекал от написания новых правил для C++, и от улучшения (исправления false positives) существующих.
А когда вышел анализатор для C# реально скорость добавления диагностик для C++ снизилась в разы. Это даже по changelog'у видно.
Кстати, за саму статью и за тот огромный труд, что вы проделали, большое вам спасибо!
Мой комментарий не принимайте близко к себе. Просто меня немного задело «ограничение на 1024 символов в строке и на исключение при отсутствие файла с логами». Решил рассказать людям, о его старом дедушке — рабочей лошадке log4cxx, лишённого этих детских болезней.
Задача статьи сравнить логеры с точки зрения их простоты использования. Возможно для Вас это 30 минут работы, для другого инженера не знакомого с логером — это несколько дней плюс тестирование и исправления и все это при наличии желания, особенно если можно взять что-то другое где функция доступна из коробки.
Смысл моего этого замечания на самом деле был в том, что log4cxx (уверен, что это относится и к log4cpp/log4cplusplus) можно быть сильно, и быстро, кастомизировать под свои кейзы в случае необходимости. Конечно, такое требуется обычно раз в жизни, но обычно в тот самый момент, когда времени переходить на новый логгер точно не будет. Я, кстати, слабо представляю зачем тот же DayliRollingAppender вообще нужен, хоть и делал его. Другими словами, кастомизация логгера — это один из кейсов его использования. И если вы хотели «сравнить логеры с точки зрения их простоты использования», простота расширения log4cxx — это вообще в тему.
Я не смог отнести к достоинствам тот факт, что синхронный логер может приостановить выполнение вашей программы на длительное время только потому, что обращается к файлу, а HDD скажем занят. Для домашних проектов это не ограничение, для серьезных проектов — лучше не иметь таких случайных задержек плюс существенное падение производительности в случае интенсивного логирования.
Это большой миф, что синхронное логгирование может что-то там замедлить. Объясню на примере. Мы делаем софт, который сильно грузит cpu и диск. И для нас каждый процент cpu, так же как любая задержка работы с файловой системой, очень важен. Вплоть до того, что пришлось Sleep(0.5) реализовывать, так как 1 миллисекунда для нас — это слишком большая задержка. Соответственно, постоянно профилируемся по нагрузке проца, и часто ищем задержки с помощью gpuview и других тулзовин. Так вот, синхронный логгер не даёт ни сколько нибудь значительную нагрузку на cpu, ни сколько нибудь значительных задержек работы с файловой системой. Насколько я помню, несмотрю на то, что пишет он синхронно в файл, то сам файл по дефолту флашится на диск сразу после записи только при ERROR/FATAL. А так собственно есть буферизация в винде, по умолчанию винда скидывает данные на диск большими блоками (аля секторами), что очень эффективно. В синтетических тестах может и есть какая-то разница с асинхронными логгерами, а вот в реальных приложениях — нету.
Перехват падений в этом случае решает проблему, можно даже стэк распечатать или сохранить краш дамп — самый простой способ найти и исправить дефект в разумные сроки.
Вы зря путаете логгирование и перехват исключений. Одно другое никак не заменяет. А случаев, когда партнёр, находясь в 300 км от ближайшего интернета, по телефону зачитывает логи модуля, который падает, за неимением возможности выслать даже минимальные дампы, в моей практике было не один, не пять, и даже не 10. Кстати, как показала практика — распечатывание стека при падении в самом падающем приложении — тоже не состоятельная идея (применительно к Винде). Там куча проблем, которые надо решать. Например, либо символы в бинари встраивать (C7), увеличивая их размер в разы, а то и в десятки раз, либо всё-таки старая добрая pdb и раскрутка стека на машине разработчика. Или ещё например, что бы записать в файл, когда закончилась память (выжрали 4 гига, и new постоянно кидает bad_alloc), тоже надо постараться, так как даже fopen пытаться выделить некие буффера, и если памяти реально не осталось, то даже это сделать не получится, и том чтобы использовать ofstream разговор вообще уже не идёт (если что я знаю как такую проблему решать, я к тому, что это всё не тривиально).
Утилита стоит денег если используется профессионально.
Вы здесь опять суть не уловили. Дело не в том, что есть бесплатный logmx для некоммерческого использования, а в том, что для log4j/log4net/log4cxx построена огромная инфрастуктура. Тех же анализаторов логов можно за 10 минут наверное с десяток нагуглить, на любой вкус и кошелёк, всё не закачанчивается на logmx'е. Кстати, обычные логи в log4cxx настраиваются так хорошо, что обычно не требуют специализированных средств для своего анализа, обычно это бывает полезно в очень специфичных случаях.
Не знаю как у log4cpp, а вот у его «идейного предка» log4cxx на 30 минут работы написать свои аппендеры, например dailyrolling. Да и ещё через час работы над его словами его можно спокойно заставить миксовать wchar_t* и обычный char* (правда с условием, что первым будет wchar_t логгироваться) в одной строчке. Так же log4cxx не имеет таких минусов log4cpp как ограничение на 1024 символов в строке (хоть мегабайты туда пиши) и на исключение при отсутствие файла с логами (реально такое было лет 9 назад в версии 0.9.х). И ещё плюс — это динамическая конфигурация логгера (не перезапуская программу), он умеет следить за конфигурационный файлом и на лету подхватывать из него новые настройки. Так же странно, что синхронность отнесена к недостаткам. Обычно наоборот в случае падения приложения самые интересные логи они в самом конце. А если они не успеют сброситься на диск, то беда беда.
Так же у обоих большой плюс в том что для этого семейства логгеров (включая log4j и log4net) есть сторонние инструменты для работы с файлами логов, не надо придумывать свои велосипеды (например, logMX).
Пример: обычный человек иногда пьет, иногда срывается, иногда разводится или ходит на лево. А президенту такое делать нельзя, даже мелкого недостатка будет достаточно что-бы не быть на верху.
Да вы прямо бог примеров :). 66.6℅ президентов РФ прямо подтверждают ваши слова.
Крутое достижение — это кол-во 2-х мегапиксельных кадров в секунду, которое он может декомпрессить. И что видеокарты и рядом не валялись по показателям.
Один FullHD поток — да уже лет десять кто только не умеет аппаратно декомпрессить — это не интересно.
Кстати, с кодированием 264 тоже проблем у проца не возникает, что радует.
Зато с декодированием 264 всё просто замечательно. На проце с 1 блоком вроде как почти 68 потоков FullHD с 25 fps тянет. А крайние i7 уже по 2 юнита имеют… Видеокарты отдыхают.
Да и Майкрософт, например, всегда говорит о поддержке C99, как это требуется (они заявляют, что реализовали C99 на 99.9% кроме tgmath.h, так как это к чистому C относится, для C++ есть ctgmath, который у них реализован).
Да и вообще, тот же restrict по этим причинам в C++11 не описан, но ровно один раз упомянут:
И назвать его cv::Mat…
//Допустим, есть строка «abcd»,
//Как получить значение третьего элемента?
//Можно, например, так:
char c = «abcd»[3];
//а можно еще и так:)
c = 3[«abcd»];
EmDrive?
Или как постоянные посетители бара «Голубая устрица» компания Оракл — чтобы скачать что-то надо сперва зарегистрироваться на сайте, при попытке регистрации должно сперва письмо придти для окончания регистрации, а письмо-то и не приходит…
А когда вышел анализатор для C# реально скорость добавления диагностик для C++ снизилась в разы. Это даже по changelog'у видно.
Мой комментарий не принимайте близко к себе. Просто меня немного задело «ограничение на 1024 символов в строке и на исключение при отсутствие файла с логами». Решил рассказать людям, о его старом дедушке — рабочей лошадке log4cxx, лишённого этих детских болезней.
Смысл моего этого замечания на самом деле был в том, что log4cxx (уверен, что это относится и к log4cpp/log4cplusplus) можно быть сильно, и быстро, кастомизировать под свои кейзы в случае необходимости. Конечно, такое требуется обычно раз в жизни, но обычно в тот самый момент, когда времени переходить на новый логгер точно не будет. Я, кстати, слабо представляю зачем тот же DayliRollingAppender вообще нужен, хоть и делал его. Другими словами, кастомизация логгера — это один из кейсов его использования. И если вы хотели «сравнить логеры с точки зрения их простоты использования», простота расширения log4cxx — это вообще в тему.
Это большой миф, что синхронное логгирование может что-то там замедлить. Объясню на примере. Мы делаем софт, который сильно грузит cpu и диск. И для нас каждый процент cpu, так же как любая задержка работы с файловой системой, очень важен. Вплоть до того, что пришлось Sleep(0.5) реализовывать, так как 1 миллисекунда для нас — это слишком большая задержка. Соответственно, постоянно профилируемся по нагрузке проца, и часто ищем задержки с помощью gpuview и других тулзовин. Так вот, синхронный логгер не даёт ни сколько нибудь значительную нагрузку на cpu, ни сколько нибудь значительных задержек работы с файловой системой. Насколько я помню, несмотрю на то, что пишет он синхронно в файл, то сам файл по дефолту флашится на диск сразу после записи только при ERROR/FATAL. А так собственно есть буферизация в винде, по умолчанию винда скидывает данные на диск большими блоками (аля секторами), что очень эффективно. В синтетических тестах может и есть какая-то разница с асинхронными логгерами, а вот в реальных приложениях — нету.
Вы зря путаете логгирование и перехват исключений. Одно другое никак не заменяет. А случаев, когда партнёр, находясь в 300 км от ближайшего интернета, по телефону зачитывает логи модуля, который падает, за неимением возможности выслать даже минимальные дампы, в моей практике было не один, не пять, и даже не 10. Кстати, как показала практика — распечатывание стека при падении в самом падающем приложении — тоже не состоятельная идея (применительно к Винде). Там куча проблем, которые надо решать. Например, либо символы в бинари встраивать (C7), увеличивая их размер в разы, а то и в десятки раз, либо всё-таки старая добрая pdb и раскрутка стека на машине разработчика. Или ещё например, что бы записать в файл, когда закончилась память (выжрали 4 гига, и new постоянно кидает bad_alloc), тоже надо постараться, так как даже fopen пытаться выделить некие буффера, и если памяти реально не осталось, то даже это сделать не получится, и том чтобы использовать ofstream разговор вообще уже не идёт (если что я знаю как такую проблему решать, я к тому, что это всё не тривиально).
Вы здесь опять суть не уловили. Дело не в том, что есть бесплатный logmx для некоммерческого использования, а в том, что для log4j/log4net/log4cxx построена огромная инфрастуктура. Тех же анализаторов логов можно за 10 минут наверное с десяток нагуглить, на любой вкус и кошелёк, всё не закачанчивается на logmx'е. Кстати, обычные логи в log4cxx настраиваются так хорошо, что обычно не требуют специализированных средств для своего анализа, обычно это бывает полезно в очень специфичных случаях.
Так же у обоих большой плюс в том что для этого семейства логгеров (включая log4j и log4net) есть сторонние инструменты для работы с файлами логов, не надо придумывать свои велосипеды (например, logMX).
ссылка
Да вы прямо бог примеров :). 66.6℅ президентов РФ прямо подтверждают ваши слова.
Один FullHD поток — да уже лет десять кто только не умеет аппаратно декомпрессить — это не интересно.
Кстати, с кодированием 264 тоже проблем у проца не возникает, что радует.