О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.
А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?
Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.
Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.
Здравствуйте, Shmj, Вы писали:
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
S>Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается и я затрудняюсь ответить почему так.
1. GC. Это самое главное. Ему никакой замены нет. Умные указатели это полная шляпа. Rust ломает мозг. Псевдоумные указатели на счётчиках дают утечки на циклических структурах, хотя по эргономичности они, наверное, идут сразу после GС.
2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.
3. IDE. В Java IDE прекрасны. В C++ они ужасны. И это не исправить, это генетическое, из-за сложности языка.
4. Сопутствующий тулинг. В Java про него просто не думаешь. В С++ вечно какой-то гемор. Впрочем допускаю, что тут просто разница в опыте.
5. Простота языка. В Java очень редко возникают ситуации, где хочется навернуть шаблон на шаблон. В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка (т.к. стандартные убоги, см. выше), и в итоге прошёл месяц, а ты закопался в стандартах и думаешь, как же реализовать какой-нибудь оператор присваивания в execption-safe и thread-safe виде, хотя изначально тебе надо было просто HTTP запрос сделать и распарсить его ответ. С++ просто тебя заваливает какой-то лажей, не имеющей отношения к решаемой задаче.
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
На этих языках программы в большей степени "выполняются слева направо сверху вниз".
Меньше возможностей навертеть умонерастяжимых неотлаживаемых ребусов, которые понимает только их незаменимый автор (а остальные, кому понадобится сопровождать этот код, "пусть много трудятся впустую над их распутыванием, и выглядят тупыми перед начальством").
Строчки-цветочки, шмектор-коллектор, переписать неправильные стандартные контейнеры... Сколько раз это слышал, скучно уже. В твоем гите мухи в полете не дохнут? Все это скорее говорит о том, как ты прогаешь, и о том, что наработанных средств для решения задач из твоей же предметной области на плюсах у тебя просто нет. Ну так не берись на них прогать, делов то...
Здравствуйте, Shmj, Вы писали:
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
Да, есть, C++ это язык с "избыточным" функционалом. Слишком много парадигм требуют более квалифицированных программистов.
На C++ можно писать в стиле простейших скриптов вплоть до одного файла. А можно использовать обобщённое или объектно-ориентированное программирование. И ещё до кучи парадигм, структурное и процедурное. Хочешь модульное, пожалуйста, а не хочешь и не надо.
По алгоритмам так же. Можно использовать голые системные вызовы. А можно воспользоваться кроссплатформенными библиотеками. Можешь писать алгоритмы сам. Можешь воспользоваться готовыми. Хочешь ассемблерную вставку, она есть у меня. Хочешь множественное наследование, ну ты сам так решил.
Из-за этого возникает огромное количество возможных архитектур программ. Программисты с этим не справляются, и вот это уже вопрос по поводу обучения. Иначе говоря лёгкость других языков программирования и якобы сложность C++ это чистейшая иллюзия основанная на привычных для каждого языка методах обучения.
Это не проблема C++, это проблема тех людей у которых от возможностей разбегаются глаза и они начинают творить монстра.
В других языках тебе как бы намекают.
1. Вот у нас есть мощный встроенный фреймворк и он написан по таким вот правилам, и ты пиши так же. 2. Или вот тут все пишут в стиле скриптов, давай не робей, сразу пиши алгоритмы в скриптах.
А C++ тебе говорит, у нас тут миллион и три тележки возможностей, давай же используй, используй их все сразу!!!
Короче, программист C++, я тебя спас и в благородство играть не буду: выполнишь для меня пару заданий – и мы в расчете. Заодно посмотрим, как быстро у тебя башка после амнезии прояснится. А по твоей теме постараюсь разузнать. Хрен его знает, на кой ляд тебе эти парадигмы программирования сдались, но я в чужие дела не лезу, хочешь использовать, значит есть зачем.
- нельзя одной строчкой кода/одной командой подцепить стороннюю библиотеку. В JS/Python/Go и т.д. подключение сторонней библиотеки делается крайне просто и быстро. В плюсах с этим надо помучаться, т.к. нет единого подхода
— стандартная библиотека не настолько проста и удобна, как в других языках. Элементарная работа с файлами, путями; те же контейнеры могли бы быть более простыми в работе (типа как в Qt)
Здравствуйте, Osaka, Вы писали:
O>Меньше возможностей навертеть умонерастяжимых неотлаживаемых ребусов, которые понимает только их незаменимый автор (а остальные, кому понадобится сопровождать этот код, "пусть много трудятся впустую над их распутыванием, и выглядят тупыми перед начальством").
А в каких конкретно особенностях языка это выражается?
Здравствуйте, velkin, Вы писали:
V>На C++ можно писать в стиле простейших скриптов вплоть до одного файла. А можно использовать обобщённое или объектно-ориентированное программирование. И ещё до кучи парадигм, структурное и процедурное. Хочешь модульное, пожалуйста, а не хочешь и не надо.
V>По алгоритмам так же. Можно использовать голые системные вызовы. А можно воспользоваться кроссплатформенными библиотеками. Можешь писать алгоритмы сам. Можешь воспользоваться готовыми. Хочешь ассемблерную вставку, она есть у меня. Хочешь множественное наследование, ну ты сам так решил.
Вроде все это, кроме, разве что, обобщённого — есть и в других языка и погоды не строит. Получается основная фигня — в обобщенном, которого в простых языках нет в явном виде?
Здравствуйте, Shmj, Вы писали:
S>Вроде все это, кроме, разве что, обобщённого — есть и в других языка и погоды не строит. Получается основная фигня — в обобщенном, которого в простых языках нет в явном виде?
Проблема в неуправляемом обучении. Возьми Java и C#.NET, там есть готовые фреймворки из комплекта. А это считай готовая архитектура подражая которой можешь написать что-то не слишком убогое. Или у скриптовых языков пишешь в самом простом стиле и все довольны.
А что произойдёт при обучении C++, особенно при самостоятельном обучении. Человек открывает книги, спецификации, а там объектно-ориентированное программирование, но вообще без его правильного использования в виде готовых фреймворков.
А стандартная библиотека шаблонов C++ никак не научит писать код лучше. Обобщённое программирование по сути это уже следующий этап, когда из функций и классов генерируется код. И те кто это изобрели вначале программировали в Си стиле, это потом они уже дошли до новых понятий.
У меня сотни книг по программированию, большинство по C++. Там новичок не то, что не разберётся, он будет двигаться в другую сторону, изучать не алгоритмизацию, а абстракции.
Просто если тебе так уж интересно различия языков, возьми: Rosetta Code: Задачи.
abstract class Class1
{
public abstract void method1();
public int method2()
{
return 0;
}
}
C++
class Abs
{
public:
virtual int method1(double value) = 0;
virtual int add(int a, int b)
{
return a+b;
}
};
Java
abstract class Example {
protected int methodB(int value) {
return value + 100;
}
public abstract int methodC(int valueA, int valueB);
}
Примеры не эквивалентны, но видно же, что языки не различаются по сложности на порядки и даже на один порядок. Какие-нибудь мелкие проблемы раздуваются до невиданных высот. Ту же утечку памяти можно отследить с помощью Valgrind. В GNU/Linux он как и отладчик сразу встроен в Qt Creator, но надо же об этом постоянно писать.
Потому я говорю, что с моей точки зрения это всё иллюзия про то, что там что-то простое, а здесь что-то сложное. А политическая повесточка это уже другое дело. Я уже написал про это статью, Прикладные антисанкционные языки программирования, и даже обсудил.
Что ещё можно сказать? Хочешь используй то, а хочешь это. И да, новичков когда они только начинают что-то изучать пытаются подловить на простых лозунгах. Типа это просто, а это ух как сложно. А когда вскроется обман простым обзором кода, то уже уйдут годы на изучения нужных пропагандистам технологий.
Меня всегда прикалывали гуглы и майкрософты, которые построили свой бизнес на C/C++, но сами что только людям не втюхивали.
Здравствуйте, Shmj, Вы писали:
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?
Потому что C++ имеет больше возможностей делать одно и то же. Причем часть способов устарел, часть тормозит, а часть ведет к UB. И заранее не скажешь в какую категорию попадает то, что пишешь сейчас.
Сможете сходу сказать какой правильный способ инициализации объектов и какой конструктор для этого надо написать?
S>Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.
Ну конечно не решили, скорее даже ухудшили. Если в голом C можно было передать указатель на структуру и копию структуры, то в C++ можно передать: копию объекта, указатель, ссылку, smart_ptr, ссылку на smart_ptr, указатель на smart_ptr, rvalue ссылку, rvalue ссылку на smart_ptr. Ничего не забыл?
И, кстати, ссылки, как и указатели не безопасны. Подробнее в видео https://youtu.be/qeiRGbYCD-0
S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.
Прикладному программисту почти не надо писать шаблоны, а если надо, то спасает typedef. А вот при ошибке использования шаблонных функций и объектов даже из STL текст ошибки получается ну очень невнятный, даже сейчас в 2023, что усложняет поиск ошибок.
а) язык реально очень большой.
б) стандартная библиотека напротив сильно маленькая.
Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
Это когда практически все системы стали с сетевым взаимодействием.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование S>И славатехоспади!
Не...
В каждой новой конторе что-то не стандартное.
Да и много чего приходится стороннего брать.
А в Go — из коробки и работает везде одинаково.
На мой взгляд это Go+++, а не C++ S>Достаточно истории с добавлением в стандарт std::unordered_map.
Ну, забыли...
В запарке при сдаче релиза и такое бывает
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>В каждой новой конторе что-то не стандартное.
Это либо следствие древнего происхождения (и тогда это просто так не переписать), либо следствие специфических задач, под которые пришлось делать свой инструмент, возможно, заточенный не только под задачу, но и под конкретную систему (и тогда это точно на что-то из stdlib не переписать).
LVV>А в Go — из коробки и работает везде одинаково.
Одинаково тормознуто? То-то на пике хайпа вокруг Rust-а появлялись статьи о том, как узкие места Go на Rust-е расшивают.
LVV>Ну, забыли... LVV>В запарке при сдаче релиза и такое бывает
Скорее всего, там была не запарка, а сознательное решение обеспечить сохранность итераторов при модификации, чтобы std::unordered_map мог быть прямой заменой std::map. В результате убили главное преимущество хэш-таблиц и получили рекомендацию не использовать std::unordered_map там, где требуется производительность.
Заиметь в стандарте какую-то реализацию reactor-а или proactor-а для сетевого IO, для которого будет аналогичная рекомендация "не использовать там, где требуется производительность"... Ну такое себе.
В прочем, пока еще есть шансы, что Networking TS следом за Executors TS до стандарта доедут. Не в C++23, так в C++26, ну или в C++29
Здравствуйте, LaptevVV, Вы писали:
LVV>а) язык реально очень большой.
Тут да. И еще такая особенность — язык очень символьный.
Вот в паскале комменты блочные обозначались символами {}. И представьте — чел. привыкает что в {} написано что-то не важное, т.е. то что вообще не исполняется — а тут ему нужно на эти ранее малозначимые символы сконцентрировать все внимание.
А так же контекст символов. Вот звездочка — это или умножение или декларация указателя или же разыменование. Это очень очень сложно удержать в голове и парсить, практически головоломка.
Не говорю уже про шаблоны шаблонов шаблонов шаблонов.
LVV>б) стандартная библиотека напротив сильно маленькая. LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование LVV>Это когда практически все системы стали с сетевым взаимодействием.
А вот ни такая уж и маленькая — хрен запомнишь. Целые книги по ней. Сетевого программирования нет, а овердофига других вещей есть.
Здравствуйте, vsb, Вы писали:
vsb>2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.
Это субъективно (точнее — из-за отсутствия опыта работы с STL).
vsb>3. IDE. В Java IDE прекрасны. В C++ они ужасны. И это не исправить, это генетическое, из-за сложности языка.
Дело привычки — от MS Visual Studio до Qt Creator — все они не хуже того же Eclipse или IDEA
vsb>5. Простота языка.
Тут соглашусь — Java проще, но C++ значительно универсальнее
vsb>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...
Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"
Здравствуйте, LaptevVV, Вы писали:
LVV>а) язык реально очень большой. LVV>б) стандартная библиотека напротив сильно маленькая. LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
Никогда не понимал чего все так дрочат вприсядку на стандартную либу.
Возможно меня опыт системщика приучил что всё всегда делать надо исключительно на системных примитивах ибо всегда во главу угла выходил фокус на максимальную оптимальность под конкретной системой а не чтоб вышло что то обобщённое, что одинаково (плохо) работает на разных платформах.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Никогда не понимал чего все так дрочат вприсядку на стандартную либу. CC>Возможно меня опыт системщика приучил
Да, это профдеформация.
На C++ все еще делают приложения в стиле "быстренько собрать прототип, посмотреть что получится, а затем уже доводить до ума". И акцент ставиться на "быстренько собрать", а не на какие-то другие факторы (типа ресурсоемкости, производительности, надежности). Причем еще и делают это люди, которым следовало бы руки основательно так вправить перед тем, как до C++ допускать (а еще бывают персонажи вроде ТС-а).
В таких условиях наличие готового "искаропки" перевешивает все остальное.
Се ля ви.
PS. Почему при таких вводных выбирают именно C++ -- это отдельный вопрос. Иногда потому, что уже есть какой-то кусок функциональности (например, анализ видео) вокруг которого нужно что-то собрать. Т.к. кусок уже на C++, то проще продолжать на C++, чем оборачивать это в какой-нибудь условный Python.
Здравствуйте, Shmj, Вы писали:
S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело. S>Как вы думаете?
С++ требует довольно большого времени на вхождение. При прочих равных, раза в 2-3 дольше. Причин много
1. область применения — требует бОльше знаний
2. огромное количество механик в С++, которые большей частью низкоуровневые
3. отдельная проблема это темплейты — сам по себе полноценный язык
4. проектов, где только хороший С++, ничтожное количество. Типичный код это С++ пополам с Си. Может это мне так везёт, не знаю.
5. последствия ошибок достаточно разрушительные в силу отсутствия механизмов изоляции
6. ручная работа с памятью, многозадачностью итд итд
LVV>>б) стандартная библиотека напротив сильно маленькая. LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование LVV>>Это когда практически все системы стали с сетевым взаимодействием. S>А вот ни такая уж и маленькая — хрен запомнишь. Целые книги по ней. Сетевого программирования нет, а овердофига других вещей есть.
Маленькая
Сравни с Java/C#/Go
Очень многих вещей, которые там есть, в С++ нет.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, AlexGin, Вы писали:
AG>Это субъективно (точнее — из-за отсутствия опыта работы с STL).
Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++. Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
vsb>>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка... AG>Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"
Если мне не изменяет память, я эту книгу читал году в 2005.
Здравствуйте, vsb, Вы писали:
vsb>Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.
Собственно, на фоне того, как определять собственные formatter-ы для fmtlib, operator<< для вывода собственного типа до сих по выглядит /мега/удобно.
vsb>>>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...
Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?
Здравствуйте, Shmj, Вы писали:
S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?
Да. Потому что кресты это только про язык. а перечисленное это фрэймворки.
Но! Есть адекватная замена крестам https://codeberg.org/kiesel-js/kiesel
zig run core.zig
Здравствуйте, so5team, Вы писали:
S>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?
Например чтобы использовать человеческий UTF-8. А не непойми что.
Здравствуйте, vsb, Вы писали:
S>>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?
vsb>Например чтобы использовать человеческий UTF-8. А не непойми что.
Ну это строки. А массивы-то зачем?
PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?
Здравствуйте, so5team, Вы писали:
S>>>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?
vsb>>Например чтобы использовать человеческий UTF-8. А не непойми что.
S>Ну это строки. А массивы-то зачем?
Уже не помню.
S>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?
Не пользовался им. Это же что-то большое на мегабайты? Мне от строк нужна итерация по кодепоинтам. Всякие заумности обычно не нужны. UTF-8 достаточно простой формат и реализуется в несколько десятков строк кода. Если там какие-нибудь сортировки по национальным символам будут нужны, видимо да, ICU нужен будет. А там свой класс строк есть?
Здравствуйте, vsb, Вы писали:
S>>Ну это строки. А массивы-то зачем?
vsb>Уже не помню.
Тогда это похоже на "для красного словца"
S>>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?
vsb>Не пользовался им. Это же что-то большое на мегабайты? Мне от строк нужна итерация по кодепоинтам. Всякие заумности обычно не нужны. UTF-8 достаточно простой формат и реализуется в несколько десятков строк кода. Если там какие-нибудь сортировки по национальным символам будут нужны, видимо да, ICU нужен будет. А там свой класс строк есть?
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, AlexGin, Вы писали:
AG>>Это субъективно (точнее — из-за отсутствия опыта работы с STL).
vsb>Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++.
Мы (вроле как) о C++ и об STL, а не о других языках. Да, в .NET и в Java сделано иначе. Но это не означает, что в STL хуже.
vsb>Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
Всё логично — мы можем двигать биты, и можем двигать информацию на вывод. Всё логично и просто.
AG>>Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"
vsb>Если мне не изменяет память, я эту книгу читал году в 2005.
Это старая редакция, теперь уже есть по C++11 (и выше).
Здравствуйте, CRT, Вы писали:
S>>По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.
CRT>Для выводы обычных строк, символов, чисел printf удобней
Здравствуйте, so5team, Вы писали:
S>... S>Скорее всего, там была не запарка, а сознательное решение обеспечить сохранность итераторов при модификации, чтобы std::unordered_map мог быть прямой заменой std::map. В результате убили главное преимущество хэш-таблиц и получили рекомендацию не использовать std::unordered_map там, где требуется производительность.
А где про это можно почитать? Очень интересно. У нас наоборот тащат везде unordered_map, типа он быстрее (понятно что в идеальных случаях на больших контейнерах — да).
Здравствуйте, SaZ, Вы писали:
SaZ>А где про это можно почитать? Очень интересно. У нас наоборот тащат везде unordered_map, типа он быстрее (понятно что в идеальных случаях на больших контейнерах — да).
Здравствуйте, so5team, Вы писали:
CRT>>Для выводы обычных строк, символов, чисел printf удобней
S>Расскажите эту байку кому-нибудь помоложе.
Конечно, ведь
Здравствуйте, Shmj, Вы писали:
S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.
(Verse 1)
Yo, listen up, here's a tale to tell,
'Bout this beast of a language, that we know so well.
C++, we've been through hell,
Complex syntax — ain't it a hard sell?
Chasing bugs through the night, pointer's out of sight,
Memory leaks, undefined behavior, giving us a fright.
Templates and exceptions, got our heads in a spin,
You've got to be an expert to even begin.
(Chorus)
'Cause C++'s like a riddle in the dark,
A million ways to compile, but where do you start?
Complexity stacked high, like a work of art,
Coding in C++, tearing minds apart.
(Verse 2)
Overload resolution, what a convolution,
Endless compile times — ain't no resolution.
Type safety's compromised, casting wide and far,
You can shoot yourself in the foot, don't know where you are.
Got legacy code, outdated and old,
Backwards compatibility, a stranglehold.
With header files and macros, what a bitter pill,
C++ got us chasing that overkill.
(Chorus)
'Cause C++'s like a journey through the abyss,
An intricate dance, hit or miss.
Ain't no guiding star, no state of bliss,
Coding in C++, it's a game of risk.
(Outro)
Yeah, we keep grindin', through the noise and clutter,
But the pains of C++, make us stutter.
It's a powerful tool, no other can smother,
But, oh C++, you're a difficult mother.
Здравствуйте, vsb, Вы писали:
vsb>Кстати STL далеко не самое ужасное, что есть в C++.
STL это не в С++, это для С++. Никто им пользоваться не заставляет.
vsb>Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
А этим извращением разве кто то всё ещё пользуется?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
vsb>>Кстати STL далеко не самое ужасное, что есть в C++. CC>STL это не в С++, это для С++. Никто им пользоваться не заставляет.
С момента фиксации STL в стандарте это C++.
CC>А этим извращением разве кто то всё ещё пользуется?
Да. За пределами яблочного ядра есть жизнь. А у вас нет прерогативы на единственно правильное мнение.
Здравствуйте, CreatorCray, Вы писали:
S>>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU? CC>Ты не поверишь но да!
Поверю, сам простую работу с UTF-8 реализовывал. Но там на уровне проверки корректности последовательности или трансляции из UCS-16 в UTF-8 на Windows.
Если же нужно, например, регистронезависимую сортировку сделать, то лучше уж ICU задействовать.
Здравствуйте, CreatorCray, Вы писали:
S>>это был прям таки прорыв. CC>Разишо канализации.
Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.
Всё ещё мрак и кошмар.
S>Во-первых, примеры не эквивалентны. Вариант с printf-ом требует еще одну строчку с вызовом fflush.
Это зависит от того что именно стоит за printf.
То, что в дефолтном рантайме лучше не использовать, ибо оно Сишное, а потому сильно ограниченное.
Речь скорее за printf-like синтаксис вывода.
S>Во-вторых, давайте пройдемся по тонкому льду:
С появлением вариадиков я вообще могу написать вот такое:
crprintf (L"%s %f %i", 0.5, 123, -PI);
И оно напечатает "0.5 123 -3"
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.
В плюсах можно было. Я делал типобезопасный printf-like вывод через использование оператора запятая.
С появлением вариадиков тут же переписал на них, стало на порядок удобнее.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>С момента фиксации STL в стандарте это C++.
Всё, что может быть полностью написано на С++ не является частью языка.
Что бы там себе теоретики не фантазировали.
CC>>А этим извращением разве кто то всё ещё пользуется? S>Да. За пределами яблочного ядра есть жизнь.
Выдыхай, бобёр! Хочешь пользоваться отвратительно спроектированным интерфейсом — ветер в спину.
S> А у вас нет прерогативы на единственно правильное мнение.
У меня есть прерогатива на собственный опыт, от ядер до финансового софта.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
vsb>Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++. Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
Это ты valarray еще не трогал.
Тем не менее, это можно было сделать еще в "Си с классами".
S>>Во-первых, примеры не эквивалентны. Вариант с printf-ом требует еще одну строчку с вызовом fflush. CC>Это зависит от того что именно стоит за printf.
Речь про сишный printf (fprintf, sprintf).
CC>С появлением вариадиков я вообще могу написать вот такое: CC>
CC>crprintf (L"%s %f %i", 0.5, 123, -PI);
CC>
CC>И оно напечатает "0.5 123 -3"
Во-первых, речь не про вариадики.
Во-вторых, как с помощью мифического crprintf вывести объект собственного типа?
Здравствуйте, CreatorCray, Вы писали:
S>>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам. CC>В плюсах можно было.
Давайте конкретнее: как?
CC>Я делал типобезопасный printf-like вывод через использование оператора запятая.
Объекты пользовательских типов посредством чего выводились?
CRT>>Для выводы обычных строк, символов, чисел printf удобней S>Расскажите эту байку кому-нибудь помоложе.
Те кто помоложе часто любят совать пальцы в розетки, когда взрослеют, то понимают, что не нужно это делать.
Здравствуйте, CreatorCray, Вы писали:
S>>С момента фиксации STL в стандарте это C++. CC>Всё, что может быть полностью написано на С++ не является частью языка. CC>Что бы там себе теоретики не фантазировали.
Частью языка является то, что зафиксировано в стандарте.
Чтобы там практики с "прерогативой на собственный опыт" не фантазировали.
CC>>>А этим извращением разве кто то всё ещё пользуется? S>>Да. За пределами яблочного ядра есть жизнь. CC>Выдыхай, бобёр! Хочешь пользоваться отвратительно спроектированным интерфейсом — ветер в спину.
Предложите лучше.
А да, у вас же есть мега альтернатива fmtlib, которую никто никогда не увидит.
S>> А у вас нет прерогативы на единственно правильное мнение. CC>У меня есть прерогатива на собственный опыт, от ядер до финансового софта.
Если включить мозги (хотя мозги вряд ли могли бы позволить ЧСВ раздуться до такого уровня), то можно увидеть, что ваш опыт у вас никто не отнимает, а вот над желанием высказать единственно правильное мнение скоро будут откровенно стебаться.
Здравствуйте, so5team, Вы писали:
CC>>С появлением вариадиков я вообще могу написать вот такое: CC>>
CC>>crprintf (L"%s %f %i", 0.5, 123, -PI);
CC>>
CC>>И оно напечатает "0.5 123 -3"
Кстати говоря, за то, что дабл выводится там, где требуется строка, а вещественное значение неявно преобразуется к целому (да и наоборот), руки нужно отрывать. Подобные вещи должны приводить к ошибкам, желательно времени компиляции.
Здравствуйте, so5team, Вы писали:
S>Тем не менее, это можно было сделать еще в "Си с классами".
Можно было сделать удобнее.
S>Речь про сишный printf (fprintf, sprintf).
А зачем в плюсах упорно продолжать пользоваться сишными функциями?
S>Во-первых, речь не про вариадики.
Речь про С++, в котором уже давно есть вариадики.
S>Во-вторых, как с помощью мифического crprintf вывести объект собственного типа?
А где в исходнои примере ("std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;") объект собственного типа?
Впрочем если припрёт то всё что надо это определить функцию в namespace которая будет принимать контекст и const& на нужный тип и внутри сама форматировать его в строку.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>>>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам. CC>>В плюсах можно было.
S>Давайте конкретнее: как?
Да так же. Просто не через operator<<
S>Объекты пользовательских типов посредством чего выводились?
Мне юзерская расширяемость нафиг не надо была, задача была полностью заменить printf. Впрочем любой новый тип добавляется туда элементарно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Частью языка является то, что зафиксировано в стандарте.
Частью именно что языка является то, для чего надо поддержка компилятором.
Всё остальное — библиотечный код. Который выбрасывается или заменяется без потери функциональности самого языка.
CC>>Выдыхай, бобёр! Хочешь пользоваться отвратительно спроектированным интерфейсом — ветер в спину. S>Предложите лучше.
Да вон даже в стандарте std::format наконец предложили. Только он всё равно какой то корявый у них вышел.
S>А да, у вас же есть мега альтернатива fmtlib, которую никто никогда не увидит.
Есть, работает замечательно. Причём ещё и заметно быстрее fmtlib, как то померял интересу ради.
Причём что крайне полезно — с бОльшего printf-like совместимо, что упрощает перенос всякого старого кода.
S>мозги вряд ли могли бы позволить ЧСВ раздуться до такого уровня
Божеж мой, да я "такое же быдло как и вы" (С)
Узбагойся и перестань пытаться что то там читать между строк. Там ничего не написано.
S>а вот над желанием высказать единственно правильное мнение
Похоже "единственно правильное" (tm) пытаешься отстаивать ты.
Я же высказываю просто своё мнение.
S>скоро будут откровенно стебаться.
Я давно уже стебусь.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>дабл выводится там, где требуется строка
А что должно выводиться? Какое будет строковое представление для double?
S> а вещественное значение неявно преобразуется к целому
Выводится тот тип, что был попрошен в форматной строке, ибо она задаёт отображение.
S> Подобные вещи должны приводить к ошибкам, желательно времени компиляции.
Форматная строка ж не обязательно фиксирована в момент компиляции.
И если там что то было неправильно, то желательно в логах увидеть хоть какое то разумное значение а не просто "нишмагла".
Впрочем у меня таки ругается если в тот же "%i" передать строку.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.
Мне иногда кажется, что в Villain Pub собрались собрались самые ужасные суперзлодеи — Палпатин, Джокер, Танос, Волдеморт и Александр Александрович Степанов — и стали её проектировать:
— А давай вместо Add() назовём метод push_back()?
— Давай! И ещё отделим алгоритмы от данных, вынеся их в отдельные классы! И пусть remove не remov'ит, а erase — не eras'ит.
— MWAHAHAHAHA! Ты просто гений злодейства!!!
S>>Речь про сишный printf (fprintf, sprintf). CC>А зачем в плюсах упорно продолжать пользоваться сишными функциями?
Затем, что речь идет о моменте выхода C++ в мир, когда выбор был между сишными функциями и изобретением чего-то другого. Изобрели iostream и перегрузку operator<<. С перегрузкой оператора получилось нормально, практично (если не обращать внимания на вопли пуристов из разряда "да как они посмели поступить так с оператором битового сдвига"). С iostream реально перемудрили, имхо. Но претензии почему-то к operator<<.
S>>Во-первых, речь не про вариадики. CC>Речь про С++, в котором уже давно есть вариадики.
Речь про прошлое, в котором в C++ шаблонов не было, не говоря уже про вариадики.
S>>Во-вторых, как с помощью мифического crprintf вывести объект собственного типа? CC>А где в исходнои примере ("std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;") объект собственного типа?
CC>Впрочем если припрёт то всё что надо это определить функцию в namespace которая будет принимать контекст и const& на нужный тип и внутри сама форматировать его в строку.
Ну вот в fmtlib пошли по этому пути, только там не функцию, а специализацию шаблона нужно определять. И кода нужно понаписать поболее, чем в случае с operator<<
Здравствуйте, CreatorCray, Вы писали:
S>>>>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам. CC>>>В плюсах можно было.
S>>Давайте конкретнее: как? CC>Да так же. Просто не через operator<<
Ну так как?
Напомню, что в C++ образца 1983-го года не было шаблонов. И единственный способ сделать функцию с переменным количеством аргументов был в использовании сишных va_args.
Можно было, наверное, сделать функцию print(stream, arg), которую можно было бы перегружать для пользовательских типов. Но тогда вместо:
Что ничуть не лучше. По крайней мере точно нашлись бы люди, которые от этого плевались бы не меньше, чем другие до сих пор плюются от operator<<.
S>>Объекты пользовательских типов посредством чего выводились? CC>Мне юзерская расширяемость нафиг не надо была, задача была полностью заменить printf.
Здравствуйте, CreatorCray, Вы писали:
S>>Частью языка является то, что зафиксировано в стандарте. CC>Частью именно что языка является то, для чего надо поддержка компилятором.
Можно еще 100 раз это повторить, но факт остается фактом: в стандарте C++ определена стандартная библиотека языка. Ее принято называть STL. Следовательно, STL является частью языка.
CC>Всё остальное — библиотечный код. Который выбрасывается или заменяется без потери функциональности самого языка.
То, что кто-то может пользоваться в своей работе ограниченным подмножеством языка не меняет вышеупомянутого факта.
CC>>>Выдыхай, бобёр! Хочешь пользоваться отвратительно спроектированным интерфейсом — ветер в спину. S>>Предложите лучше. CC>Да вон даже в стандарте std::format наконец предложили. Только он всё равно какой то корявый у них вышел.
Так в том-то и фокус: однозначно лучше не получилось.
S>>А да, у вас же есть мега альтернатива fmtlib, которую никто никогда не увидит. CC>Есть, работает замечательно. Причём ещё и заметно быстрее fmtlib, как то померял интересу ради. CC>Причём что крайне полезно — с бОльшего printf-like совместимо, что упрощает перенос всякого старого кода.
Как только вы ее выпустите в свет, обязательно найдется другой CreatorCray, которой обложит вашу библиотеку (а может и вас, как проектировщика) неблагозвучными эпитетами. Так что ваша библиотека замечательна лишь пока вы ей пользуетесь в очень узком кругу. Стоит ей выйти за пределы этого круга, как в ней обязательно обнаружатся фатальные недостатки.
S>>а вот над желанием высказать единственно правильное мнение CC>Похоже "единственно правильное" (tm) пытаешься отстаивать ты.
Т.е. эпитеты "отвратительно спроектированный интерфейс" и "извращение" употребляете вы, а единственно правильное отстаиваю я? Ну OK.
Здравствуйте, CreatorCray, Вы писали:
S>>дабл выводится там, где требуется строка CC>А что должно выводиться?
Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.
S>> а вещественное значение неявно преобразуется к целому CC>Выводится тот тип, что был попрошен в форматной строке, ибо она задаёт отображение.
Округлять вещественное до целого можно по разному, пользователь должен задавать это явным способом, неявных преобразований в C++ и так выше крыши, к сожалению (хотелось бы сильно поменьше этих самых неявных преобразований).
S>> Подобные вещи должны приводить к ошибкам, желательно времени компиляции. CC>Форматная строка ж не обязательно фиксирована в момент компиляции.
Значит должна быть ошибка в run-time.
PS. Это все к разговору о том, что у разных людей разные требования и взгляды на то, как "нормально".
vsb>>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.
S>И получаем ООП головного мозга на ровном месте.
Я бы не назвал это ООП. Ну в любом случае мне такой подход нравится куда больше, чем шаблоны. Хотя бы потому, что он нормально работает с раздельной компиляцией.
Здравствуйте, vsb, Вы писали:
vsb>>>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.
S>>И получаем ООП головного мозга на ровном месте.
vsb>Я бы не назвал это ООП.
И что же это? Какой-то деградировавший ФП?
vsb>Ну в любом случае мне такой подход нравится куда больше, чем шаблоны. Хотя бы потому, что он нормально работает с раздельной компиляцией.
Здравствуйте, so5team, Вы писали:
vsb>>>>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.
S>>>И получаем ООП головного мозга на ровном месте.
vsb>>Я бы не назвал это ООП.
S>И что же это? Какой-то деградировавший ФП?
ООП в моём понимании это наследование классов с данными. Реализация интерфейса на ООП не тянет. Я не знаю, как её назвать, но к примеру в Go или Rust эта модель есть, а полновесного ООП нет. Наверное можно назвать это ООП здорового человека.
vsb>>Ну в любом случае мне такой подход нравится куда больше, чем шаблоны. Хотя бы потому, что он нормально работает с раздельной компиляцией.
S>У вас C++ные проекты компилируются по 8 часов?
У меня травма детства, когда я видел C++ проект от "деда", который компилировался за долю секунды и при этом в нём было несколько десятков тысяч строк. Там использовалась только C-шная библиотека и шаблоны очень редко. Когда простой хелло-ворлд с STL компилируется на железе в 5 раз мощней — несколько секунд, я понимаю, что в раздельной компиляции есть свой смысл. И C++ с его подходом с повсеместными шаблонами, возможно, ушёл немножко не туда.
Впрочем может быть современные компиляторы научились компилировать шаблоны один раз? Плохо представляю, как это может работать, но вроде были какие-то precompiled headers, которые я так и не смог "завести".
CRT>>Для выводы обычных строк, символов, чисел printf удобней CC>printf-like — да. Но сам сишный printf таки нет.
сишный printf с его языком форматирования гораздо удобней чем cout, но опаснее. Но я про удобство.
Хотя некоторые компиляторы умеют проверять аргументы на соответствие формату в printf
Здравствуйте, CRT, Вы писали:
CRT>>>Для выводы обычных строк, символов, чисел printf удобней CC>>printf-like — да. Но сам сишный printf таки нет.
CRT>сишный printf с его языком форматирования гораздо удобней чем cout, но опаснее. Но я про удобство. CRT>Хотя некоторые компиляторы умеют проверять аргументы на соответствие формату в printf
Вроде в C++ уже должно хватать возможностей, чтобы реализовать интерфейс printf безопасно? Ну может не с ошибкой компиляции, но по крайней мере без порчи стека и прочих спецэффектов при неправильном формате.
Здравствуйте, vsb, Вы писали:
vsb>ООП в моём понимании это наследование классов с данными. Реализация интерфейса на ООП не тянет.
Тем не менее. Здесь классический ООП-ный runtime-полиморфизм.
А если добавить, что для printable потребуется не один виртуальный метод, а два (первый нужен для хранения результатов разбора форматной строки), то выяснится, что в наследнике printable будут какие-то данные, а это уже и инкапсуляция в придачу.
Посему это именно что ООП.
vsb>У меня травма детства, когда я видел C++ проект от "деда", который компилировался за долю секунды и при этом в нём было несколько десятков тысяч строк. Там использовалась только C-шная библиотека и шаблоны очень редко. Когда простой хелло-ворлд с STL компилируется на железе в 5 раз мощней — несколько секунд, я понимаю, что в раздельной компиляции есть свой смысл. И C++ с его подходом с повсеместными шаблонами, возможно, ушёл немножко не туда.
C++ пока еще очень сдерживает модель компиляции, унаследованная из C: одни и те же заголовочные файлы приходится парсить помногу раз. Повсеместное пришествие поддержки модулей из C++20 должно улучить ситуацию. Ускорить где-то на 1/3
PS. Цифра 1/3 взята, по сути, с потолка. Когда-то замерял затраты компилятора на обработку cpp-файла с активным использованием шаблонов. Там стадия препроцессинга как-раз треть занимала. Остальное -- это кодогенерация после инстанциирования шаблонов.
Здравствуйте, CRT, Вы писали:
S>>Напомню, что в C++ образца 1983-го года не было шаблонов.
CRT>а в образце 1991 были
Ну так operator<< для вывода в iostream появился не в 1991-ом, а гораздо раньше.
CRT>а STL в 1994 появилась
В 1992-1993.
CRT>в конце 90-х шаблоны были довольно прилично развиты.
Смотря где. В VC++ нормальная поддержка шаблонов из C++98 появилась только в VS2003. А export template вообще всего в одном компиляторе был, который не имел широкого применения.
CRT>а этот format() когда появился?
После принятия C++11, т.к. ему вариадики нужны были.
До fmtlib были другие инструменты, тот же Boost.Format, который для C++98 был написан.
Здравствуйте, Shmj, Вы писали:
S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?
Есть. C++ расчитан на мифических программистов которые никогда не допускают ошибок. А другие языки наоборот на то что программисты могут и будут ошибаться.
Здравствуйте, so5team, Вы писали:
S>А если добавить, что для printable потребуется не один виртуальный метод, а два (первый нужен для хранения результатов разбора форматной строки)
Не понял. Предполагается, что метод print просто печатает текущий объект в output_stream посимвольно.
Более простой вариант — сделать вместо этого метод to_string(). Но тут придётся между печатью хранить строку. В большинстве языков делают именно так, хотя мне это кажется не оптимальным и даже менее удобным для реализации.
Т.е. используется это так: printf("%s", my_obj). И printf уже вызовет у my_obj метод print, которым он напечатает себя в stdout.
Использовать что-либо кроме %s для печати своих объектов мне кажется странной идеей, но можно и это сделать, просто в метод print передавать вторым парамметром запрошенный модификатор форматирования. Наверное это может иметь смысл для своих числовых типов.
Здравствуйте, vsb, Вы писали:
vsb>Т.е. используется это так: printf("%s", my_obj). И printf уже вызовет у my_obj метод print, которым он напечатает себя в stdout.
Посмотрите как поддержка пользовательских типов сделана в fmtlib: https://fmt.dev/10.0.0/api.html#formatting-user-defined-types
Там требуется два метода: parse (в принципе, он опциональный, если нет собственных требований к форматной строке) и format.
vsb>Использовать что-либо кроме %s для печати своих объектов мне кажется странной идеей, но можно и это сделать, просто в метод print передавать вторым парамметром запрошенный модификатор форматирования.
Два разных метода позволяют разделить парсинг форматной строки и собственно формат. Тем самым, если парсинг осуществляется в compile-time, то и всякие ошибки с форматом выявляются именно там.
Выделенное жирным является сутью этой дискуссии: кому-то кажется одно, но с большой долей вероятности этот кто-то даже не представляет, что кажется и что нужно другим людям.
Здравствуйте, CRT, Вы писали:
S>>Смотря где. В VC++ нормальная поддержка шаблонов из C++98 появилась только в VS2003.
CRT>Тоже давным давно уже
При этом operator<< как были введены в C++ начала 1980-х, так и работали.
CRT>>>а этот format() когда появился?
S>>После принятия C++11, т.к. ему вариадики нужны были.
CRT>а cppreference.com пишет C++20
CRT>в стандарте его не было
Речь не про std::format, а про fmtlib из которой std::format и появился. Эта самая fmtlib стала возможной только после принятия C++11.
CRT>>а cppreference.com пишет C++20
CRT>>в стандарте его не было
S>Речь не про std::format, а про fmtlib из которой std::format и появился. Эта самая fmtlib стала возможной только после принятия C++11.
Так я о чем и говорю что в стандарт они его добавили недавно. То есть частью языка (если считать стандартные библиотеки частью языка), он стал совсем недавно
Здравствуйте, so5team, Вы писали:
S>Выделенное жирным является сутью этой дискуссии: кому-то кажется одно, но с большой долей вероятности этот кто-то даже не представляет, что кажется и что нужно другим людям.
На самом деле у меня своего мнения не так уж много. Мне пришлось поработать с разными языками, и поэтому я своё мнение лишь складываю исходя из сравнения того, как похожие вещи сделаны в разных языках.
Поэтому когда я говорю, что мне кажется, что использовать что-то кроме %s для пользовательских типов не нужно, в основном это вызвано тем, что я не знаю ни одного языка, где это было бы. В Java есть String.format, в нём %s вызывает toString() у пользовательского объекта. В Objective C есть %@, там тоже какой-то подобный метод. В Go то же самое. И если вдруг понадобится какой-то нестандартный метод для форматирования, достаточно просто написать метод to_custom_string(), возвращающий строку или же написать объект-обёртку, если этот объект такой гигантский, что промежуточная строка ну никак не подходит.
Допускаю, что на этих языках есть люди, которые страшно страдают от того, что не могут указать свой формат для форматирования прямо в строке. Но мне кажется, что таких людей мало. А людей, которые продуктивно используют простую и понятную систему — много.
Здравствуйте, CRT, Вы писали:
CRT>Так я о чем и говорю что в стандарт они его добавили недавно. То есть частью языка (если считать стандартные библиотеки частью языка), он стал совсем недавно
Э... А как это меняет тот факт, что в 1980-х в C++ смогли сделать только безопасный по типам operator<<?
Здравствуйте, vsb, Вы писали:
vsb>Поэтому когда я говорю, что мне кажется, что использовать что-то кроме %s для пользовательских типов не нужно, в основном это вызвано тем, что я не знаю ни одного языка, где это было бы.
Это логика из категории "если миллионы мух"...
C++ очень сильно отличается от Java или Objective C.
Например, в нем ООП не обязательно.
Следовательно, нет какой-то вершины иерархии, вроде Object, в которую можно было зафигачить toString.
Кроме того, в C++ многие упарываются по производительности и накладным расходам.
И если навязать подход, когда парсинг только в run-time, для вывода нужно вызывать виртуальный toString, а этот toString еще и вернет std::string с динамической аллокацией внутри, то подобное решение очень быстро закидают гнилыми помидорами.
Здравствуйте, so5team, Вы писали:
vsb>>Поэтому когда я говорю, что мне кажется, что использовать что-то кроме %s для пользовательских типов не нужно, в основном это вызвано тем, что я не знаю ни одного языка, где это было бы.
S>Это логика из категории "если миллионы мух"...
Ну как бы и тема про то, почему на других языках писать комфортнее.
S>C++ очень сильно отличается от Java или Objective C. S>Например, в нем ООП не обязательно. S>Следовательно, нет какой-то вершины иерархии, вроде Object, в которую можно было зафигачить toString.
Я уже писал пример, при котором вершина иерархии не нужна. Я вообще не считаю, что Object.toString() было правильным решением. Дефолтная реализация бесполезная, а если уж свою реализацию делать, можно и интерфейс реализовать. Да и печатать удобней в поток, а не в строку.
S>Кроме того, в C++ многие упарываются по производительности и накладным расходам.
Это обычно прямо противоречит "писать проще и комфортнее".
S>И если навязать подход, когда парсинг только в run-time, для вывода нужно вызывать виртуальный toString, а этот toString еще и вернет std::string с динамической аллокацией внутри, то подобное решение очень быстро закидают гнилыми помидорами.
Напоминаю, что изначально я не предлагал возвращать string, поэтому динамическая аллокация тут не обязательна.
А виртуальный вызов? Ну это же ввод-вывод. Это не то, что будет тормозить.
Здравствуйте, vsb, Вы писали:
vsb>>>Поэтому когда я говорю, что мне кажется, что использовать что-то кроме %s для пользовательских типов не нужно, в основном это вызвано тем, что я не знаю ни одного языка, где это было бы.
S>>Это логика из категории "если миллионы мух"...
vsb>Ну как бы и тема про то, почему на других языках писать комфортнее.
Но вы в нее приходите с логикой "а вот в других языках по другому". Ну так на то они и другие языки.
S>>C++ очень сильно отличается от Java или Objective C. S>>Например, в нем ООП не обязательно. S>>Следовательно, нет какой-то вершины иерархии, вроде Object, в которую можно было зафигачить toString.
vsb>Я уже писал пример, при котором вершина иерархии не нужна.
Давайте будем последовательны. Вы привели пример, в котором общий корень не нужен. Его обсудили. Затем вы в дополнение к тому, что уже было обсуждено, добавляете еще:
В Java есть String.format, в нём %s вызывает toString() у пользовательского объекта. В Objective C есть %@, там тоже какой-то подобный метод.
И я отвечаю вам на то, что вы добавили. Пока все вроде логично, не так ли?
Но потом вы опять апеллируете к предыдущему примеру. И тут мне непонятно зачем.
S>>Кроме того, в C++ многие упарываются по производительности и накладным расходам.
vsb>Это обычно прямо противоречит "писать проще и комфортнее".
Ну так прикладные ниши, которые еще остались у C++, они же как раз про производительность, накладные расходы и предсказуемость.
И тем, кто вынужден продолжать пользоваться C++, хочется в этих условиях "писать проще и комфортнее" насколько это возможно.
Отсюда и использование своеобразных практик, на которые в языках, где производительностью, накладными расходами и предсказуемостью, упарываются на так сильно, не идут. Вот те же шаблоны, из-за которых компиляция тормозит, зато в run-time нет лишней косвенности на виртуальных вызовах.
vsb>А виртуальный вызов? Ну это же ввод-вывод. Это не то, что будет тормозить.
Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.
Здравствуйте, so5team, Вы писали:
vsb>>А виртуальный вызов? Ну это же ввод-вывод. Это не то, что будет тормозить.
S>Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.
А текущая система iostreams — она как в таком раскладе работает? Много слышал про её тормоза, сам не мерял, правда.
Здравствуйте, vsb, Вы писали:
S>>Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.
vsb>А текущая система iostreams — она как в таком раскладе работает? Много слышал про её тормоза, сам не мерял, правда.
Да, говорят, что тормозит. Например, на github-е fmtlib есть такие результаты:
Но, помнится по рассказам тех, кто в std::ostream погружался, там куча заморочек с локализацией, что добавляет тормозов.
В принципе, можно свою реализацию ostream-а сделать, где бы лишнего не было. Но это непросто, насколько я помню.
Здравствуйте, so5team, Вы писали:
S>>>дабл выводится там, где требуется строка CC>>А что должно выводиться? S>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.
А вот представь что это логгинг в ветке, которая редко выполняется. В итоге мы знаем что что то пошло не так но вообще не знаем ничего больше.
Так что на порядки лучше получить не совсем правильно отформатированные данные чем совсем ничего.
S>Округлять вещественное до целого можно по разному, пользователь должен задавать это явным способом
См выше.
S>Значит должна быть ошибка в run-time.
Вывод сообщения об ошибке вернул ошибку и ничего не вывел — это проблема куда хуже.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Затем, что речь идет о моменте выхода C++ в мир, когда выбор был между сишными функциями и изобретением чего-то другого. Изобрели iostream и перегрузку operator<<. С перегрузкой оператора получилось нормально, практично
Вот как раз практичность и пострадала.
S>(если не обращать внимания на вопли пуристов из разряда "да как они посмели поступить так с оператором битового сдвига"
Оператор точка был бы удобнее, тем что у них вышло таки пользоваться неудобно.
S>Речь про прошлое, в котором в C++ шаблонов не было, не говоря уже про вариадики.
Для printf-like достаточно было оператора запятая.
S>>>Во-вторых, как с помощью мифического crprintf вывести объект собственного типа? CC>>А где в исходнои примере ("std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;") объект собственного типа? S>Да легко:
Ты не понял вопроса.
CC>>Впрочем если припрёт то всё что надо это определить функцию в namespace которая будет принимать контекст и const& на нужный тип и внутри сама форматировать его в строку. S>Ну вот в fmtlib пошли по этому пути, только там не функцию, а специализацию шаблона нужно определять.
Мне эта либа не понравилась, переусложнили.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CRT, Вы писали:
CRT>сишный printf с его языком форматирования гораздо удобней чем cout, но опаснее.
Нынче (да и раньше тоже) легко на С++ делался printf с тем же языком только безопасный.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Можно было, наверное, сделать функцию print(stream, arg), которую можно было бы перегружать для пользовательских типов.
Просто перегрузи оператор запятая для класса форматтера, который вернёт основное тело printf_core(const char* fmt)
Потом через вариадик-макрос делается обёртка, которая строку форматирования передаёт в функцию, которая возвращает объект форматтера а все аргументы __VA_ARGS__ автоматом туда добавит через запятую, ну и заворачивает это всё в скобочки чтоб не вылезло.
Оператор запятая там работает абсолютно так же как и operator<<
Вариадик темплейты это всё делают банально сильно аккуратнее, без необходимости перегрузки именно оператора, тупо функцию форматтер добавляешь для нужного типа.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
CC>>Да вон даже в стандарте std::format наконец предложили. Только он всё равно какой то корявый у них вышел. S>Так в том-то и фокус: однозначно лучше не получилось.
Да потому я и не люблю стандартную библиотеку — они там гонятся за тем, чтоб сделать её максимально generic и получается что то недоубоваримое. Всё такое расширяемое, такое гЫбкое что на ногах не стоит.
S>Как только вы ее выпустите в свет
А зачем? Она написана решать конкретные задачи, и их прекрасно решает. Задачи сделать универсальный всемогутор не стояло и не будет.
На основе этого кода уже написаны несколько версий, заточенных под совсем другое, и они тоже работают максимально хорошо для своих применений. Если же генерализировать чтоб и туда и сюда подходило — получится что то громоздкое и такое же хреновое как и в стандартной.
S>Т.е. эпитеты "отвратительно спроектированный интерфейс"
А лепить цепочку через << это и есть отвратительный интерфейс. Ибо это кошмарно неудобно, особенно на фоне других решений.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>Впрочем может быть современные компиляторы научились компилировать шаблоны один раз? Плохо представляю, как это может работать, но вроде были какие-то precompiled headers, которые я так и не смог "завести".
ICC давно умеет в автоматические precompiled headers для которых вообще ничего врукопашную делать не надо. Работает замечательно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>C++ пока еще очень сдерживает модель компиляции, унаследованная из C: одни и те же заголовочные файлы приходится парсить помногу раз.
Давно решено на уровне компилятора в нормальных компиляторах. Результаты кэшируются.
S> Повсеместное пришествие поддержки модулей из C++20 должно улучить ситуацию. Ускорить где-то на 1/3
Да уже лет 10 как проблемы на практике нету
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.
CC>А вот представь что это логгинг в ветке, которая редко выполняется.
Вот поэтому compile-time проверки гораздо лучше run-time.
CC>Так что на порядки лучше получить не совсем правильно отформатированные данные чем совсем ничего.
Вообще-то говоря еще на порядки лучше иметь протестированные даже редко выполняемые ветки. Иначе там проблемы похлеще неправильного логирования могут жить.
S>>Округлять вещественное до целого можно по разному, пользователь должен задавать это явным способом CC>См выше.
Если не будет неявных преобразований типа, то не придется ссылаться "См выше".
Здравствуйте, CreatorCray, Вы писали:
CC>Оператор точка был бы удобнее, тем что у них вышло таки пользоваться неудобно. CC>Для printf-like достаточно было оператора запятая.
Так речь об операторе точка или операторе запятая?
Если об операторе запятая, то мы меняем шило на мыло. Точнее мыло на шило, ибо, подозреваю, на это шило бы напарывались бы побольше.
S>>>>Во-вторых, как с помощью мифического crprintf вывести объект собственного типа? CC>>>А где в исходнои примере ("std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;") объект собственного типа? S>>Да легко: CC>Ты не понял вопроса.
Если вопрос важен, то может его переформулируете, чтобы было понятнее?
Здравствуйте, CreatorCray, Вы писали:
S>>Можно было, наверное, сделать функцию print(stream, arg), которую можно было бы перегружать для пользовательских типов.
CC>Просто перегрузи оператор запятая для класса форматтера, который вернёт основное тело printf_core(const char* fmt) CC>Потом через вариадик-макрос делается обёртка, которая строку форматирования передаёт в функцию, которая возвращает объект форматтера а все аргументы __VA_ARGS__ автоматом туда добавит через запятую, ну и заворачивает это всё в скобочки чтоб не вылезло.
__VA_ARGS__, если верить беглому гуглению, появился в C99, т.е. это уже 1990-е годы. А operator<< берет свое начало в первой половине 1980-х.
Здравствуйте, CreatorCray, Вы писали:
S>> Повсеместное пришествие поддержки модулей из C++20 должно улучить ситуацию. Ускорить где-то на 1/3 CC>Да уже лет 10 как проблемы на практике нету
Ну-ну, ну-ну... Я не самый большой любитель упарываться шаблонной магией, но местами компиляция одного (всего одного) .cpp файла в течении 10-15 секунд -- это вполне себе обыденно.
Здравствуйте, LaptevVV, Вы писали:
LVV>а) язык реально очень большой. LVV>б) стандартная библиотека напротив сильно маленькая. LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование LVV>Это когда практически все системы стали с сетевым взаимодействием. АСE: ADAPTIVE Communication Environment кроссплатформенная C++-либа для низкоуровневого сетевого программирования.
PS: опыта личного, прям вот ручками, прям вот с так называемыми «кодами» у меня нет, прям вот чтобы в живом проекте, по делу, «Чтобы коды прям с утра, и тряслись и трепетали..» (С) — да такого не дошло как-то.
Но несколько лет назад прочитал книжку на русском про ACE. В целом мне понравилась (сама концепция ACE, да и книга толково написана. Название манускрипта с ходу не скажу, мне надо на полке его поискать...).
Здравствуйте, Carc, Вы писали:
C>Здравствуйте, LaptevVV, Вы писали:
LVV>>а) язык реально очень большой. LVV>>б) стандартная библиотека напротив сильно маленькая. LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование LVV>>Это когда практически все системы стали с сетевым взаимодействием. АСE: ADAPTIVE Communication Environment кроссплатформенная C++-либа для низкоуровневого сетевого программирования.
PS: опыта личного, прям вот ручками, прям вот с так называемыми «кодами» у меня нет, прям вот чтобы в живом проекте, по делу, «Чтобы коды прям с утра, и И тряслись и трепетали..» (С) — да такого не дошло как-то.
Но несколько лет назад прочитал книжку на русском про ACE. В целом мне понравилась (сама концепция ACE, да и книга толково написана. Название манускрипта с ходу не скажу, мне надо на полке его поискать...).
Здравствуйте, so5team, Вы писали:
S>>>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так. CC>>А вот представь что это логгинг в ветке, которая редко выполняется. S>Вот поэтому compile-time проверки гораздо лучше run-time.
Не не всегда применимы
CC>>Так что на порядки лучше получить не совсем правильно отформатированные данные чем совсем ничего. S>Вообще-то говоря еще на порядки лучше иметь протестированные даже редко выполняемые ветки. Иначе там проблемы похлеще неправильного логирования могут жить.
Это ортогонально.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
CC>>Оператор точка был бы удобнее, тем что у них вышло таки пользоваться неудобно. CC>>Для printf-like достаточно было оператора запятая. S>Так речь об операторе точка или операторе запятая?
Оператор запятая необходим чтоб замакрить это всё чтоб выглядело как обычный printf, ибо __VA_ARGS__ вставляет аргументы именно через запятую.
CC>>Ты не понял вопроса. S>Если вопрос важен, то может его переформулируете, чтобы было понятнее?
Мне уже и так скучно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>__VA_ARGS__, если верить беглому гуглению, появился в C99, т.е. это уже 1990-е годы. А operator<< берет свое начало в первой половине 1980-х.
Можно без него, но тогда использование выглядеть будет странноватее:
printflike ("%u %i %f"), a, b, c;
вместо
printflike ("%u %i %f" , a, b, c);
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
C++ — кошмарный язык. Его делает ещё более кошмарным тот факт, что множество недостаточно грамотных программистов используют его, до такой степени, что оказывается намного проще выкинуть его как мусор.
Откровенно говоря, даже если нет *никаких* причин для выбора Си, кроме того чтобы держать C++-программистов подальше — то одно это уже будет достаточно веским основанием для использования Си.
Я пришёл к выводу, что *действительно* предпочту выгнать любого, кто предпочтёт вести разработку проекта на C++, нежели на Си, чтобы этот человек не загубил проект, в который я вовлечён.
C++ приводит к очень, очень плохим проектным решениям. Неизбежно начинают применяться «замечательные» библиотечные возможности вроде STL, и Boost, и прочего мусора, которые могут «помочь» программированию, но порождают:
— невыносимую боль, когда они не работают (и всякий, кто утверждает, что STL и особенно Boost стабильны и портируемы, настолько погряз во лжи, что это даже не смешно)
— неэффективно абстрагированные программные модели, когда спустя два года обнаруживается, что какая-то абстракция была недостаточно эффективна, но теперь весь код зависит ото всех окружающих её замечательных объектных моделей, и её нельзя исправить, не переписав всё приложение.
Другими словами, единственный способ иметь хороший, эффективный, низкоуровневый и портируемый C++ сводится к тому, чтобы ограничиться всеми теми вещами, которые элементарно доступны в Си.
А ограничение проекта рамками Си будет означать, что люди его не выкинут, и что будет доступно множество программистов, действительно хорошо понимающих низкоуровневые особенности и не отказывающихся от них из-за идиотской ерунды про «объектные модели».
Когда эффективность является первостепенным требованием, «преимущества» C++ будут огромной ошибкой.
Казалось бы не используй парадигмы, если они создают проблемы в конкретном проекте, но на практике всё выходит не так. Особенно плохо на этапах обучения, когда непонятна лучшая стратегия, а чтобы её понять может показаться, что нужно выучить всё.
Или что мешает писать битомолки на C# или Java. По сути синтаксис разных языков не так уж и различается, но проще сказать, что каждый язык создан для чего-то конкретного. Ты не инвалид, ты особенный язык.
Сегментация: относится к процессу разделения широкого потребительского или делового рынка, обычно состоящего из существующих и потенциальных клиентов, на подгруппы потребителей (известные как сегменты). Либо деление аудитории на более узкие аудитории. Например многие компании, при продаже продукции Apple разделяют аудиторию текстом, давая каждой аудитории то, что им необходимо. Мужчинам — престиж, надежное качество. Девушкам — крутую камеру и красивые селфи.
Таргетирование: относится к выбору сегмента или сегментов, которые станут объектом особого внимания (известные как целевые рынки).
Позиционирование: относится к общей стратегии, которая «направлена на то, чтобы бренд занимал определенную позицию относительно конкурирующих брендов в сознании потребителя»
Математик мог с той же лёгкостью писать формулы на C++ в структурной парадигме программирования, нежели на Python. Но мы можем позиционировать Python как язык для лёгкого написания скриптов. Таким образом мы получаем целевую аудиторию математиков в свои руки.
А про C++ мы скажем, что там всё слишком сложно, нужно сначала выучиться объектно-ориентированному и обобщённому программированию, множеству шаблонов проектирования, и то не факт, что сможешь написать формулу. Так естественная битомолка проигрывает в глазах потребителя.
В C# и Java мы будем рекламировать условно входящие в состав фреймворки. Да, для C++ есть Qt, но там много что ещё есть. В конце концов Qt не идёт в комплекте с C++, а .NET и прочие идут. Вот у нас уже есть целевая аудитория формошлёпов, и C++ опять проиграл.
Или взять веб, очевидно же что веб нужно писать на веб языках, скрипты, все дела. Почему? Да потому, что есть веб сервера написанные на Си, такие как Nginx, Apache, Lighttpd. Подождите, но если сервера написаны на Си, значит можно было бы использовать их сетевую часть для... Нет!!! Не думай, не заканчивай эту мысль. Ты ведь знаешь, что писать сайты на C++ плохая идея, особенно если кто создаст к серверам скриптовый модуль C++.
Вот так у нас появилась целевая аудитория под каждый язык программирования. Каждый язык имеет своё предназначение и это хорошо. Зачем нам универсальный инструмент, в этом нет смысла. Самое главное, что выучить только одну область такую как формошлёпство, веб или даже битомолки проще, чем все сразу. Потому одни языки программирования проще других.
Здравствуйте, CreatorCray, Вы писали:
V>>Ещё раз процитирую. V>>Линус Торвальдс CC>Вот как раз мнение этого пЫнгвина касательно чего угодно не интересует совершенно.
Здравствуйте, velkin, Вы писали:
V>https://www.youtube.com/watch?v=JbovJbKALzA
Ты правда думаешь что я про этот его высер не в курсе?
Надо же nVidia не захотела плясать под его хотелки, какая беда! Не хотят свой код отдавать под вирусную GPL — вот жеж сволочи какие!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>>>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так. CC>>>А вот представь что это логгинг в ветке, которая редко выполняется. S>>Вот поэтому compile-time проверки гораздо лучше run-time. CC>Не не всегда применимы
Если проблемы не ловятся в compile-time, то остается только тестировать.
Ну или убеждать себя в том, что написав %s вместо %e все равно что-то да выведется и это хорошо.
Здравствуйте, CreatorCray, Вы писали:
S>>__VA_ARGS__, если верить беглому гуглению, появился в C99, т.е. это уже 1990-е годы. А operator<< берет свое начало в первой половине 1980-х.
CC>Можно без него, но тогда использование выглядеть будет странноватее: CC>
CC>printflike ("%u %i %f"), a, b, c;
CC>
Ну и получаем, что:
* перегрузка оператора все равно нужна, так что дальше лишь дело вкуса: кому-то не нравится перегрузка operator<<, кому-то перегрузка operator,;
* придется объяснять новичкам, что же делает эта конструкция и почему она так отличается от обычного вызова функции;
* непонятно зачем городить для простых случаев форматную строку со спецификаторами типов, если в C++ мы и так точно знаем типы параметров;
* непонятно как встраивать в этот механизм поддержку вывода для пользовательских типов.
Так что, как и было сказано ранее, шило на мыло. Для хорошего решения в начале 1980 в C++ просто не было достаточных выразительных средств.
Здравствуйте, CreatorCray, Вы писали:
S>>Если проблемы не ловятся в compile-time, то остается только тестировать. CC>А вода — мокрая!
Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая.
Но если кому-то printf-like стиль настолько нравится и есть возможность апеллировать к афигенному опыту, то все остальное будет уродским и извращенным, да.
Ну вот это все объясняет. Вместо того чтобы рассматривать что такое С++ на самом деле, ты рассматриваешь какие-то стереотипы, которые еще и не общеприняты.
Соответственно и проблемы С++ идентифицированы не верно.
Во первых, современный мэнйстрим — это совсем не системные приложения. Сейчас от языков требуется, чтобы они позволяли максимально просто гонять джейсонины туда-сюда и имели низкой порог вхождения для программистов. Плюсы тут даже близко не стояли.
Во вторых, даже в той области, для которой плюсы создавались, у современных плюсов есть проблемы. C++ (и ему подобные) — это языки, которые надо "уметь готовить". Поэтому вместо того, чтобы концентрироваться на задачах бизнеса, командам на с++ приходится заниматься поиском особых поваров, которые 1) никогда не используют вредных продуктов голых указателей, new, delete, 2) знают наизусть Великую поварскую книгу хотя бы Effective Modern C++, 3) разбираются в молекулярной кухне современных стандартах, 4) всегда придерживаются строгого порядка добавления ингредиентов стиля программирования (чтобы их код могли понять другие) и т.п. Ну вы понели ))
Здравствуйте, Shmj, Вы писали:
S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.
Есть еще один "плюс плюсов" — Shmj научился правильно выбирать форум.
От сабя лично и от лица определенного круга участников: огромное тебе человеческое спасибо, что не принес этот вопрос в профильный форум
Здравствуйте, gandjustas, Вы писали:
G>Ну конечно не решили, скорее даже ухудшили. Если в голом C можно было передать указатель на структуру и копию структуры, то в C++ можно передать: копию объекта, указатель, ссылку, smart_ptr, ссылку на smart_ptr, указатель на smart_ptr, rvalue ссылку, rvalue ссылку на smart_ptr. Ничего не забыл?
Здравствуйте, CreatorCray, Вы писали:
CC>Никогда не понимал чего все так дрочат вприсядку на стандартную либу. CC>Возможно меня опыт системщика приучил что всё всегда делать надо исключительно на системных примитивах ибо всегда во главу угла выходил фокус на максимальную оптимальность под конкретной системой а не чтоб вышло что то обобщённое, что одинаково (плохо) работает на разных платформах.
Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок: при переходе на новый процессор или платформу всё по новой... Оно, конечно, всегда при деле, но пятый раз писать одно и то же...
И ведь самое забавное, что производительность при этом совсем не максимальна: всё время уходит на копирование структур и массивов.
Здравствуйте, so5team, Вы писали:
S>Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая.
И чем именно "{}" лучше чем "%s"?
Я вижу только недостаток в том, что надо маскировать два специальных символа, которые куда чаще встречаются в обычном тексте чем символ процента.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, B0FEE664, Вы писали:
BFE>Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок
Куда больше интересует производительность результата.
BFE> при переходе на новый процессор
Шта?
BFE> или платформу
И как часто это происходит в реальности?
BFE>всё время уходит на копирование структур и массивов.
А зачем их всё время копировать?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, rg45, Вы писали:
R>От сабя лично и от лица определенного круга участников: огромное тебе человеческое спасибо, что не принес этот вопрос в профильный форум
А бомбочки на что?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Константин Б., Вы писали:
V>>Фактически я сейчас говорю о позиционировании в маркетинге. КБ>Ну вот это все объясняет. Вместо того чтобы рассматривать что такое С++ на самом деле, ты рассматриваешь какие-то стереотипы, которые еще и не общеприняты.
А ты думаешь языки программирования выбирают на основе объективных, а не субъективных факторов. Или что программисты управляют бизнесом, а не бизнес программистами. Это всё равно, что сказать, что хвост виляет собакой, а не собака хвостом.
По факту если бизнес готов заплатить за решения своих проблем десять тысяч рублей, то он заплатит столько или попробует работать иначе. Если бизнес готов заплатить десять миллионов рублей, доходы позволяют, то и десять миллионов заплатит. Кто-то вбухивает в разработку миллиарды, потому что есть окупаемость.
Люди пытаются изображать из себя объективных, но что мы видим по факту. Какой-нибудь Google создал свои системы на C++. Доход он получает не с продажи программ, а рекламодателей. И кто-то там внутри решил сделать Go. И "все" такие смотри это Go, давайте учить его.
А что только Microsoft не создавали. Языки относящие к .NET это по факту калька к Java. Какой-то бизнес решил, что им надо писать на Java или .NET языках. Он пишет вакансии, что так и так, нам нужны программисты с таким стеком технологий.
То что я пишу, может показаться философией, но если у заказчика есть деньги, то он может нанять программиста даже на ассемблере или в машинных кодах. Если ему не хватит инструментов и возможностей, то он может сделать какой-нибудь свой генератор, в конце концов именно так компиляторы и работают.
Назовут его Ассемблер++ и вот тебе крутой язык программирования. Или мы говорим о том, что парадигмы программирования иногда идут во вред. Давайте тогда сварганим язык программирования СтопПарадигм++. Фишка у него в том, что нужно будет предварительно задать список парадигм и входящих в них возможностей, которые нельзя использовать в данном проекте.
Но если у программиста есть мозги, то он может обойтись чем-то стандартным, без Ассемблер++ или СтопПарадигм++. Можно создать крутую систему на обычном Си без всяких C++.
Фактически есть два определяющих фактора для языков программирования и оба относятся к позиционированию.
1. Позиционирование языков программирование для бизнес использования программистом.
2. Позиционирование языков программирование для личного использования программистом.
Если какой-то банк пишет для себя софт на Java и их всё устраивает, то они дадут вакансию, что нам надо программистов на Java. Нет программистов на Java, а нам класть на это свой огромный болт, мы просто увеличим зарплаты на порядок и они появятся. Может не сразу, но найдутся люди готовые с этим заморочиться за такие то деньги.
А смысл нам докапываться почему банком был выбран Java, а не что-то для каждого. Ткни в небо, назови случайный язык программирования. Будет ли выбор для личного использования адекватным. Для адекватного выбора нужно разбираться в предмете. Новичок он на то и новичок, что в нём не разбирается.
Так что не исключено, что "объективным" фактором станет случайный Васёк Пупкин на форуме, или хайп, что типа смотрите как много вакансий, или смотрите вакансий на порядок меньше, зато высокие зарплаты. И потом люди ходят, мы такие классные, полностью объективные, наш выбор правильный, верной дорогой идём товарищи.
Здравствуйте, CreatorCray, Вы писали:
S>>Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая. CC>И чем именно "{}" лучше чем "%s"?
Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений, ведь актуальные типы все равно точно известны. Так что хоть "{}", хоть "%%", хоть "<>", ...
Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр., и пр. То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).
Здравствуйте, velkin, Вы писали:
V>А смысл нам докапываться почему банком был выбран Java, а не что-то для каждого. Ткни в небо, назови случайный язык программирования. Будет ли выбор для личного использования адекватным. Для адекватного выбора нужно разбираться в предмете. Новичок он на то и новичок, что в нём не разбирается.
Был недавно в сбере, получал новую карточку. У меня вызвал смех тот факт, что менеджер работал с планшетом, а не на компютере.
То есть создать приложение для того же андроида это нормально, а вот для Windows как то руки не дошли?
На том же MAUI это не проблема. Или просто Xamarin с различным гуем, но единой кодовой базой.
Вэб приложение мне лично не удобно
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, so5team, Вы писали:
S>Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений
Да пофигу на метки типов. Считай что "%s" это "%*", универсальный тип. Но такой формат таки позволяет единообразно уточнить в каком виде мы хотим видеть конкретное значение.
S>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр.
И что же мешало делать то же самое с %?
Так что нет, не удобны. Всё это уже было и работало.
S>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).
Этот новострой неудобнее как раз традиций.
Ну и к тому же типичный NIH
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений CC>Да пофигу на метки типов.
Если пофигу, то зачем вы за них так держитесь?
S>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр. CC>И что же мешало делать то же самое с %?
Тем, что в случае с % не очевидно, что должно быть %% когда дополнительных параметров нет. Тогда как со скобками это очевидно.
S>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format). CC>Этот новострой неудобнее как раз традиций.
В C++ из традиций были только iostreams с operator<< (от которых многие, включая вас, плюются) и унаследованный из Си printf (от которого больше вреда, чем пользы). А тут хороший опыт и традиции в другом языке, который в последние годы плотно C++ сопровождает. Грех было не воспользоваться.
Здравствуйте, vsb, Вы писали:
S>>Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.
vsb>А текущая система iostreams — она как в таком раскладе работает? Много слышал про её тормоза, сам не мерял, правда.
А ей кто-то пользуется, ну кроме примеров и задачек на leetcode?
Здравствуйте, so5team, Вы писали:
S>Если пофигу, то зачем вы за них так держитесь?
Чтоб не переписывать туевы хучи кода на новые метки, doh!
Ну и да, %s == {}
S>Тем, что в случае с % не очевидно, что должно быть %% когда дополнительных параметров нет.
А чем %s не устраивает в этом случае?
S>В C++ из традиций были только iostreams с operator<<
Это у тех, кто кроме стандартной библиотеки мира не видел.
S>и унаследованный из Си printf (от которого больше вреда, чем пользы).
Printf написанный именно на С++ как раз работает замечательно.
То, что бесполезный комитет сумел родить это только к 20й версии (и то корявое донельзя) совсем не отменяет что у практикующих людей это всё давно уже было.
S>А тут хороший опыт и традиции в другом языке
Пусть остаются в другом языке, не надо это сюда тащить. Ничего эдакого хорошего в этом нет, банальный NIH
Мне надоело.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
S> Был недавно в сбере, получал новую карточку. У меня вызвал смех тот факт, что менеджер работал с планшетом, а не на компютере.
Кстати недавно тоже наблюдал что-то подобное в Сбербанке:
ПК у сотрудника нет, но есть планшет, причем судя по происходившему цирку с конями единственный работающий на всё отделение (ну или на услугу в очереди, на которую, я был).
И они его попеременно передавали друг другу. Отчего всё с черепашьей скоростью и двигалось.
Вместо распечатки черновика на бумаге передают планшет клиентам на проверку.
Для сравнения в 2021 всё было быстро, без очередей. Оператор работала на десктопе.
Распечатала на бумаге черновой вариант, потом чистовой на подпись.
S> То есть создать приложение для того же андроида это нормально, а вот для Windows как то руки не дошли? S>На том же MAUI это не проблема. Или просто Xamarin с различным гуем, но единой кодовой базой. S> Вэб приложение мне лично не удобно
Там же по сути заполнение формы и всё. Веб приложение вполне годится.
Здравствуйте, so5team, Вы писали:
S>>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр. CC>>И что же мешало делать то же самое с %? S>Тем, что в случае с % не очевидно, что должно быть %% когда дополнительных параметров нет.
Эээ... Вообще-то %% во всех printf-like означает одиночный символ '%', а не "дополнительных параметров нет". Или вы как-то очень странно выражаетесь.
S> Тогда как со скобками это очевидно.
И что же именно очевидно-то?
Что надо писать %% чтобы передать пробел — ну да, надо доку прочитать.
Точно так же надо доку прочитать чтобы понять, что надо писать {{ и }} чтобы они не понимались как управляющие.
А вот что {} означает "сам выбери самый полезный вариант" — для этого аналога нет — его надо было бы изобретать явно.
Хотя в Java, например, %s работает для этого — что бы ни было, оно сначала подвергается toString(). Для C|C++ придётся таки изобретать своё (если вообще делать).
S>>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).
В C# оно было введено значительно раньше Python. И первое или нет — не знаю как смотреть, может, кто-то знает про более ранний пример.
Я думаю, что влияние со стороны C# было не менее существенно, чем из Python.
Здравствуйте, CreatorCray, Вы писали:
S>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр. CC>И что же мешало делать то же самое с %? CC>Так что нет, не удобны. Всё это уже было и работало.
Совместимость. Большинство вариантов, которые можно задать не меняя полностью стиль, уже занято какими-то комбинациями (даже в стандарте, а тем более в конкретных имплементациях).
Изобретать методы как впихнуть туда что-то новое -- привело бы к какому-нибудь "птичьему" языку стиля того, что мы наблюдаем с регулярными выражениями и особенно с их продвинутыми расширениями, где всякие (?<:...).
Вариант с {} (начался с C# или даже раньше), во-первых, делает всё с нуля, во-вторых, использует рефлексию (или compile-time аналог) для того, чтобы именно тип значения не надо было передавать. Поэтому там концентрация на том, _как_ форматировать, а не том, _что_ форматировать из входного потока байтов или регистров.
S>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format). CC>Этот новострой неудобнее как раз традиций. CC>Ну и к тому же типичный NIH
Здравствуйте, netch80, Вы писали:
S>>>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр. CC>>>И что же мешало делать то же самое с %? S>>Тем, что в случае с % не очевидно, что должно быть %% когда дополнительных параметров нет.
N>Эээ... Вообще-то %% во всех printf-like означает одиночный символ '%', а не "дополнительных параметров нет". Или вы как-то очень странно выражаетесь.
В printf-like синтаксисе, имхо, ключевой момент в том, что % обозначает "сейчас пойдут параметры", а завершает этот необязательный список параметров обязательный спецификатор типа (s, d, x, e и т.д.). Если мы этот самый спецификатор шлем вдоль, а именно об этом я и говорю, то от printf-like синтаксиса у нас остается только %. Ну а т.к. % только открывает спецификацию вывода, то появляется задача как эту спецификацию закрыть. Например, %02x% (где x обозначает не int, а только шестнадцатиричное представление). Соответственно, если спецификация пуста, то получается %%.
То, что %% -- это обозначение для одинарного %, простите, запамятовал. За последние пару десятков лет с printf приходилось иметь дело лишь эпизодически.
S>> Тогда как со скобками это очевидно.
N>И что же именно очевидно-то?
Что {} обозначает дефолтную спецификацию вывода. Тогда как {:02x} обозначает применение формата "02x".
И здесь {} можно заменить на () или [], или <>. Суть в парности символов открытия и закрытия спецификации формата вывода.
S>>>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).
N>В C# оно было введено значительно раньше Python. И первое или нет — не знаю как смотреть, может, кто-то знает про более ранний пример. N>Я думаю, что влияние со стороны C# было не менее существенно, чем из Python.
Может Python-овский формал позаимствовал чуть больше, чем все, из C#. Может быть.
Но автор fmtlib ссылается именно на Python-овский format, так что логичным было бы назвать это влиянием Python format.
Здравствуйте, so5team, Вы писали:
N>>Эээ... Вообще-то %% во всех printf-like означает одиночный символ '%', а не "дополнительных параметров нет". Или вы как-то очень странно выражаетесь. S>В printf-like синтаксисе, имхо, ключевой момент в том, что % обозначает "сейчас пойдут параметры", а завершает этот необязательный список параметров обязательный спецификатор типа (s, d, x, e и т.д.). Если мы этот самый спецификатор шлем вдоль, а именно об этом я и говорю, то от printf-like синтаксиса у нас остается только %. Ну а т.к. % только открывает спецификацию вывода, то появляется задача как эту спецификацию закрыть. Например, %02x% (где x обозначает не int, а только шестнадцатиричное представление). Соответственно, если спецификация пуста, то получается %%.
Думаю, если бы так сделали сначала, то оно было бы сильно лучше расширяемо.
Но вот имеем тяжёлое легаси.
Со введением {} по крайней мере вид форматных спецификаторов напоминает, что внутри надо ожидать совсем другое.
S>>> Тогда как со скобками это очевидно. N>>И что же именно очевидно-то? S>Что {} обозначает дефолтную спецификацию вывода. Тогда как {:02x} обозначает применение формата "02x". S>И здесь {} можно заменить на () или [], или <>. Суть в парности символов открытия и закрытия спецификации формата вывода.
Да, внешняя терминация в таком виде выглядит сильно читабельнее.
S>А я здесь не думаю, уж простите, а цитирую фрагмент из официального README: S>
Format string syntax similar to Python's format
Ясно. Да, в таком виде это аргумент.
S>Может Python-овский формал позаимствовал чуть больше, чем все, из C#. Может быть.
Почти так — причём специфические особенности Питона вроде !r вместо !s в основном неуместны для C++ (или должны быть поняты иначе).
S>Но автор fmtlib ссылается именно на Python-овский format, так что логичным было бы назвать это влиянием Python format.
Здравствуйте, so5team, Вы писали:
S>Если мы этот самый спецификатор шлем вдоль
А зачем? Всё равно надо терминатор, так что ничего не трогаем, оставляем как есть, меняется только смысл спецификаторов, которые теперь означают не тип передаваемого параметра а желаемое преставление параметра. Т.е. "s" банально становится as string, что одновременно становится аналогом "{}"
Что и обеспечивает обратную совместимость и не приводит к парадоксам типа "%%".
S>Суть в парности символов открытия и закрытия спецификации формата вывода.
А нафига?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, netch80, Вы писали:
N>Совместимость.
Сломана нахрен.
N>Изобретать методы как впихнуть туда что-то новое
А что именно новое туда надо впихнуть?
N>во-первых, делает всё с нуля
Не ну типичный NIH
N> во-вторых, использует рефлексию (или compile-time аналог)
C++ может это делать и с %
N>Поэтому там концентрация на том, _как_ форматировать, а не том, _что_ форматировать из входного потока байтов или регистров.
Я уже несколько раз пальцем показал как это сделать на С++ с %
И это у меня работало ещё до появления C++0x
CC>>Ну и к тому же типичный NIH N>Уже давно нет.
Всё ещё да, если мы говорим про С++
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
N>>Совместимость. CC>Сломана нахрен.
Из printf в printf? То есть раньше %s, %d и так далее в printf — значили одно, а сейчас другое? Пример в студию, или считаю, что соврал.
N>>Поэтому там концентрация на том, _как_ форматировать, а не том, _что_ форматировать из входного потока байтов или регистров. CC>Я уже несколько раз пальцем показал как это сделать на С++ с % CC>И это у меня работало ещё до появления C++0x
У тебя был разборщик форматной строки в compile-time до C++0x? На чистом C++98?
Здравствуйте, netch80, Вы писали:
N>У тебя был разборщик форматной строки в compile-time до C++0x? На чистом C++98?
mpl не в C++0x появился, так что принципиальных ограничений (кроме как на фиксированый лимит аргументов) не было
другое дело что вряд-ли кто-то этим для принта заморачивался
Здравствуйте, netch80, Вы писали:
N>У тебя был разборщик форматной строки в compile-time
У меня был type safe/agnostic printf где то в 2008м.
Тот самый в котором можно было на любой тип писать %s и оно правильно работало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Если мы этот самый спецификатор шлем вдоль CC>А зачем? Всё равно надо терминатор, так что ничего не трогаем, оставляем как есть, меняется только смысл спецификаторов, которые теперь означают не тип передаваемого параметра а желаемое преставление параметра. Т.е. "s" банально становится as string, что одновременно становится аналогом "{}" CC>Что и обеспечивает обратную совместимость и не приводит к парадоксам типа "%%".
А совместимость с printf многим нафиг не упала еще в 1990-х, потому что printf поддерживал вывод содержимого пользовательских типов практически никак.
Ну и иметь print, который по %i будет автоматом отображать float не поперхнувшись, ну такое себе. Я бы не хотел.
Как и объяснять в XXI веке почему используется синтаксис вида %02xs тем, что когда-то, когда меня еще не было на свете, дедушка Керниган с дедушкой Ричи придумали язык Си, в котором был printf, в котором был специальный синтаксис со спецификаторами типов, потом, спустя почти пять десятилетий, оставили всего один спецификатор типа s, который сейчас означает любой тип... В общем, ширина дорожной колеи все еще определяется размерами задниц лошадей в Древнем Риме.
S>>Суть в парности символов открытия и закрытия спецификации формата вывода. CC>А нафига?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>У тебя был разборщик форматной строки в compile-time CC>У меня был type safe/agnostic printf где то в 2008м. CC>Тот самый в котором можно было на любой тип писать %s и оно правильно работало.
Это ответ программиста — ясный, точный и абсолютно бесполезный.
Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался (например, как разбирал форматную строку).
Может, у тебя вообще там через препроцессор вызывался конвертер в ostream<<something
Здравствуйте, netch80, Вы писали:
N>Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался
Я это уже несколько раз говорил, как то надоело повторяться. Супер секретное расширение под названием оператор запятая + __VA_ARGS__ чтоб использование было такое же визуально как и printf, т.е. функция с переменным колвом аргументов
N> например, как разбирал форматную строку.
Этож вообще банальщина. Особенно когда не надо больше поддерживать всякое старьё для указания размерности, типа h или l, потому как тип переданного значения известен на момент компиляции и левой памяти из стека уже не зачерпнуть.
N>Может, у тебя вообще там через препроцессор вызывался конвертер в ostream<<something
Это не получится ибо совместить с форматной строкой будет ну уж очень гемор, но принцип был похожий: класс форматтера, в который кормятся параметры через оператор запятая.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>А совместимость с printf многим нафиг не упала еще в 1990-х, потому что printf поддерживал вывод содержимого пользовательских типов практически никак.
Вот чего мне никогда не надо было с прошлого века это как раз поддержка вывода пользовательских типов. Всё специфическое выводилось через %s и аналог toString ()
Нафига тащить это именно в форматтер — мне лично не понятно.
S>Ну и иметь print, который по %i будет автоматом отображать float не поперхнувшись, ну такое себе. Я бы не хотел.
А я по результатам многолетнего опыта не хочу чтоб вместо хоть какого то полезного сообщения в логе окажется тупо ничего.
Логгинг не имеет права поперхнуться. Потому форматтер обязан работать по принципу best effort.
S>Как и объяснять в XXI веке почему используется синтаксис вида %02xs
И какой же синтаксис для такого же вывода будет у {} нотации?
S>>>Суть в парности символов открытия и закрытия спецификации формата вывода. CC>>А нафига? S>Проще.
Кому? И чем?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Если мы этот самый спецификатор шлем вдоль CC>А зачем? Всё равно надо терминатор, так что ничего не трогаем, оставляем как есть, меняется только смысл спецификаторов, которые теперь означают не тип передаваемого параметра а желаемое преставление параметра. Т.е. "s" банально становится as string, что одновременно становится аналогом "{}" CC>Что и обеспечивает обратную совместимость и не приводит к парадоксам типа "%%".
Не обеспечивает оно обратную совместимость, потому что тип не задаёт однозначно правила печати. Для целых любой знаковости есть x. Для плавучих есть e, f, g, a.
Если ты будешь хотеть, например, %30.10es вместо %30.10e, ты уже сломал совместимость.
Если ты введёшь для этого другие знаки — то тем более.
S>>Суть в парности символов открытия и закрытия спецификации формата вывода. CC>А нафига?
Проще и человеку, и машине, по одинаковой причине: универсальный гарантированный терминатор. С классическим printf ты должен держать в голове (и в таблицах разбора) какие символы финальные, какие — нет. Почему h, j, l, l, L, q, t, z, Z — нефинальные, а a, c, d, e, f, g, i... — финальные? Где логика, кроме того что всё запоминать?
Ну а раз есть потребность в таком терминаторе, то сделать его какой-то из закрывающих скобок велел сам Отец Тьюринг.
Здравствуйте, CreatorCray, Вы писали:
N>>Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался CC>Я это уже несколько раз говорил, как то надоело повторяться. Супер секретное расширение под названием оператор запятая + __VA_ARGS__ чтоб использование было такое же визуально как и printf, т.е. функция с переменным колвом аргументов
__VA_ARGS__ нет в стандарте. Значит, расширения.
N>>Может, у тебя вообще там через препроцессор вызывался конвертер в ostream<<something CC>Это не получится ибо совместить с форматной строкой будет ну уж очень гемор,
Здравствуйте, CreatorCray, Вы писали:
S>>А совместимость с printf многим нафиг не упала еще в 1990-х, потому что printf поддерживал вывод содержимого пользовательских типов практически никак. CC>Вот чего мне никогда не надо было с прошлого века это как раз поддержка вывода пользовательских типов.
А вот мне (и не только мне) надо было.
CC>Всё специфическое выводилось через %s и аналог toString ()
Так это же так себе решение, ведь нужно промежуточную строку сформировать. ИМХО, лучше уж бы toStream.
CC>Нафига тащить это именно в форматтер — мне лично не понятно.
Хотя бы для того, чтобы можно было подхватить спецификаторы вывода. Например, если у меня есть std::vector<unsigned int>, то поменяв буковку в спецификаторе я могу отобразить его содержимое как в десятичном, так в шестандатиричном или даже двоичном представлении.
S>>Ну и иметь print, который по %i будет автоматом отображать float не поперхнувшись, ну такое себе. Я бы не хотел. CC>А я по результатам многолетнего опыта не хочу чтоб вместо хоть какого то полезного сообщения в логе окажется тупо ничего.
А я бы предпочел получить исключение в run-time, если вместо int-а оказывается float, т.к. отображая float как int мы теряем часть информации даже не зная об этом.
CC>Логгинг не имеет права поперхнуться. Потому форматтер обязан работать по принципу best effort.
Ага, и вместо значений 1.025, 1.150, 1.300, 1.400 мы будем видеть 1, 1, 1, 1. При этом, если у нас это дельта по времени между двумя событиями в секундах, то потеря информации о 25ms, 150ms, 300ms, 400ms -- это проблема. Иногда просто афигеть какая проблема.
S>>Как и объяснять в XXI веке почему используется синтаксис вида %02xs CC>И какой же синтаксис для такого же вывода будет у {} нотации?
{:02x}
Причем двоеточие здесь нужно потому, что fmtlib позволяет нумеровать аргументы, т.е. можно делать так: fmt::format("{1:03}: value obtained={0:02x}", value, iteration)
Подробнее можно посмотреть здесь: https://hackingcpp.com/cpp/libs/fmt.html#hfold2a
S>>>>Суть в парности символов открытия и закрытия спецификации формата вывода. CC>>>А нафига? S>>Проще. CC>Кому? И чем?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, CreatorCray, Вы писали:
N>>>Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался CC>>Я это уже несколько раз говорил, как то надоело повторяться. Супер секретное расширение под названием оператор запятая + __VA_ARGS__ чтоб использование было такое же визуально как и printf, т.е. функция с переменным колвом аргументов
N>__VA_ARGS__ нет в стандарте. Значит, расширения.
В стандарте C99 уже давно.
Стандартизировали и для C++ немного позже.
Здравствуйте, so5team, Вы писали:
CC>>Всё специфическое выводилось через %s и аналог toString () S>Так это же так себе решение, ведь нужно промежуточную строку сформировать. ИМХО, лучше уж бы toStream.
Ну учитывая что за 30 лет комитеты не смогли стандартизовать fopencookie() или funopen() — какой уж там toStream?
CC>>Нафига тащить это именно в форматтер — мне лично не понятно. S>Хотя бы для того, чтобы можно было подхватить спецификаторы вывода. Например, если у меня есть std::vector<unsigned int>, то поменяв буковку в спецификаторе я могу отобразить его содержимое как в десятичном, так в шестандатиричном или даже двоичном представлении.
+100.
S>>>Ну и иметь print, который по %i будет автоматом отображать float не поперхнувшись, ну такое себе. Я бы не хотел. CC>>А я по результатам многолетнего опыта не хочу чтоб вместо хоть какого то полезного сообщения в логе окажется тупо ничего. S>А я бы предпочел получить исключение в run-time, если вместо int-а оказывается float, т.к. отображая float как int мы теряем часть информации даже не зная об этом.
Вот тут сомнительно, что именно исключение. Может быть, лучше предупреждение в логе специальной меткой рядом со значением.
CC>>Логгинг не имеет права поперхнуться. Потому форматтер обязан работать по принципу best effort. S>Ага, и вместо значений 1.025, 1.150, 1.300, 1.400 мы будем видеть 1, 1, 1, 1. При этом, если у нас это дельта по времени между двумя событиями в секундах, то потеря информации о 25ms, 150ms, 300ms, 400ms -- это проблема. Иногда просто афигеть какая проблема.
Ну то что оно напишет 1 вместо 1.0 даже при точной единице — уже может быть подсказкой.
Здравствуйте, netch80, Вы писали:
CC>>>Всё специфическое выводилось через %s и аналог toString () S>>Так это же так себе решение, ведь нужно промежуточную строку сформировать. ИМХО, лучше уж бы toStream.
N>Ну учитывая что за 30 лет комитеты не смогли стандартизовать fopencookie() или funopen() — какой уж там toStream?
По большому счету, если кто-то пишет свой лисапед в обход стандартных iostreams, то он может потребовать наличие у типа метода toStream с некоторой сигнатурой. И параметром в этот toStream может идти не стандартный std::ostream, а какой-то другой тип.
В принципе, наличие этого toStream может проверяться в compile-time разными SFINAE-подобными трюками.
По большому счету, в fmtlib как раз пошли по этому пути, но еще более сурово: там теперь нужно специализацию fmt::formatter делать для своего типа. Что, временами, не сказать, что тривиально (если хочется сделать эффективно, а не через промежуточную строку). И, полагаю, авторы fmtlib пошли так не от хорошей жизни, а потому что проще (но эффективно при этом всем) сделать пока не получилось.
S>>А я бы предпочел получить исключение в run-time, если вместо int-а оказывается float, т.к. отображая float как int мы теряем часть информации даже не зная об этом.
N>Вот тут сомнительно, что именно исключение. Может быть, лучше предупреждение в логе специальной меткой рядом со значением.
Я со своей колокольни смотрю и свое мнение высказываю. Как по мне, так исключение надежнее всего (хотя исключения в проекте вообще могут быть под запретом).
Так-то понятно, что могут быть разные требования и разные взгляды. Но здесь же каждый свое ИМХО излагает. Благодаря чему можно оценить насколько все разнообразно.
Здравствуйте, CreatorCray, Вы писали:
BFE>>Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок CC>Куда больше интересует производительность результата.
Результат должен укладываться в норму, не более.
BFE>> при переходе на новый процессор CC>Шта?
Ага.
BFE>> или платформу CC>И как часто это происходит в реальности?
От конторы зависит. В одной из контор это было регулярно, каждый год новая плата с абсолютно другой сборкой, процессором и входами/выходами...
BFE>>всё время уходит на копирование структур и массивов. CC>А зачем их всё время копировать?
Потому, что "электронщики" не умеют иначе. Хотите кому-то послать данные? Ну-давайте-мы-их-скопируем-в-свой-буфер и будем медленно, битик за битиком посылать... Обменяться указателями на буфер? Это вы чего тут выдумали? Мы так не умеем... Вот наш буфер, мы им дорожим и никому не отдаём. Все данные только через него.
Здравствуйте, so5team, Вы писали:
S>А вот мне (и не только мне) надо было.
С++ хорош тем, что ты можешь пользоваться тем, что надо тебе.
А не заставлять всех остальных пользоваться тем, что им не нужно.
S>А я бы предпочел получить исключение в run-time
Когда в критичной ветке вместо лога происходит исключение и всё просирается — я за такое давно уже готов лично расстреливать.
S>Ага, и вместо значений 1.025, 1.150, 1.300, 1.400 мы будем видеть 1, 1, 1, 1. При этом, если у нас это дельта по времени между двумя событиями в секундах, то потеря информации о 25ms, 150ms, 300ms, 400ms -- это проблема. Иногда просто афигеть какая проблема.
Это всяко лучше когда не вывелось вообще ничего.
S>{:02x}
И чем это лучше чем
%02x
?
S>проще запоминать.
Вот это ты щас серьёзно?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>А вот мне (и не только мне) надо было. CC>С++ хорош тем, что ты можешь пользоваться тем, что надо тебе. CC>А не заставлять всех остальных пользоваться тем, что им не нужно.
Продолжая логическую цепочку: если мне printf не нужен был в течении многих и многих лет, то зачем мне держаться за его синтаксис?
S>>А я бы предпочел получить исключение в run-time CC>Когда в критичной ветке вместо лога происходит исключение и всё просирается — я за такое давно уже готов лично расстреливать.
Если критичная ветка не была протестирована и никто не знал, что там вместо одного типа подсовывается другой -- вот это серьезно. Но расстреливать вы собираетесь гонца, который принес вам дурную весть. Ну, OK.
S>>Ага, и вместо значений 1.025, 1.150, 1.300, 1.400 мы будем видеть 1, 1, 1, 1. При этом, если у нас это дельта по времени между двумя событиями в секундах, то потеря информации о 25ms, 150ms, 300ms, 400ms -- это проблема. Иногда просто афигеть какая проблема. CC>Это всяко лучше когда не вывелось вообще ничего.
Ничего подобного. Если события должны выполняться в течении 20 тактов, а в логе получается, что они выполнились всего за один такт, то прежде чем выяснить проблемы с логированием будет потрачено время на попытки выяснить как же так получилось, что все произошло в одном такте. А в итоге получится, что лог можно пустить в утиль, т.к. актуальной привязки ко времени там нет. И это далеко "не всяко лучше".
S>>{:02x} CC>И чем это лучше чем
%02x
?
Позволю себе процитировать ув.тов.netch80, который уже все хорошо расписал:
Проще и человеку, и машине, по одинаковой причине: универсальный гарантированный терминатор. С классическим printf ты должен держать в голове (и в таблицах разбора) какие символы финальные, какие — нет. Почему h, j, l, l, L, q, t, z, Z — нефинальные, а a, c, d, e, f, g, i... — финальные? Где логика, кроме того что всё запоминать?
S>>проще запоминать. CC>Вот это ты щас серьёзно?
Да, запомнить, что для дефолта нужно написать просто {} вместо правил выбора между %s, %i, %f и пр., легче.
Здравствуйте, so5team, Вы писали:
S>Продолжая логическую цепочку...
Не знаю как тебе а мне эта сказка про белого бычка уже надоела...
S>Если критичная ветка не была протестирована
Очень далеко не всё и не всегда можно протестировать.
S>Но расстреливать вы собираетесь гонца, который принес вам дурную весть. Ну, OK.
Не, я как раз хочу чтоб никого не расстреляли и гонец хоть что то промямлил.
S>Позволю себе процитировать ув.тов.netch80, который уже все хорошо расписал:
Он за деревьями не увидел леса.
После того, как тебе не надо задавать передаваемые размерности всякие "нефинальные" попросту отмирают.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>>>А я бы предпочел получить исключение в run-time, если вместо int-а оказывается float, т.к. отображая float как int мы теряем часть информации даже не зная об этом. N>>Вот тут сомнительно, что именно исключение. Может быть, лучше предупреждение в логе специальной меткой рядом со значением. S>Я со своей колокольни смотрю и свое мнение высказываю. Как по мне, так исключение надежнее всего (хотя исключения в проекте вообще могут быть под запретом).
Так исключения для целевого кода — могут как раз быть осмысленными, если ему лучше остановиться, чем сделать плохое — но тут точно вопрос контекста и даже вкуса.
А вот выбить логгирование — имеет смысл только тогда, когда это портит сам лог (ну типа скинуть бинарный блоб в текстовую форму, или гигабайт мусора), тут я не вижу, чем можно вообще возражать.
S>Так-то понятно, что могут быть разные требования и разные взгляды. Но здесь же каждый свое ИМХО излагает. Благодаря чему можно оценить насколько все разнообразно.
Ну вот я и не могу понять из каких соображений может быть лучше не логгировать — или даже вышибать работу целевого кода из-за проблем отладочно-диагностического логгирования.
Здравствуйте, CreatorCray, Вы писали:
S>>Позволю себе процитировать ув.тов.netch80, который уже все хорошо расписал: CC>Он за деревьями не увидел леса. CC>После того, как тебе не надо задавать передаваемые размерности всякие "нефинальные" попросту отмирают.
Нет, я же объяснил, почему.
Десятичный (d), шестнадцатиричный (x), восьмеричный (o) формат для целых.
Фиксированная точка (f), чисто плавающая (e), смешанная (g), машинно-читаемая (a) для плавучих.
Выбор локали (хотя бы — применяется или универсальный формат для машины).
Для C|C++ ещё и применение целого как кода символа (увы, char это целое).
Как ты вообще читаешь, если пропускаешь такое?
S>>Продолжая логическую цепочку... CC>Не знаю как тебе а мне эта сказка про белого бычка уже надоела...
Если бы ты хоть пытался читать что тебе пишут, ты бы давно перестал её рассказывать, за ненадобностью.
Здравствуйте, netch80, Вы писали:
CC>>После того, как тебе не надо задавать передаваемые размерности всякие "нефинальные" попросту отмирают. N>Нет, я же объяснил, почему.
И не близко. Ты там вообще о чём то ортогональном...
N>Десятичный (d), шестнадцатиричный (x), восьмеричный (o) формат для целых. N>Фиксированная точка (f), чисто плавающая (e), смешанная (g), машинно-читаемая (a) для плавучих.
И какие же из них "нефинальные", которые надо "держать в голове"?
N>Как ты вообще читаешь, если пропускаешь такое?
Какое, такое? Не имеющее отношение к обсуждаемому вопросу? Да, не вижу смысла уводить на это тему.
N>Если бы ты хоть пытался читать что тебе пишут
Попытайся прочитать что тебе пишут.
Ладно, мне уже совсем надоело, пора похоже от этой ветки отписаться.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
N>>Десятичный (d), шестнадцатиричный (x), восьмеричный (o) формат для целых. N>>Фиксированная точка (f), чисто плавающая (e), смешанная (g), машинно-читаемая (a) для плавучих. CC>И какие же из них "нефинальные", которые надо "держать в голове"?
В твоём варианте с %s — все перечисленные.
N>>Если бы ты хоть пытался читать что тебе пишут CC> CC>Попытайся прочитать что тебе пишут.
У меня как раз с этим проблем нет.
CC>Ладно, мне уже совсем надоело, пора похоже от этой ветки отписаться.
Заранее спасибо за снижение уровня бессмысленного шума. (Можешь расширить на прочие ветки.)
Здравствуйте, netch80, Вы писали:
N>Ну вот я и не могу понять из каких соображений может быть лучше не логгировать — или даже вышибать работу целевого кода из-за проблем отладочно-диагностического логгирования.
N>(Не думаю, что речь шла о целевом логгировании)
А я не про отладочно-диагностическое. Я про "целевое" логирование в вашей терминологии, по котором затем с инцидентами на проде разбираться будут. Если в таком логировании вместо int-а подсунут float и этот float автоматически сконвертируется в int, то значит мы теряем информацию, которая может быть критически важна для тех самых разбирательств. И если это происходит тайком от всех, то это не есть хорошо.
Здравствуйте, netch80, Вы писали:
CC>>И какие же из них "нефинальные", которые надо "держать в голове"? N>В твоём варианте с %s — все перечисленные.
Они как раз все финальные, включая %s
CC>>Попытайся прочитать что тебе пишут. N>У меня как раз с этим проблем нет.
Да вот что то в глаза не бросается.
N>Заранее спасибо за снижение уровня бессмысленного шума. (Можешь расширить на прочие ветки.)
Ты явно пытаешься добиться того, чтоб я все твои опусы ехидно комментировал?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Если человек обожает Си++, назубок выучил шаблоны проектирования, свободно использует стандартную библиотеку с "Бустом" и прочими библиотеками, а также следит за модными системами сборки проекта вроде "Симэйка", то на решение ответственных задач я бы такого программиста постарался не брать и сейчас поясню почему.
Чтобы сделать что-либо лучше остальных придётся разобраться в задаче от истока досконально и всё делать самому. Для этого, к примеру, "Тесла" занимается изготовлением собственной бортовой электронной аппаратуры и аккумуляторов с электродвигателями, хотя вполне могла бы поручить изготовление составных узлов автомобиля стороннему производителю.
Если же программист при обучении привык к переиспользованию чужого кода и склонен к использованию сторонних библиотек вместо написания собственного кода, наилучшим образом подходящего под задачу, то создать ПО, превосходящее всё остальное ПО, с таким товарищем вряд ли получится.
Делать как у всех смысла не имеет ибо крупные предприятия выдавят с рынка мелких лавочников наличием больших денег и, соответственно, привлечением лучших инженеров с рынка труда.
Побеждают зануды, всегда идущие от истока, вроде Линуса Торвальдса и Илона Маска, а неудачники-переиспользователи, вроде Бьёрна Страуструпа, лишь пишут одну книгу за другой ибо собственный успешный проект создать не способны.
Здравствуйте, Shmj, Вы писали:
S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.
Настоящая кроссплатформенность — это когда один и тот же код по-разному везде работает, а где-то и вовсе отказывается компилироваться?
S>Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.
Умные указатели нужно уметь использовать. Код нужно писать по неким правилам и трястись чуть ли не над каждым исключением.
Иначе вылезет что-то в каком-нибудь конструкторе не то и утекла память.
Или массив решил принять на вход, забыл проверить размерность или не ту передал — попортил память.
S>Как вы думаете?
Простота выстрелить себе в ногу и сложность реализации базовых вещей.
Можно сравнить хотя бы строковые типы в C#, Java и C++.
Здравствуйте, Pitirimov, Вы писали:
P>Побеждают зануды, всегда идущие от истока, вроде Линуса Торвальдса и Илона Маска, а неудачники-переиспользователи, вроде Бьёрна Страуструпа, лишь пишут одну книгу за другой ибо собственный успешный проект создать не способны.
Разве Страуструп не больший зануда? Вроде Маска так никто еще не унижал.
Здравствуйте, karbofos42, Вы писали:
K>Настоящая кроссплатформенность — это когда один и тот же код по-разному везде работает, а где-то и вовсе отказывается компилироваться?
Чистый код без системных вызовов то как раз 100% компилируется везде.
K>Умные указатели нужно уметь использовать. Код нужно писать по неким правилам и трястись чуть ли не над каждым исключением. K>Иначе вылезет что-то в каком-нибудь конструкторе не то и утекла память.
Правила есть, согласен. Но это — плата за нейтивность.
K>Или массив решил принять на вход, забыл проверить размерность или не ту передал — попортил память.
Так vector же подвезли вместо массивов.
S>>Как вы думаете?
K>Простота выстрелить себе в ногу и сложность реализации базовых вещей. K>Можно сравнить хотя бы строковые типы в C#, Java и C++.
Здравствуйте, Pitirimov, Вы писали:
P>Делать как у всех смысла не имеет ибо крупные предприятия выдавят с рынка мелких лавочников наличием больших денег и, соответственно, привлечением лучших инженеров с рынка труда.
Тут не просто. Велосипедить тоже далеко не всегда уместно.
Тесла с миллиардными капиталами может велосипедить — но есть ли у вас эти миллиарды?
Здравствуйте, Pitirimov, Вы писали:
P>Если человек обожает Си++ P>Если же программист при обучении привык к переиспользованию чужого кода и склонен к использованию сторонних библиотек вместо написания собственного кода, наилучшим образом подходящего под задачу, то создать ПО, превосходящее всё остальное ПО, с таким товарищем вряд ли получится.
А теперь объясни при чём тут С++?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Shmj, Вы писали:
S>Чистый код без системных вызовов то как раз 100% компилируется везде.
Правда там куча UB, которые зависят от конкретной реализации.
Где-то не вылезают ошибки и их никто не видит, а на другой платформе внезапно поведение изменится.
Компилируется тоже при условии, что везде один стандарт языка и все компиляторы этот стандарт одинаково понимают.
S>Правила есть, согласен. Но это — плата за нейтивность.
Та же Java носом тычет во все исключения и мимо не пройдёшь.
В C++ сиди за каждой строкой кода следи сам как хочешь.
В плюсах есть куча рекомендаций как нужно писать, при этом никто не заставит им следовать.
Синтаксис позволяет банальные опечатки = вместо == в условиях допускать и компилятор всё пропустит, лови потом в рантайме и глазками высматривай.
А сколько десятилетий плюсовики сидели с костылём в виде макроса NULL?
nullptr как-то помешал нативности?
А #pragma once сейчас хотя бы приняли в стандарт или до сих пор #ifndef #define пишут в каждом *.h?
Куча проблем и неудобств языка — это не плата за нативность, а просто так исторически сложилось из-за его костыльного происхождения.
S>Чем так уж std::string плох?
Тем, что константные строки "const char *", т.е. указатель, а не строка.
А ещё та же винда любит UTF-16 и уже может пригодиться и std::wstring.
И не забудь везде правильно те же константные строки прописать как "строка", L"строка", _T("строка"),...
Для пущего веселья ещё у каждой крупной библиотеки будет свой тип (CString, QString, wxString,...) и будешь туда-сюда постоянно конвертировать.
С другими контейнерами та же история. Сначала экономят на виртуальных вызовах, поэтому никаких ICollection и IEnumerable не получишь.
Зато будешь перегонять содержимое из своего std::vector в какой-нибудь QVector, т.к. нужный метод внезапно умеет работать только с таким контейнером.
Здравствуйте, karbofos42, Вы писали:
K>Правда там куча UB, которые зависят от конкретной реализации. K>Где-то не вылезают ошибки и их никто не видит, а на другой платформе внезапно поведение изменится. K>Компилируется тоже при условии, что везде один стандарт языка и все компиляторы этот стандарт одинаково понимают.
UB нужно не применять, его подсвечивают.
Со стандартом сразу решите — чтобы была поддержка всеми используемыми вами компиляторами. Вообще не злоупотреблять самыми новыми фишками — я уже так попадался.
Это больше страхи.
S>>Правила есть, согласен. Но это — плата за нейтивность. K>Та же Java носом тычет во все исключения и мимо не пройдёшь.
Но медленная и требует установки среды
Сколько минимальный размер бинарника для WebAssembly на Java?
S>>Чем так уж std::string плох?
K>Тем, что константные строки "const char *", т.е. указатель, а не строка.
Так std::string же есть, старые строки зачем использовать?
K>А ещё та же винда любит UTF-16 и уже может пригодиться и std::wstring.
А в Java и C# строка — это ведь тоже UTF-8 и если понадобится UTF-16 — то все аналогично.
Здравствуйте, Shmj, Вы писали:
S>Это больше страхи.
Нет. Это больше опять к тому, что на C++ свободно можно наворотить всякого, но потом окажется, что это работает нормально только у тебя.
Нужно долго ковыряться и изучать язык, чтобы собрать в голове что и как лучше делать и где какие нюансы.
Банально будешь использовать int в надежде на 4 байта, потом код будет собран под платформу, где он будет 2 байта, в процессе работы пойдут переполнения и успехов в отладке этого кроссплатформенного кода.
Вроде и программист сам дурак, что такое написал, а вроде и в чём кроссплатформенность языка, если он такие подставы на каждом шагу устраивает?
S>Но медленная и требует установки среды
Ну, компиляция в байт-код никак не связана с синтаксисом языка.
В .NET завезли AOT, для Java по-моему тоже что-то подобное было или есть.
S>Сколько минимальный размер бинарника для WebAssembly на Java?
WebAssembly — это очередная идиотия человеков, которые всё только усложняют.
Не смогли унифицировать окошки в десктопах, что надо и не надо вынесли в веб, всё подряд понаписали на JS, теперь оказалось, что чего-то не хватает и пытаются как-то нативный код прикрутить к вебу.
S>Так std::string же есть, старые строки зачем использовать?
"строка" — это же const char * в обоих случаях
Я давно за плюсами не слежу, они там в новых стандартах уже нормальные строковые константы добавили?
S>А в Java и C# строка — это ведь тоже UTF-8 и если понадобится UTF-16 — то все аналогично.
По-моему UTF-16 в обоих языках идёт.
В любом случае, в Java и C# строки идут как строки, а в C++ — массив символов, а строки уже отдельно прикручиваются.
Здравствуйте, karbofos42, Вы писали:
K>Банально будешь использовать int в надежде на 4 байта, потом код будет собран под платформу, где он будет 2 байта, в процессе работы пойдут переполнения и успехов в отладке этого кроссплатформенного кода. K>Вроде и программист сам дурак, что такое написал, а вроде и в чём кроссплатформенность языка, если он такие подставы на каждом шагу устраивает?
Я думаю, на такой платформе будет побольше проблем;\
Но в общем да, заложиться на ресурс и потом страдать от скрытых ошибок от его недостатка — это жестокий сюр.
K>"строка" — это же const char * в обоих случаях K>Я давно за плюсами не слежу, они там в новых стандартах уже нормальные строковые константы добавили?