- =A=L=X=
- Постоялец
=A=L=X=
> Что плохого будет если не плюс?
плохого - человек который раз первый раз видит язык\библиотеку может не понять как складывать строки.
хорошего (если в языке есть автовывод\динамическая типизация) - минус один источник трудноуловимых багов.
kipar
> плохого - человек который раз первый раз видит язык\библиотеку может не понять как складывать строки.
Эээ...
Что это значит?
Мешает получить справку о том, что ты инвалид умственного труда или что?
Как можно перепутать сложение строк и чисел?
Язык же со статической типизацией.
Поэтому я не понял о чём ты.
=A=L=X=
> Принтф это запрещенная уже лет 30 как практика. Ненадёжная и неправильная.
Кем запрещённая? Можно пруфы? Ты как всегда пишешь чушь. Если уж и существуют какие-то общепризнанные истины в форматировании, то это только то, что как раз именно конкатенация строк это наихудший из возможных способов.
Например вот история про JS: https://uniqname.medium.com/a55078ac4dcc
C#: https://www.nilebits.com/blog/2023/09/improving-code-readability-… enation-in-c/
И даже SQL: https://www.quora.com/Why-is-concatenating-SQL-string-is-bad-idea
Так что иди обтекай.
Zefick
> Например вот история про JS: https://uniqname.medium.com/a55078ac4dcc
The solution
Ok, so now we know we shouldn’t use + for string concatenation, but what should we use. Well, we could go a few different ways, but I think the most obvious — the one that makes it very clear we mean to be dealing with building up a string — is by using template literals.
const combine = (a, b) => `${a}${b}`
That’s much nicer. It obvious that we are trying to combine strings here. Sure, value coercion to strings can still happen if one of the values is not a string, but it is evident that the end result here is going to be a string. With + we could get a number or a string, depending on what values we are combining.
Тьфу. Ты реально это как аргумент задумал? Отряхнись уже от кала и потрохов, не место в приличном месте показывать такое.
Zefick
Расскажи про строки в яве
=A=L=X=
> как беременную корову на льду разнесло - одни копыта вправо другие влево, всё порознь
Ну не знаю, лично меня что писать напрягает конкатенацию, что читать. Если это банальное:
echo "error code: ".$i;То ок, а если даже что-то типа такого:
echo "error code: '" . $i . "'";
То уже прямо напрягает, и я предпочту альтернативы с интерполяцией/принтфом, ведь так сразу видно всю строку-шаблон, а значения-параметры мало интересны.
echo "error code: '{$i}'";printf("error code: '%d'", $i);
$msg = sprintf("error code: '%d'", $i); echo $msg;
Тебя именно printf вымораживает, или современные format/print тоже? Ниже твой недавний пример, но с перегруженным +, и тоже самое, но через std::format - всё равно предпочтёшь первый вариант?
template< typename... Args > void checkFunctionCompatibility(std::shared_ptr< Function > function, int sizeOfReturn ) { if ( function->getReturnSize( ) != sizeOfReturn ) throw std::runtime_error( std::string( "Incompatible function " ) + function->getName( ) + ": wrong return size " + function->getReturnSize( ) + " instead of " + sizeOfReturn + "." ); if ( function->getParamsCount( ) != sizeof...( Args ) ) throw std::runtime_error( std::string( "Incompatible function " ) + function->getName( ) + ": wrong params count " + function->getParamsCount( ) + " instead of " + std::to_string( sizeof...( Args ) ) + "." ); };
VS
template<typename... Args> void checkFunctionCompatibility2(std::shared_ptr<Function> function, int sizeOfReturn) { if ( function->getReturnSize( ) != sizeOfReturn) throw std::runtime_error( std::format( "Incompatible function {}: wrong return size {} instead of {}.", function->getName( ), function->getReturnSize( ), sizeOfReturn )); if ( function->getParamsCount( ) != sizeof...( Args)) throw std::runtime_error( std::format( "Incompatible function {}: wrong params count {} instead of {}.", function->getName( ), function->getParamsCount( ), sizeof...( Args) )); };
entryway
Ты плохой ... Говорят не надо пользоваться исключениями ибо ...
Went
> Я бы еще руки оторвал гениям, которые придумали для строк всякие хитрые конструкторы принимающие числа, чары и их комбинации
Встроенные объекты как std::string, std::vector итд, это универсальные объекты, главная задача которых упростить для студентов написание лабораторных работ по информатике. В языке есть всё необходимое, чтобы создать собственный объект с нужным функционалом.
=A=L=X=
> Поэтому я не понял о чём ты.
это да. Хотя вроде понедельник уже. Ты же спросил в чем минусы того что сложение будет НЕ знаком плюс.
=A=L=X=
> Что плохого будет если не плюс?
=A=L=X=
> просто пишешь String("abc") + 100 и получишь строку "abc100".
> Как можно перепутать сложение строк и чисел?
> Язык же со статической типизацией.
int a = 100;
int b = 200;
String c = String("abc") + a + b;Получаем "abc100200", хотя возможно ожидали "abc300". Прямо как в джаваскрипте.
> Принтф это запрещенная уже лет 30 как практика.
Запрещенная в С/С++ ты хотел сказать? Потому как в нормальных языках нет никаких проблем с принтф-лайк конструкциями.
iw4nna.rock
И как эти конструкторы облегчают написание лабораторных работ? Что мешало сделать вместо неочевидного конструктора свободную функцию с осмысленным названием?
std::noob
> Запрещенная в С/С++ ты хотел сказать?
Даже в крестах это не "запретили", а только в 20-м году добавили возможность писать вот так:
std::string msg = std::format("{:*^10}\n{:*>10}!", "hello", "world");
Но это по сути просто новый хипстерский sprintf. И то, что до сих пор в язык добавляют подобные фичи говорит только о том, что любые заявления об их запрете это не более чем синюшный бред.
Не, ну с новым принтом хотя бы "права рута" сложнее получить, написав что-то типа
std::print(argv[1]);
или
std::print("{} {}", 0);
Zefick
> Даже в крестах это не "запретили", а только в 20-м году добавили возможность писать вот так:
Ну так-то сишный принтф часто критиковали за небезопасность и призывали по возможности от него отказаться. Трупостраус изначально сделал I/O streams в качестве замены printf, а потом уже гомитет втащил std::format в c++20. Например гугловский стайл гайд рекомендует стримы или сторонние библиотеки вместо printf:
The << and >> stream operators provide an API for formatted I/O that is easily learned, portable, reusable, and extensible. printf, by contrast, doesn't even support std::string, to say nothing of user-defined types, and is very difficult to use portably. printf also obliges you to choose among the numerous slightly different versions of that function, and navigate the dozens of conversion specifiers.
Correct portable printf() conversion specifiers for some integral typedefs rely on macro expansions that we find unpleasant to use and impractical to require (the PRI macros from <cinttypes>). Unless there is no reasonable alternative for your particular case, try to avoid or even upgrade APIs that rely on the printf family. Instead use a library supporting typesafe numeric formatting, such as StrCat or Substitute for fast simple conversions, or std::ostream.
entryway
> ведь так сразу видно всю строку-шаблон, а значения-параметры мало интересны.
Ложь именно здесь в этой сентенции. Я программист и для меня важно не только как что-то выводится, но и что именно выводится. Важно всё до последнего цента.
И давайте будем честны перед богом и людьми - идиома printf существует ТОЛЬКО потому что в предревнем Си не существовало конкатенации строк.
Там просто не было такого и приходилось лишаться и изобретать. Изобрели. Понос еще тот от которого потом C++ долго и нудно избавлялся через типизацию <<.
И знаете что? А там была перегрузка для чисел!!! Просто была и код выглядел опрятно.
А эти вот говно " {} {} {} " - неа не выглядят опрятно, а говно где надо разрывать мозг и восстанавливать что и где выводится.
Жизнь этим конструкциям на самом деле даёт internationalization, но в идеале это должно выглядеть как "getLocalizedString(RES.id.string_wrong_count_of_visitors)" бла-бла-бла. Говно, но понятно хотя бы зачем и из каких целей.