Ровно до тех пор, пока не придется использовать printf в обобщенном коде. Или до тех пор, пока не придется использовать printf для вывода в определенный пользователем поток данных.
Для тех, кто исходит на известную субстанцию от iostreams, уже давно есть fmtlib. Которая, среди прочего, позволяет работать с пользовательскими типами, для которых определены операторы сдвига именно в std::ostream.
Ну, вообще-то, to_chars получает на вход char*. Что получил, то и вернул.
Другое дело, что к to_chars_result::ptr можно получить доступ даже если в to_chars_result::ec находится код ошибки… Вот это не есть хорошо. Какой-нибудь std::variant<char*, std::errc> был бы, наверное, уместнее. Но, вероятно, с точки зрения эффективности to_chars_result обходится дешевле.
Проблема даже не в том, что я не ученый. А в том, что вы не пятилетний ребенок. И объяснять вам простые вещи у меня уже нет ни желания, ни терпения. Равно как и учить вас считать строки.
Вряд ли в этой программе есть что-то сложное, обычный такой quick sort. Сложным для восприятие ее сделал не программист, а синтаксис языка программирования.
Фразы «глаз замылиться» и «парадокс Блаб-программиста» не делают понятнее то, что вы хотите сказать…
Ну извините, разжевывать еще подробнее нет желания.
По поводу количества строк. Скобки нет смысла считать. Так что там всего три строки. Но если вы хотите подсчитать скобки, то будет либо 4, либо 5, в зависимости от расположения открывающей. Но подобный подсчет выглядит еще более тупым занятием, чем попытки сравнить простоту и выразительность C-шного и C++ного кода.
Для демонстрации ошибочности вашего утверждения этого не требуется. Ну если хотите примеров того, что люди используют в работе, то посмотрите на какой-нибудь Q или J.
Можете пояснить, что конкретно вы имеете в виду?
Если вы вынуждены плотно заниматься сетевым программированием на чистом C и привыкли это делать так, как разработчики nginx, то у вас может просто «глаз замылиться». Ну и парадокс Блаб-программиста так же может иметь место быть.
У васт большой опыт написания программ на C, да?
Возможно, опыт написания программ у меня просто больше, чем у вас. Если вы говорили про 1997-ой год, то точно больше. Ну и C был одним из тех языков, с которых приходилось начинать. И ушел я с него при первой же возможности, т.к. даже в начале 90-х было понятно, что использовать C по собственной воле могут не только лишь все.
В моём коде вы предложили сократитить 2 повтора по 2 строки лямбдой в 5 строк и плюс по одной стоке на каждый повтор вместо двух.
Вообще-то три повтора. В двух из которых еще и нужно было функцию очистки явным образом вызывать. И если вы в лямбде насчитали пять строк, то у вас еще и проблемы со зрением.
Ваш код стал менее читаемым, длинее и дольше в написании…
Простота кода зависит не от языка, а от программиста.
Программы на brainfuck-е смотрят на вас с недоумением.
Тот же, неоднократно упоминаемы мною nginx, прекрасно читается.
Это может быть следствием профдеформации.
С++ позволяет стоить что угодно, хоть нормальный код, хоть ненормальный. Тогда как на C вы вынуждены педалить простыни однотипного кода, повторяя одно и тоже снова и снова. И оставляя контроль за всем (например, за временами жизни и очистку ресурсов) исключительно на разработчике.
Так что C++ определенно не самый удобный язык программирования, но противопоставлять ему C, на котором облегчить себе работу гораздо сложнее… Ну пусть каждый выбирает для себя.
Вы разговорами о деталях пытаетесь заболтать более важное: в C вы пишете простой код, который за счет своего объема становится сложным. Во всех аспектах сложный. Более того, его сложность только растет со временем, когда первоначальный автор перестает заниматься кодом и приходят другие люди, которые не помнят всех деталей. И которые могут забыть вызвать какую-нибудь функцию очистки в очередном if-е.
И вот такую «простоту» вы пытаетесь противопоставить растущей сложности C++.
Исключения здесь вообще не при чем. Ну вот совсем. В том же C++ вы можете объявить cor_http_t как unique_ptr с кастомным deleter-ом. И тогда ни вам, ни пользователям вашего кода не придется думать, кто и когда должен освобождать значение, возвращенное cor_http_new. В самом cor_http_new вы можете использовать локальные лямбды, для того, чтобы сократить количество писанины. Что-то вроде:
Тем не менее, даже в своей библиотеке вы вынуждены копипастить однотипные фрагменты кода и менять там всего по одной строчке (например, раз и два). Это как раз то, что более выразительные языки (вроде С++ или Rust) позволяют не делать, экономя время и силы разработчиков (и без лишних накладных расходов в run-time). Причем не столько во время написания кода, сколько во время сопровождения и развития.
У нас в чем цель? Получить максимально компактный код? Ну так вы его получили, но ценой введения еще одной сущности — compatingBy, про которую нужно знать.
Выигрыш ли это? А вот не факт. Если у вас вызовов std::sort с кастомными компараторами множество, то дополнительный comparingBy может себя оправдать. Если же std::sort вызывается всего один раз, то делать еще и comparingBy — это уже поклонение паттернам вместо здравого смысла.
Ну и повторюсь, поинт был вообще не в том. Но, видимо, это непонятно, поэтому начинается соревнование в утонченности на ровном месте.
Зачем же для этого разводить огород с дополнительными функциями и параметрами в виде лямб?
std::sort(std::begin(cnt), std::end(cnt),
[](const auto & a, const auto & b) {
const auto tie = [](const auto & x) { return std::tie(x.a, x.b, x.c); };
return tie(a) < tie(b);
});
Ну а сам предикат для sort-а выносить в отдельную функцию имеет смысл если он повторяется в коде несколько раз (если два раза, то это уже сигнал к рефакторингу). Но тогда еще нужно посмотреть, может в отдельную функцию следует вынести не один предикат, а весь sort с этим предикатом.
Для тех, кто исходит на известную субстанцию от iostreams, уже давно есть fmtlib. Которая, среди прочего, позволяет работать с пользовательскими типами, для которых определены операторы сдвига именно в std::ostream.
Другое дело, что к to_chars_result::ptr можно получить доступ даже если в to_chars_result::ec находится код ошибки… Вот это не есть хорошо. Какой-нибудь std::variant<char*, std::errc> был бы, наверное, уместнее. Но, вероятно, с точки зрения эффективности to_chars_result обходится дешевле.
Может имело бы смысл его записать в духе современного C++?
Как-то понадежнее будет.
Посмотрим на исходный тезис:
И смотрим на пример программы на J:
Вряд ли в этой программе есть что-то сложное, обычный такой quick sort. Сложным для восприятие ее сделал не программист, а синтаксис языка программирования.
Ну извините, разжевывать еще подробнее нет желания.
По поводу количества строк. Скобки нет смысла считать. Так что там всего три строки. Но если вы хотите подсчитать скобки, то будет либо 4, либо 5, в зависимости от расположения открывающей. Но подобный подсчет выглядит еще более тупым занятием, чем попытки сравнить простоту и выразительность C-шного и C++ного кода.
Если вы вынуждены плотно заниматься сетевым программированием на чистом C и привыкли это делать так, как разработчики nginx, то у вас может просто «глаз замылиться». Ну и парадокс Блаб-программиста так же может иметь место быть.
Возможно, опыт написания программ у меня просто больше, чем у вас. Если вы говорили про 1997-ой год, то точно больше. Ну и C был одним из тех языков, с которых приходилось начинать. И ушел я с него при первой же возможности, т.к. даже в начале 90-х было понятно, что использовать C по собственной воле могут не только лишь все.
Вообще-то три повтора. В двух из которых еще и нужно было функцию очистки явным образом вызывать. И если вы в лямбде насчитали пять строк, то у вас еще и проблемы со зрением.
Ну тогда понятно. Вопросов больше не имею.
Это может быть следствием профдеформации.
С++ позволяет стоить что угодно, хоть нормальный код, хоть ненормальный. Тогда как на C вы вынуждены педалить простыни однотипного кода, повторяя одно и тоже снова и снова. И оставляя контроль за всем (например, за временами жизни и очистку ресурсов) исключительно на разработчике.
Так что C++ определенно не самый удобный язык программирования, но противопоставлять ему C, на котором облегчить себе работу гораздо сложнее… Ну пусть каждый выбирает для себя.
И вот такую «простоту» вы пытаетесь противопоставить растущей сложности C++.
И писать нужно меньше, и вероятность допустить ошибку ниже, и даже думать больше не нужно. Нужно только перестать смотреть на C++ как на «C с чем-то».
Выигрыш ли это? А вот не факт. Если у вас вызовов std::sort с кастомными компараторами множество, то дополнительный comparingBy может себя оправдать. Если же std::sort вызывается всего один раз, то делать еще и comparingBy — это уже поклонение паттернам вместо здравого смысла.
Ну и повторюсь, поинт был вообще не в том. Но, видимо, это непонятно, поэтому начинается соревнование в утонченности на ровном месте.
Ну а сам предикат для sort-а выносить в отдельную функцию имеет смысл если он повторяется в коде несколько раз (если два раза, то это уже сигнал к рефакторингу). Но тогда еще нужно посмотреть, может в отдельную функцию следует вынести не один предикат, а весь sort с этим предикатом.
Однако, поинт вообще был в другом.
Но после утверждения: смысл продолжать дискуссию пропал.
Вообще подобные претензии к примеру уровня hello_world, это внушаить.
STL уже перестал быть Standard Template Library? Как давно?
вы бы лямбду в отдельную функцию вынесли бы? Ну SOLID и все такое…
Ну что уж тут поделать. У вас нет. А вот у огромного количества разработчиков есть.