Готов убивать.

Не очень, если на это нет причин (например, производительность). Но порой причины как раз есть.

Недавно надо было жёстко ускорить код, заменил iostreams на fprintf, стало быстрее на 15%.

sscanf

Резко отрицательно. Этим говном и на C не надо пользоваться. А так, форматеров аля printf в кресты так и не завезли :(

Нормально отношусь.

Именно sscanf? С большим подозрением.

http://en.cppreference.com/w/cpp/io/c/fscanf

хм. Первый раз вижу пустую капчу.

Если хорошей замены нет, то хорошо. sscanf - дешево и грязно.

http://fmtlib.net/

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

C++ I/O стримы на дух не переношу, пользую везде C API (read/write/printf etc), точнее написал классы-обертки (без операторов << >>) пару лет назад и ими пользуюсь

Хотя коллеги активно их (стримы) используют (даже для форматирования строк)

Судя по некоторым местным ораторам, меня надо убивать. Отношусь хорошо, так как сам им пользуюсь для быстрого парсинга (например, ip-адрес).

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

сторонние библиотеки там нельзя было использовать (ну либо копипастить оттуда код в свой исходник)

Конкретно ублюдка scanf не должно быть и в C коде. А в общем - крайне отрицательно, потому что для всего есть более удобные и безопасные C++ конструкции.

стало быстрее на 15%

cat ускорял?

не поверишь, сортировку вставками)

Нормально отношусь. Если есть удобная и такая же быстрая альтернатива на C++ - пользуюсь ею, иначе - остаюсь на функциях из C.

не поверишь, сортировку вставками

там на сравнении строк можно сэкономить.
Массив слева от текущего элемента всегда упорядочен, можно выполнять поиск места для вставки бинарным поиском — это даст экономию только на сравнениях, но они-то для строк вполне дороги, будет на поиске logN вместо N.

Например, к sscanf?

Ну, sscanf ещё ничего, а вообще - резко отрицательно. Если есть под рукой что-то C++ное, то лучше его - хоть буст, хоть Qt, хоть iostreams.

C++ конструкции

удобные

Знатно на нуль поделил.

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

Usage
To use the fmt library, add format.h and format.cc from a release archive or the Git repository to your project.

Положительно

Там нужно было все исходники в одном файле (не считая инклюды стандартных хедеров).

Там не сравнение строк, там сортировка int32_t, но много io в файл.

sscanf

Зло. Используйте безопасные обёртки.

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

Ну и есть же божественный QtCore, при использовании которого не нужны ни этот ваш sscanf, ни в разы более громоздкие конструккции из STL.

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

Вопрос задаёт телезритель из уфы

А это C или C++?

        template<typename ... Args>
        inline Exception(const char *format, Args ... args)
        {
            size_t size = std::snprintf(nullptr, 0, format, args ...) + 1;
            std::unique_ptr<char[]> buf(new char[size]);
            std::snprintf(buf.get(), size, format, args ...);
            m_what << std::string(buf.get(), buf.get() + size - 1);
        }

До чего же «такой» C++ тошнотворен, и до чего приятен C++ в варианте Qt...

и до чего приятен C++ в варианте Qt...

Простите, я не очень шарю, это C++03 который?

Именно в C++ коде плохо. Тот же sscanf меняю на istringstream.

Но если это просто С++ проект и там есть отдельные функции на C, то есть отдельные .c файлы с C кодом, то нормально.

А если snprintf заменить на Boost.Spirit.Karma вопрос останется в силе?

При чём тут стандарт языка к фреймворку?

Ничего нельзя менять ^_~

Есть мнение, что это говнокод.

Итого 2 знатока уже высказались про говно, в то время как варианты были C,C++.

std::unique_ptr<char[]> buf(new char[size]);

а оно удалится через delete[] или через delete ?

Ну, в интернете написано что unique_ptr<T[]> правильно удалит, удалялкой для массивов.

До чего же «такой» C++ тошнотворен, и до чего приятен C++ в варианте Qt...

Qt-программист в треде.

Почему не vector<char> ?

А в целом мне кажется нормальный код

Попробуйте скомпилировать это C-компилятором и вариант C отпадет сам собой.

Одна из причин, почему код выглядит говном, в том, что создание временного std::string там наверняка лишнее.

Оно в std::stringstream поедет (m_what). А вообще это ж эксепшен, они редко бросаются, if any.

А какой смысл тогда оборачивать в string если в stringstream отдаешь?

Уехать в std::stringstream оно может и через write, а так лишняя аллокация на ровном месте. И проброс исключения становится еще дороже. Да и само хранение в Exception экземпляра std::stringstream вместо хотя бы std::string уже странно, т.к. конструирование пустого std::stringstream само по себе дорого.

Плюс, подозреваю, такого рода конструктор вполне себе проглотит нечто вроде:

throw Exception("id: %i, key: %s", index, std::string("Key"));

Неть, почему, я проверял, ошибочку пишет и не компилирует:

            try { throw generic::Exception("%s", std::string("/path/to/file")); }
            catch (std::exception &e) { std::cout << e.what() << std::endl; }

exceptions.hpp:43:69: error: cannot pass objects of non-trivially-copyable type ‘class std::basic_string<char>’ through ‘...’
             size_t size = std::snprintf(nullptr, 0, format, args ...) + 1;
                                                                     ^
exceptions.hpp:45:60: error: cannot pass objects of non-trivially-copyable type ‘class std::basic_string<char>’ through ‘...’
             std::snprintf(buf.get(), size, format, args ...);
                                                            ^

Конкретно это он не проглотит — т.к. std::string не скушается snprintfом.

Именно в этом и заключается моя главная претензия к printf/scanf и их товарищам в C++-коде: объекты туда не прокинуть, никакой перегрузкой для собственных типов поведения не добавить.

В одной проприетарной библиотеке, которой приходится пользоваться на работе, логгирование сделано как раз через ... и snprintf. Безумно бесит писать по пять раз в строке .c_str() и .ToString().c_str() при использовании их логгера. Лучше уж иостримы.

Я вам ссылку на wandbox дал, там вполне себе компилируется и ожидаемо не работает под gcc-6.3.0. Да и под VC++, полагаю, будет такое же поведение.

То, что clang ругнулся — это хорошо, но это всего лишь один из компиляторов.

А какой смысл тогда оборачивать в string если в stringstream отдаешь?

Убрал уж :) Просто buf.get() остался.

То, что clang ругнулся — это хорошо, но это всего лишь один из компиляторов.

А у меня и не clang, просто ГКК 4.8. Но вообще плохо конечно, непонятно зачем так "починили".