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

C++ такой, как он есть, не нужен. Загрублю. В низконагруженной прикладухе нужен GC, в высоконагруженой не нужен C++, во всей остальной low-level фигне не нужен даром. Нужен рантайм другому языку? C++ никаким боком. Нужна какая-нибудь ядерная магия? C++ не при делах. Нужен универсальный ассемблер? C, конечно же. Числодробилка? Опять мимо. Эмбедщина? Да что ж такое.

пытаетесь применять C++ там, где ему не место. И это вовсе не проблема C++.

А где, где ему место?? На свалке истории?

Если бы он был не нужен, им бы никто не пользовался.

Если бы он был не нужен, им бы никто не начинал пользовался.

FTFY.

C++ такой, как он есть, не нужен.

Пишет нам товарищ из параллельной вселенной. Как у вас там, дорогой корреспондент, реальность не протекает?

Вот прям такой маразм по всем пунктам, что даже не хочется в N-й раз тратить время на разбор.

Т. к. строки s1 и s2 компилятор и библиотека в данном случае разрушать не имеют права, то в лучшем случае мы избавимся от 1 лишнего временного объекта, но 1 всё равно останется.

У меня такое ощущение, что кто-то из нас неправильно считает. Вот вы пишете:

при выполнении данной операции сначала создаётся новая временная строка, содержащая s1 и " ", затем эта строка объединяется с s2 в ещё одну временную строку, после чего всё это копируется в s3, а временные строки удаляются.

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

Кроме того, в C++ для эффективного сложения строк не обязательно делать вот так:

s3.reserve(s1.size() + 1 + s2.size());
s3 = s1;
s3 += " ";
s3 += s2;

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

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

Пишет нам товарищ из параллельной вселенной.

Не завидую вашей вселенной.

Я тебе >5 пунктов написал, а ты ни одного не оспорил и ни одной ниши привести не смог? Ясно-понятно.

Я тебе >5 пунктов написал

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

Что ж ты сразу не сказал? Теперь я прозрел! ФП не нужно, темплейты — не костыль, ниша не нужна, кресты божественны и без всякой ниши.

поскольку за счет нескольких вспомогательных функций на базе variadic templates можно будет сделать вот так:

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

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

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

Да так же.

#define concat(...) \
    concat_impl(sizeof((const char*[]){__VA_ARGS__})/sizeof(const char*), (const char*[]){__VA_ARGS__})

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


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

Что ж ты сразу не сказал?

Вообще-то сказал.

Теперь я прозрел!

Сильно сомневаюсь.

ФП не нужно

Для нормального ФП нужен GC. Соответственно, для тех, кому нужен нормальный ФП, существует множество ФЯ. Как нативных, так и базирующихся на JVM или .NET.

темплейты — не костыль

Не костыль.

ниша не нужна

Ниш достаточно. Но в этой вселенной, не в вашей.

кресты божественны

Это не так, но в вашей реальности все может быть и по другому.

А память выделять и чистить? Или в Сишечке это не принято?

Ну и с типобезопасностью как?

Шлангуй дальше в своей воображаемой нише.

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

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

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

Какой иксперд, аргументы прям один весомее другого.

Твои бесконечно весомее, средняя весомость — примерно NaN.

Если бы он был не нужен, им бы никто не начинал пользовался.

FTFY.

Это слив.

NaN это акроним Not a NaN?

По крайней мере откровенной ерунды не говорю.

Ретрограды по инерции пользуются. Хоть слив, хоть чернослив, а я жду ниши.

1) Либо free, либо в функции создавать thread_local static буфер, и тогда не освобождать...

2) С типобезопастностью всё гораздо лучше, чем у variadic function C. (сейчас в С правильно делать используя именно variadic macros, а не variadic function)

    double a = 5;
    double* h = &a;
    char* s3 = concat("hello", h);

warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
     char* s3 = concat("hello", h);
                                ^

char* s3 = concat(557, "world");

 warning: initialization makes pointer from integer without a cast [-Wint-conversion]
     s3 = concat(557, "world");
                 ^

Числодробилка? Опять мимо.

и что же использовать для этих целей?

а я жду ниши

Ну вот правда, откуда, бл*дь, столько «малолетних дебилов» (с), которые не могут просто по сторонам посмотреть. Ниш немного, но они есть и каждая из них вовсе не такая уж и маленькая:

• высокопроизводительные вычисления (предсказания прогнозов погоды, моделирование химических и физических процессов, расчеты прочности конструкций, имитационное моделирование, модные нынче big-data, machine lerning, computer vision и вот это вот все);
• системное и околосистемное программирование (ОС (Linux-ом и BSD мир не ограничен), ПО промежуточного слоя (СУБД, MQ), компиляторы, антивирусы и пр.);
• реальное время и встраиваемое ПО (SCADA+IIoT, avionics, automotive, finance, telecom, не говоря уже про оборонку);
• тяжелый и ресурсоемкий десктопный софт (CAD, софт для профессиональной работы с фото/видео/аудио, тяжелые игры, браузеры, MSOffice и его аналоги, ...);
• кросс-платформенные приложения. Ядро пишется на C++, GUI — на родных технологиях, как итог приложения работают и на Win, и на Linux, и на Android, и на iOS, и на всяких умных и не очень гаджетах).

Примеры всего этого хозяйства на C++ легко гуглится.

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

Сойдут a) любой язык без ООП, компилящийся в натив, opencl или что там сейчас модно б) инструмент, позволяющий это реализовать/ сынтерфейсить для интерпретируемого языка.

То есть если остальное у тебя на Python, то cython, numba, pyopencl... C++ тут ловить нечего.

Хоть слив, хоть чернослив, а я жду ниши.

А иначе что - ты останешься при своем мнении? Оставайся, не вопрос. Это никак не отменяет факта, что Си++ широко используется и, следовательно, нужен. Забавно, но этот факт очевиден даже по главной ЛОРа в данный момент.

Числодробилка? Опять мимо.

и что же использовать для этих целей?

Сойдут a) любой язык без ООП, компилящийся в натив, opencl или что там сейчас модно

Если ты не знал (хотя ты, конечно, не знал), ООП есть даже в современном Fortran («современный» - это Fortran 15-летней давности). По твоему ценному мнению, использовать его в числодробилке нельзя. Ценное мнение такое ценное.

ООП есть даже в современном Fortran

Cobol тут показательнее, лол

откуда

Примерно оттуда же, откуда в за 20 лет до них вылезли современные плюсовые ретрограды

высокопроизводительные вычисления

И что такого тут дадут плюсы? Они умеют компилиться в натив? Они не одни такие. Они компилятся в код, пригодный для запуска на современных высокопроизводительных кластерах с архитектурой сильно отличной от персональника? Че-то ой.

системное и околосистемное программирование

Широко как страна моя родная.

ПО промежуточного слоя (СУБД, MQ), компиляторы, антивирусы и пр.);

Только выиграют от смены языка на нормальный. C++ здесь лучше чем C, но не более.

реальное время

Вот тут согласен.

встраиваемое ПО

Зачем там именно C++? Непонятно. Язык-то не самый легковесный, да и фичи у него не о том.

тяжелый и ресурсоемкий десктопный софт (CAD, софт для профессиональной работы с фото/видео/аудио, тяжелые игры, браузеры, MSOffice и его аналоги, ...);

Зачем, прости, видеоредактору C++? Хреновины же с вычислительно тяжелой _логикой_ типа браузеров так только рады бы с C++ свалить, тут чистое legacy.

кросс-платформенные приложения.

Ну тут просто гасите свет. C++ ради кроссплатформенности. Уникальная черта, C, Java, Python — все помирают от зависти, никто так больше не умеет.

Примеры всего этого хозяйства на C++ легко гуглится.

Как и гифки идиотов, сующих в разные места пиротехнику.

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

Язык без ООП сойдет

использовать <язык без ООП> в числодробилке нельзя

С соломой спорь сам.

Это никак не отменяет факта, что Си++ широко используется и, следовательно, нужен.

Люди по всему миру жрут тайд => тайд нужен.

ООП есть даже в современном Fortran

Cobol тут показательнее, лол

Еще один профессионал числодробления?

Хреновины же с вычислительно тяжелой _логикой_ типа браузеров так только рады бы с C++ свалить, тут чистое legacy.

Было бы куда - свалили бы уже. См. на мозилу.

Люди по всему миру жрут тайд

Ты понимаешь, что ты поехавший? Это риторический вопрос, можно не отвечать.

Ну они и пытаются, и не от идеальности плюсов.

Python

Справедливости ради, Python, как и Ruby на винде через одно место устанавливаются и работают, ибо под unix заточены.

Сюда же можно git приписать.

Разработка под виндой - вообще странная затея.

А непоехавшему что, нельзя тыкать тебя в твои логические ошибки?

Не так прочел, сонный

Про идеальность плюсов никто и не говорит. Альтернативы просто нет.

Вон Гугл пишет свою новую ОС на плюсах, а не на расте, или своём же Go. С чего бы это?

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

Да, действительно помогло частично.

clock resolution: mean is 43.349 ns (10240002 iterations)

benchmarking c
collecting 100 samples, 6266 iterations each, in estimated 3.7596 ms
mean: 6.73442 ns, lb 6.72139 ns, ub 6.79018 ns, ci 0.95
std dev: 0.112451 ns, lb 0.00201177 ns, ub 0.264515 ns, ci 0.95
found 29 outliers among 100 samples (29%)
variance is slightly inflated by outliers

benchmarking c++
collecting 100 samples, 1797 iterations each, in estimated 4.3128 ms
mean: 22.7102 ns, lb 22.6735 ns, ub 22.7942 ns, ci 0.95
std dev: 0.272355 ns, lb 0.145418 ns, ub 0.436722 ns, ci 0.95
found 17 outliers among 100 samples (17%)
variance is unaffected by outliers

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

А еще MS не поддерживает C новее С89. Это не означает, что С99 — плохой язык, это просто, гм, своеобразная платформа.

С отсутствия альтернативы плюсам? Что донести-то хотел? Я даже не понял, нет альтернативы или вот она.

А непоехавшему что, нельзя [...]

Что можно или нельзя непоехавшим - нерелевантно для тебя. Ты-то поехавший. Попробуй жрать меньше тайда.

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

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

Че-т припекло там у тебя. Извини, не хотел. Поехавший так поехавший, спорить не буду.

Поехавший так поехавший

Вот. Признание - первый шаг к исцелению.

А теперь покопайся на researchgate и узнаешь, что на числодробилках массово используется C++ и Fortran.

Fortran при этом тоже можно использовать без ООП, компилится в нативный, есть библиоте и для работы с opencl и cuda (например, привет тебе от компилятора PGI, одним из разработчиков-спонсоров является nvidia и там в комплекте есть поддержка необходимых для этого инструментов).

И как-то нет оснований полагать, что в C++ с этим всем есть проблемы.

Блин, я вообще-то на работе пишу наукоемкие числодробилки. За остальные области не ручаюсь, но в моделировании плазменного кильватерного ускорения доминируют Python для логики, GPU для «дробления». Встречал и чистый C, и Python + Fortran, и Python + Cython, и Python + C++ даже пару раз видел. От C++ там было только расширение файла.

И как-то нет оснований полагать, что в C++ с этим всем есть проблемы.

Нету в C++ с этим проблем. Как и нету нужды в фичах именно C++ у наукоемких числодробилок.

И что такого тут дадут плюсы?

Вы вообще когда-нибудь плюсы в глаза видели?

Там очень дешевые абстракции. Которые сильно сокращают трудозатраты на разработку. И за которыми можно прятать все, что угодно, хоть использование специализированных процессорных инструкций, хоть делегирование вычислений на специализированные устройства. Плюс шаблоны. Плюс специализация шаблонов. Плюс expression templates на этих же самых шаблонах.

Широко как страна моя родная.

Тем не менее, так оно и есть. C++ широко используется в разработке таких ОС, как Windows и macOS. Не говоря уже про разные экспериментальные штуки, вроде IncludeOS и чего там сейчас делает Google.

Только выиграют от смены языка на нормальный. C++ здесь лучше чем C, но не более.

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

Зачем там именно C++? Непонятно.

Если вам что-то не понятно, то это не означает, что встраиваемое ПО на C++ не делается. Или что использование C++ там не выгодно. Выгодно. Как раз за счет тех же шаблонов, RAII, лямбд и более строгой типизации, чем в C.

Зачем, прости, видеоредактору C++?

Затем, что это a) нехилая числодробилка и b) у нее высокие требования к отзывчивости.

Ну тут просто гасите свет. C++ ради кроссплатформенности.

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

Вообще, ощущение, что разговариваю с пришельцем из параллельной вселенной только усиливается. Хорошо, если не с пациентом палаты №6.