Может кто нибудь показать красоту с++?

Variant, в котором тег типа значения и тип самого значения могут быть разными - это песня.

Variant, в котором тег типа значения и тип самого значения могут быть разными - это песня.

Ага, ага :-) А если добавить перегруженный конструктор, который сам выставит тип, то тогда разница в размере выхлопа будет ещё меньше. Поэтому не надо тут мне теории рассказывать.

Поэтому не надо тут мне теории рассказывать.

Рассказывать то можно, но это всё понятно. Песня же, лол :-)

Variant, в котором тег типа значения и тип самого значения могут быть разными - это песня.

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

Речь о том, что такие вещи нужно автоматически писать правильно. А на размер выхлопа пофиг.

Поэтому не надо тут мне теории рассказывать.

Не надо приписывать мне своих фантазий.

Variant, в котором тег типа значения и тип самого значения могут быть разными - это песня.

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

Речь о том, что такие вещи нужно автоматически писать правильно. А на размер выхлопа пофиг.

Лол :-) А то же такие тупые все, один только тэйлганнер автоматически умеет писать конструкторы. Подиж ты :-)

А размер выхлопа тут как раз таки был первостепенен. Речь про раздувание кода.

А то же такие тупые все

Почему все? Пока только один. Но ошибка, к сожалению, характерная.

А размер выхлопа тут как раз таки был первостепенен. Речь про раздувание кода.

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

я не искал о переходе, я искал о fortran

Многомерными массивами NxMxK, но и так интересно.

С многомерными аналогично, разве что не знаю насколько переприсваивания массива через сам себя корректно, но оно работает, хотя скорее всего вызывает копирование.

Вот странпонированием что имелось ввиду? То есть если есть транспонирование как .T, то что делает transpose? Это из внешней библиотеки?

Почему все? Пока только один. Но ошибка, к сожалению, характерная.

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

Далее. Взгляни на Variant от Microsoft. https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms221627(v=vs.85).aspx Там что, тоже ошибка? Нет, там структура, в которой тип значения и само значение могут быть разными. Так что ты в пролёте дважды. Учись :-)

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

Конечно :-) И я доказал.

Это не ошибка. Я ТЕБЯ ТРАЛИЛ!!!!111

Окей.

Окей.

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

Бл*дь, шланговать, так шланговать!

У меня gcc-5.4, поэтому код f2.cpp и g2.cpp был модифицирован под C++14.

А теперь следим за руками:

$ g++ -O3 -flto -std=c++14 prog.cpp variant1.cpp f1.cpp g1.cpp -oprog1_O3
$ g++ -O3 -flto -std=c++14 prog.cpp f2.cpp g2.cpp -oprog2_O3
$ ls -ln prog?_O?
-rwxrwxr-x 1 1000 1000 9464 фев 25 07:51 prog1_O3
-rwxrwxr-x 1 1000 1000 9584 фев 25 07:51 prog2_O3
$ strip prog?_O?
$ ls -ln prog?_O?
-rwxrwxr-x 1 1000 1000 6360 фев 25 07:52 prog1_O3
-rwxrwxr-x 1 1000 1000 6368 фев 25 07:52 prog2_O3

Ну и да, судя по использованию extern и forward не по делу, вы с C++ом вряд ли имеете дело. Если только на форуме повыеживаться.

Тебе привели пример как в С++ делается то же самое, только с приятным синтаксисом (+), а ты шлангуешь

Да, посмотрел, и правда хорошо сделано. Но только я читал (сам, правда, не тестировал), что строки и другие классы Qt по скорости уступают аналогичным из STL. Брехня или нет?

Эт почему еще «крестовые фичи использоваться не будут»? С библиотекой придется поужаться (, исключения тоже могут не прокатить (хотя смотря как это ядро реализовано), а все остальное не имеет приниципиальных проблем

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

benchmarking c
mean: 6.75393 ns, lb 6.72732 ns, ub 6.8659 ns, ci 0.95
std dev: 0.240033 ns, lb 0.0392782 ns, ub 0.56316 ns, ci 0.95

benchmarking c++
mean: 22.6757 ns, lb 22.6529 ns, ub 22.7331 ns, ci 0.95
std dev: 0.161126 ns, lb 0.00766571 ns, ub 0.297814 ns, ci 0.95

benchmarking Qt
mean: 339.169 ns, lb 337.292 ns, ub 342.762 ns, ci 0.95
std dev: 12.7975 ns, lb 7.63821 ns, ub 19.3936 ns, ci 0.95

Спасибо за бенчамрки. Всё коротко и ясно.

Там дальше корректные результаты: Может кто нибудь показать красоту с++? (комментарий)

benchmarking Qt
collecting 100 samples, 426 iterations each, in estimated 4.3026 ms
mean: 100.978 ns, lb 100.802 ns, ub 101.642 ns, ci 0.95
std dev: 1.43752 ns, lb 0.00194991 ns, ub 3.32686 ns, ci 0.95
found 3 outliers among 100 samples (3%)
variance is slightly inflated by outliers

Узнал для себя обязательный дефайн для Qt проектов :)

Числодробилки и прикладуха уже почти все, а в системном программировании и эмбедщине плюсы и даром не сдались.

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

В низконагруженной прикладухе нужен GC, в высоконагруженой не нужен C++

Вот с этим не совсем согласен. Всё-таки gc жрёт ресурсы мама не горюй. Думаю, какой-нибудь браузер на языке с gc будет сверх тормознутым, а вот на крестах — более-менее.

Попробуйте добавить QT_USE_QSTRINGBUILDER дефайн.

Узнал для себя обязательный дефайн для Qt проектов :)

А, это тот самый, ссылку на реализацию которого в качестве примера однократного выделения памяти дал annulen:

http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qstringbuilder.h

QStringBuilder(const A &a_, const B &b_) : a(a_), b(b_) {}
// skip
#if defined(QT_USE_FAST_OPERATOR_PLUS) || defined(QT_USE_QSTRINGBUILDER)
template <typename A, typename B>
QStringBuilder<typename QConcatenable<A>::type, typename QConcatenable<B>::type>
operator+(const A &a, const B &b)
{
   return QStringBuilder<typename QConcatenable<A>::type, typename QConcatenable<B>::type>(a, b);
}
#endif

http://doc.crossplatform.ru/qt/4.7.x/qstring.html :

В 4.6 был добавлен внутренний шаблонный класс QStringBuilder вместе с несколькими вспомогательными функциями. Этот класс помечен как внутренний и не отражён в документации, потому что вы не должны создавать его экземпляры в своём коде. Он будет использоваться автоматически, как описано ниже. Класс находится в src/corelib/tools/qstringbuilder.cpp, если вы хотите взглянуть на него.

QStringBuilder использует шаблоны выражений и переопределяет оператор '%', так что вы можете использовать '%' вместо '+' для объединения строк, а многократное объединение подстрок будет отложено до момента присвоения окончательного результата QString. В этот момент объём памяти, необходимый для окончательного результата, уже известен. Распределитель памяти в этом случае вызывается для получения необходимого места один раз, и подстроки копируются туда одна за другой.

Но всё равно, хоть 100 и меньше 339, но по-прежнему намного больше 22 и тем более 6. Хотя на первый взгляд реализовано всё грамотно и кажется, что должно выполняться быстрее, чем в STL и не намного медленнее, чем в чистом си. Впрочем, это надо профилировать, а не гадать.

Но при использовании rvalue references и move semantics получается одна временная строка для результата сложения s1 и " ", затем к этой же временной строке добавляется s2 (тут возможна переаллокация, а может все влезет

Вот и я о том же. Ключевые слова выделил жирным.

s3 = concat(s1, " ", s2);

и эта запись будет по эффективности не хуже вручную выписанного кода.

А вот как вы подобную concat сделаете на чистом Си?

Ну, как предложил vmx в этом каменте:

        stream = open_memstream(&str, &len);
	fprintf(stream, "%s %s", "The", "string");
	fclose(stream);

И делать ничего не надо. Всё уже сделано за нас.

Но если не нравятся потоки, то здесь уже предложили альтернативную реализацию. Переменное число параметров функции в си поддерживалось с самого начала.

И делать ничего не надо. Всё уже сделано за нас.

Задолго до попадания open_memstream в POSIX-2008 в C++ уже был ostringstream.

Но если не нравятся потоки, то здесь уже предложили альтернативную реализацию. Переменное число параметров функции в си поддерживалось с самого начала.

Эту альтернативную реализацию уже обсудили. Надежность у нее так себе.

Как и кроссплатформенность у open_memstream. Если, конечно, кроссплатформенностью не называть способность работать только в различных диалектах Unix-а. В отличии от ostringstream. В котором, к тому же, с типобезопасностью, опять же, получше, чем у printf-семейств.

Разумеется, ты забудешь.

Почему ты так думаешь?

Я не «думаю», я знаю. Потому что рано или поздно, каждый забудет.

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

Предупреждения — это хорошо. Но на них забивают так же часто, как и на вызовы free. А то и чаще.

Ну, это уже проблема тех, кто забивает.

Ну, это уже проблема тех, кто забивает.

А вот в C++ на это забить просто не получится. Вот ведь незадача какая.

Не знаю, что за transpose, а .T - фишка numpy, создает транспонированный view без копирования.

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

Тем не менее ты написал типичный код, который к этому приводит. Я понимаю, что это пример в дискуссии, но на Си++ даже в дискуссии приведен код, в котором переполнение буфера исключено.

Но существует не менее известная и серьёзная проблема утечек памяти, решаемая gc. И что из этого следует?

То, что проблема «решается GC», нерелевантно (кстати, GC не решает проблему утечек памяти). А для уменьшения вероятности утечек надо использовать специально предназначенные средства. В Си++ это shared_ptr и unique_ptr. В Си таких нет.

Просто надо аккуратнее писать.

Типичное заклинание от любителей «сишечки».

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

Кстати, да. Я тоже не заметил, что в си варианте используется статический буфер. Но справедливости ради надо сказать, что хотя формально сравнение и некорректно, но при работе с массивом char и традиционными си-функциями всегда можно выбрать то, что лучше подходит. А вот при работе с std::string и QString выбора нет. И это тоже серьёзный недостаток, если говорить о гибкости и производительности.

Но справедливости ради надо сказать, что хотя формально сравнение и некорректно, но при работе с массивом char и традиционными си-функциями всегда можно выбрать то, что лучше подходит. А вот при работе с std::string и QString выбора нет. И это тоже серьёзный недостаток, если говорить о гибкости и производительности.

Какой стиль! И какая чушь.

Но если не нравятся потоки, то здесь уже предложили альтернативную реализацию. Переменное число параметров функции в си поддерживалось с самого начала.

Эту альтернативную реализацию уже обсудили. Надежность у нее так себе.

Можно добавить совместимость с С++, и компилировать С++ компилятором. Конечно #ifdef, но зато будут ошибки компиляции, а не предупреждения.

char* concat_impl(size_t n, const char* strs[])
{
...
}

#ifndef __cplusplus
#define concat(...) \
    concat_impl(sizeof((const char*[]){__VA_ARGS__})/sizeof(const char*), (const char*[]){__VA_ARGS__})
#else
template <typename... Args>
char* concat(Args... args)
{
    const char* temp[] = {args...};
    return concat_impl(sizeof...(Args), temp);
}
#endif

int main()
{
    char* s3 = concat("hello", "world", 1);
}

src/main.c: In instantiation of ‘char* concat(Args ...) [with Args = {const char*, const char*, int}]’:
src/main.c:48:42:   required from here
src/main.c:39:17: error: invalid conversion from ‘int’ to ‘const char*’ [-fpermissive]
     const char* temp[] = {args...};
                 ^~~~

Можно добавить совместимость с С++, и компилировать С++ компилятором.

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

Отлично. Просто отлично.

Ну и да, судя по использованию extern и forward не по делу, вы с C++ом вряд ли имеете дело.

Не надо трындеть. extern тут чтобы по делу. Можно без него? Можно. Но я для себя подчеркнул, что f, g, h объявлены где-то там. Далее, forward. Тут я забыл поставить &&. Это значит? Ничего. Я написал целую простыть кода на цепепе, но забыл поставить && в аргументе, и потому Евгений Охотников сделал вывод, что, таки нет, с Си++-м этот персонаж не знаком :-)

Если только на форуме повыеживаться.

А ещё на конференциях. Вы то любите по ним мотаться :-)

А вот в C++ на это забить просто не получится. Вот ведь незадача какая.

Ага. И поэтому наёмные ламерки разных мастей, ответственные за немалые проекты, генерируют тонны кода с сотнями варнингов, на которые забивают болт.

Да, кстати, достаточно дать компилятору MSVC опцию /Wall и включить в cpp-шник инклюд стандартной библиотеке, и можно увидеть кучу варнингов авторам стандартной библиотеки. Лол. :-)

Специально для форумных тролей не умеющих читать: Может кто нибудь показать красоту с++? (комментарий)

Между «вряд ли имеет дело» и «с Си++-м этот персонаж не знаком» есть большая разница, но смайлодаун, даже зарегистрировавшись на LOR-е, умнее не стал и разницу эту не заметил.

Специально для форумных тролей не умеющих читать: Может кто нибудь показать красоту с++? (комментарий)

Не стоит забывать, что в Qt UTF-16 + валидация.

UTF16 — это, конечно, плохо, но я не вижу, как её использование может повлиять на производительность. И о валидации чего идёт речь?

UTF16 — это, конечно, плохо, но я не вижу, как её использование может повлиять на производительность. И о валидации чего идёт речь?

«Сколько тебе лет?» (ц)

Вы не видите разницы между «складыванием» байт и конкатенацией строк? Типичный сишник.

for (int i = 0; i < size; ++i) {
  if (!callback(i)) {
    free(something);
    return -1;
  }
}

...то у вас тут undefined behaviour и поведение зависит от версии компилятора, т.е. предсказать его очень даже не легко, и, в общем случае, невозможно

Почему здесь будет ub?

Между «вряд ли имеет дело» и «с Си++-м этот персонаж не знаком» есть большая разница, но смайлодаун, даже зарегистрировавшись на LOR-е, умнее не стал и разницу эту не заметил.

По правде говоря, с Си++ пока приходится иметь дело. Каждый день. Поэтому все эти дешёвые придирки «не по делу forward, extern» меня вообще не трогают. Почему? Потому что в реальных проектах (которые закрыты по большей части) далеко не такой вылизанный код, как у вас в репе на гитхабе. (Это не комплимент, а факт.) На деле же приходится видеть такой ущербанский код на Си++, что просто удивительно как на этом люди ещё и зарабатывают? Там ни то что forward для T без &&, там маразм любого уровня и на любой вкус - начиная от непролазных макр, генерирующих объявления/определения геттеров/сеттеров, заканчивая совершенно неадекватными абстракциями и горами велосипедов, выполненных на том же уровне маразма.

Что касается Си++. Нет ощущения, что вы знаете его лучше, чем я :-) Судить можно по всему - от споров тут, до кода на гитхабе.

На деле же приходится видеть такой ущербанский код на Си++, что просто удивительно как на этом люди ещё и зарабатывают?

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

Нет ощущения, что вы знаете его лучше, чем я

Это вообще никого не ебё волнует. А если у вас какие-то комплексы по поводу знает/не знает, лучше/хуже, то это ваши половые сложности.

Судя по херне, которую вы здесь изливаете, такие как вы этот ущербанский код и производят.

Нет, такие как я этот код подвергают критике. И знаете что? Авторы такого кода эту критику не принимают. Появление подобного критика для них является мощнейшим раздражителем. И вот с этого момента у подобных ламерков как раз и начинаются проблемы.

А потом еще и старательно убеждают, что так и нужно, что это нормально, и что лучше ну никак нельзя.

Скажу больше. Эти ламерки не понимают, что можно лучше. И самое печальное, что не хотят понимать. Ничему новому подобные ламерки учиться не хотят в принципе. Они считают, что им и так удалось хорошо пристроиться в какой-нибудь конторе, создавая видимость грандиозной работы, получая за это неплохие деньги, кстати.

Это вообще никого не ебё волнует. А если у вас какие-то комплексы по поводу знает/не знает, лучше/хуже, то это ваши половые сложности.

У всех свои сложности. Но вы же сами провоцируете. Зачем?

Всё-таки gc жрёт ресурсы мама не горюй. Думаю, какой-нибудь браузер на языке с gc будет сверх тормознутым, а вот на крестах — более-менее.

В коде движков JavaScript популярных браузеров используется GC, следовательно, и в браузерах в целом.

$ g++ -O3 -flto -std=c++1z prog.cpp variant1.cpp f1.cpp g1.cpp -oprog1
$ g++ -O3 -flto -std=c++1z prog.cpp f2.cpp g2.cpp -oprog2
$ ls -nl prog1 prog2
-rwxrwxr-x 1 1000 1000 9744 фев 24 22:57 prog1
-rwxrwxr-x 1 1000 1000 9872 фев 24 22:57 prog2

Мне кажется, что тут дело не в шаблонах, а в том, что в prog2 тела методов реализованы внутри классов, что делает их inline. Т. е. всё дело в инлайнах. Я попробовал скомпилять у себя эти 2 варианта с такими же опциями + prog3, где тело шаблонной функции вынесено за пределы класса + prog11, где, наоборот, все функции реализованы внутри класса в хидере, но без шаблонов, и вот что получил:

-rwxr-xr-x 1 1000 999 14864 фев 25 13:25 prog1
-rwxr-xr-x 1 1000 999 14992 фев 25 13:38 prog11
-rwxr-xr-x 1 1000 999 14936 фев 25 13:25 prog2
-rwxr-xr-x 1 1000 999 14936 фев 25 13:31 prog3

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

Кроме того, у меня при использовании тех же опций, тот же код скомпилировался в значительно более длинные elf'ы. Компилятор у меня g++ (GCC) 7.3.0. Так что тут многое зависит и от версии компилятора.

Ну, это уже проблема тех, кто забивает.

А вот в C++ на это забить просто не получится. Вот ведь незадача какая.

Вот с этим полностью согласен. И считаю это серьёзным недостатком си по сравнению с си++. Но тут, видимо, проблема легаси.

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

Тем не менее ты написал типичный код, который к этому приводит.

Нет. Я привёл фрагмент кода, который может как приводить, так и не приводить к этому, в зависимости от аккуратности программиста. Если он предварительно вычислил все длины и выделил нужный объём памяти с запасом или без (зависит от дальнейшего использования этой памяти), то никакой уязвимости не будет. А вот если он ничего не проверил и выделил 100500 байт памяти, считая, что в такой буфер всё что угодно влезет, то будет и уязвимость, и неоправданный расход памяти, что сведёт все достоинства си на нет.

То, что проблема «решается GC», нерелевантно

Почему?

GC не решает проблему утечек памяти

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

А для уменьшения вероятности утечек надо использовать специально предназначенные средства. В Си++ это shared_ptr и unique_ptr.

Умные указатели — ещё один способ замедлить код.

Просто надо аккуратнее писать.

Типичное заклинание от любителей «сишечки».

Вообще-то это для любых языков актуально.

И это тоже серьёзный недостаток, если говорить о гибкости и производительности.

Какой стиль! И какая чушь.

Почему чушь и что не так со стилем?

Вы не видите разницы между «складыванием» байт и конкатенацией строк? Типичный сишник.

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

что не так со стилем?

Такое впечатление, что пишет подросток, который изо всех сил пытается казаться взрослым и рассудительным.

Всё-таки gc жрёт ресурсы мама не горюй. Думаю, какой-нибудь браузер на языке с gc будет сверх тормознутым, а вот на крестах — более-менее.

В коде движков JavaScript популярных браузеров используется GC

Поэтому js и жрёт так нещадно ресурсы. Не только поэтому, конечно, но в том числе. А если этот gc ещё и в основной код браузера добавить, то будет ещё хуже, и отключение js уже не поможет.

следовательно, и в браузерах в целом.

В таком случае, в любом браузере, поддерживающем java-апплеты, используется jvm, а значит любой браузер полностью идентичен браузеру, работающему из-под jvm, из чего следует, что неважно, на си ты пишешь браузер или на яве — результат будет одинаковым.

что не так со стилем?

Такое впечатление, что пишет подросток, который изо всех сил пытается казаться взрослым и рассудительным.

Имхо, это уже проблема читающего.

А почему чушь?