Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 24.07.23 13:51
Оценка:
О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.

А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?

Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.

Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.

Как вы думаете?
Отредактировано 24.07.2023 17:26 Shmj . Предыдущая версия . Еще …
Отредактировано 24.07.2023 13:52 Shmj . Предыдущая версия .
Re: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 24.07.23 13:59
Оценка: 5 (2) +6 :))) :))) :)))
Здравствуйте, 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 запрос сделать и распарсить его ответ. С++ просто тебя заваливает какой-то лажей, не имеющей отношения к решаемой задаче.
Re: Основные минусы плюсов...
От: Osaka  
Дата: 24.07.23 14:07
Оценка: +2
S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.
На этих языках программы в большей степени "выполняются слева направо сверху вниз".
Меньше возможностей навертеть умонерастяжимых неотлаживаемых ребусов, которые понимает только их незаменимый автор (а остальные, кому понадобится сопровождать этот код, "пусть много трудятся впустую над их распутыванием, и выглядят тупыми перед начальством").
Re: Основные минусы плюсов...
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 24.07.23 14:12
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Как вы думаете?

Что ты пишешь?
Sic luceat lux!
Re[2]: Основные минусы плюсов...
От: andyp  
Дата: 24.07.23 15:02
Оценка: +1 -2
Здравствуйте, vsb, Вы писали:

vsb>12345...


Строчки-цветочки, шмектор-коллектор, переписать неправильные стандартные контейнеры... Сколько раз это слышал, скучно уже. В твоем гите мухи в полете не дохнут? Все это скорее говорит о том, как ты прогаешь, и о том, что наработанных средств для решения задач из твоей же предметной области на плюсах у тебя просто нет. Ну так не берись на них прогать, делов то...
Re: Основные минусы плюсов...
От: velkin Удмуртия https://kisa.biz
Дата: 24.07.23 17:27
Оценка: 3 (1) +2
Здравствуйте, Shmj, Вы писали:

S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ.


Да, есть, C++ это язык с "избыточным" функционалом. Слишком много парадигм требуют более квалифицированных программистов.

На C++ можно писать в стиле простейших скриптов вплоть до одного файла. А можно использовать обобщённое или объектно-ориентированное программирование. И ещё до кучи парадигм, структурное и процедурное. Хочешь модульное, пожалуйста, а не хочешь и не надо.

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

Из-за этого возникает огромное количество возможных архитектур программ. Программисты с этим не справляются, и вот это уже вопрос по поводу обучения. Иначе говоря лёгкость других языков программирования и якобы сложность C++ это чистейшая иллюзия основанная на привычных для каждого языка методах обучения.

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

В других языках тебе как бы намекают.
1. Вот у нас есть мощный встроенный фреймворк и он написан по таким вот правилам, и ты пиши так же. 2. Или вот тут все пишут в стиле скриптов, давай не робей, сразу пиши алгоритмы в скриптах.

А C++ тебе говорит, у нас тут миллион и три тележки возможностей, давай же используй, используй их все сразу!!!

Короче, программист C++, я тебя спас и в благородство играть не буду: выполнишь для меня пару заданий – и мы в расчете. Заодно посмотрим, как быстро у тебя башка после амнезии прояснится. А по твоей теме постараюсь разузнать. Хрен его знает, на кой ляд тебе эти парадигмы программирования сдались, но я в чужие дела не лезу, хочешь использовать, значит есть зачем.

Re: Основные минусы плюсов...
От: DiPaolo Россия  
Дата: 24.07.23 17:35
Оценка:
- нельзя одной строчкой кода/одной командой подцепить стороннюю библиотеку. В JS/Python/Go и т.д. подключение сторонней библиотеки делается крайне просто и быстро. В плюсах с этим надо помучаться, т.к. нет единого подхода
— стандартная библиотека не настолько проста и удобна, как в других языках. Элементарная работа с файлами, путями; те же контейнеры могли бы быть более простыми в работе (типа как в Qt)
Патриот здравого смысла
Re[2]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 24.07.23 17:41
Оценка:
Здравствуйте, Osaka, Вы писали:

O>Меньше возможностей навертеть умонерастяжимых неотлаживаемых ребусов, которые понимает только их незаменимый автор (а остальные, кому понадобится сопровождать этот код, "пусть много трудятся впустую над их распутыванием, и выглядят тупыми перед начальством").


А в каких конкретно особенностях языка это выражается?
Re[2]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 24.07.23 17:44
Оценка:
Здравствуйте, velkin, Вы писали:

V>На C++ можно писать в стиле простейших скриптов вплоть до одного файла. А можно использовать обобщённое или объектно-ориентированное программирование. И ещё до кучи парадигм, структурное и процедурное. Хочешь модульное, пожалуйста, а не хочешь и не надо.


V>По алгоритмам так же. Можно использовать голые системные вызовы. А можно воспользоваться кроссплатформенными библиотеками. Можешь писать алгоритмы сам. Можешь воспользоваться готовыми. Хочешь ассемблерную вставку, она есть у меня. Хочешь множественное наследование, ну ты сам так решил.


Вроде все это, кроме, разве что, обобщённого — есть и в других языка и погоды не строит. Получается основная фигня — в обобщенном, которого в простых языках нет в явном виде?
Re: Основные минусы плюсов...
От: CRT  
Дата: 24.07.23 17:57
Оценка: :))
нет break/continue по метке.
Приходится использовать дурацкие флаги или goto чтобы выйти из вложенного цикла.

Мелочь конечно. Но не понятно почему не добавляют, хотя столько уже обновлений за последние годы. Видимо принципиально.
Re[3]: Основные минусы плюсов...
От: velkin Удмуртия https://kisa.biz
Дата: 24.07.23 18:50
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вроде все это, кроме, разве что, обобщённого — есть и в других языка и погоды не строит. Получается основная фигня — в обобщенном, которого в простых языках нет в явном виде?


Проблема в неуправляемом обучении. Возьми Java и C#.NET, там есть готовые фреймворки из комплекта. А это считай готовая архитектура подражая которой можешь написать что-то не слишком убогое. Или у скриптовых языков пишешь в самом простом стиле и все довольны.

А что произойдёт при обучении C++, особенно при самостоятельном обучении. Человек открывает книги, спецификации, а там объектно-ориентированное программирование, но вообще без его правильного использования в виде готовых фреймворков.

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

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

Просто если тебе так уж интересно различия языков, возьми: Rosetta Code: Задачи.

Вот чисто пример от балды Rosetta Code: Abstract type

C#
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++, но сами что только людям не втюхивали.
Re: Основные минусы плюсов...
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.07.23 19:54
Оценка:
Здравствуйте, 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, что усложняет поиск ошибок.
Re: Основные минусы плюсов...
От: LaptevVV Россия  
Дата: 25.07.23 05:00
Оценка:
Минусы отсутствуют.
Для обычного программера это не плюсы, а кресты...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Основные минусы плюсов...
От: Vzhyk2  
Дата: 25.07.23 05:04
Оценка: +1 :)
LVV>Для обычного программера это не плюсы, а кресты...
Даже сын божий один таскал, а эти приплюснутые по два таскают и с удовольствием.
Re: Основные минусы плюсов... лично для меня
От: LaptevVV Россия  
Дата: 25.07.23 05:06
Оценка:
а) язык реально очень большой.
б) стандартная библиотека напротив сильно маленькая.
Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
Это когда практически все системы стали с сетевым взаимодействием.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Основные минусы плюсов... лично для меня
От: so5team https://stiffstream.com
Дата: 25.07.23 05:35
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование


И славатехоспади!

Достаточно истории с добавлением в стандарт std::unordered_map.
Re[3]: Основные минусы плюсов... лично для меня
От: LaptevVV Россия  
Дата: 25.07.23 05:52
Оценка: :))
LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
S>И славатехоспади!
Не...
В каждой новой конторе что-то не стандартное.
Да и много чего приходится стороннего брать.
А в Go — из коробки и работает везде одинаково.
На мой взгляд это Go+++, а не C++
S>Достаточно истории с добавлением в стандарт std::unordered_map.
Ну, забыли...
В запарке при сдаче релиза и такое бывает
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Основные минусы плюсов... лично для меня
От: so5team https://stiffstream.com
Дата: 25.07.23 06:05
Оценка:
Здравствуйте, 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
Re[2]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 25.07.23 07:25
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Минусы отсутствуют.

LVV>Для обычного программера это не плюсы, а кресты...

Просьба пояснить мысль.
Re[2]: Основные минусы плюсов... лично для меня
От: Shmj Ниоткуда  
Дата: 25.07.23 07:43
Оценка: +1 :)
Здравствуйте, LaptevVV, Вы писали:

LVV>а) язык реально очень большой.


Тут да. И еще такая особенность — язык очень символьный.

Вот в паскале комменты блочные обозначались символами {}. И представьте — чел. привыкает что в {} написано что-то не важное, т.е. то что вообще не исполняется — а тут ему нужно на эти ранее малозначимые символы сконцентрировать все внимание.

А так же контекст символов. Вот звездочка — это или умножение или декларация указателя или же разыменование. Это очень очень сложно удержать в голове и парсить, практически головоломка.

Не говорю уже про шаблоны шаблонов шаблонов шаблонов.

LVV>б) стандартная библиотека напротив сильно маленькая.

LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
LVV>Это когда практически все системы стали с сетевым взаимодействием.

А вот ни такая уж и маленькая — хрен запомнишь. Целые книги по ней. Сетевого программирования нет, а овердофига других вещей есть.
Re[2]: Основные минусы плюсов...
От: AlexGin Беларусь  
Дата: 25.07.23 07:55
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.

Это субъективно (точнее — из-за отсутствия опыта работы с STL).

vsb>3. IDE. В Java IDE прекрасны. В C++ они ужасны. И это не исправить, это генетическое, из-за сложности языка.

Дело привычки — от MS Visual Studio до Qt Creator — все они не хуже того же Eclipse или IDEA

vsb>5. Простота языка.

Тут соглашусь — Java проще, но C++ значительно универсальнее

vsb>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...

Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"
Re[2]: Основные минусы плюсов... лично для меня
От: CreatorCray  
Дата: 25.07.23 08:00
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>а) язык реально очень большой.

LVV>б) стандартная библиотека напротив сильно маленькая.
LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование

Никогда не понимал чего все так дрочат вприсядку на стандартную либу.
Возможно меня опыт системщика приучил что всё всегда делать надо исключительно на системных примитивах ибо всегда во главу угла выходил фокус на максимальную оптимальность под конкретной системой а не чтоб вышло что то обобщённое, что одинаково (плохо) работает на разных платформах.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Основные минусы плюсов... лично для меня
От: so5team https://stiffstream.com
Дата: 25.07.23 08:09
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

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

CC>Возможно меня опыт системщика приучил

Да, это профдеформация.

На C++ все еще делают приложения в стиле "быстренько собрать прототип, посмотреть что получится, а затем уже доводить до ума". И акцент ставиться на "быстренько собрать", а не на какие-то другие факторы (типа ресурсоемкости, производительности, надежности). Причем еще и делают это люди, которым следовало бы руки основательно так вправить перед тем, как до C++ допускать (а еще бывают персонажи вроде ТС-а).

В таких условиях наличие готового "искаропки" перевешивает все остальное.

Се ля ви.

PS. Почему при таких вводных выбирают именно C++ -- это отдельный вопрос. Иногда потому, что уже есть какой-то кусок функциональности (например, анализ видео) вокруг которого нужно что-то собрать. Т.к. кусок уже на C++, то проще продолжать на C++, чем оборачивать это в какой-нибудь условный Python.
Re: Основные минусы плюсов...
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.07.23 09:01
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Возможная причина, кмк, непростая парадигма времени компиляции. Шаблоны те же бывают трех-четырех и пяти этажные... В может и не в этом дело.

S>Как вы думаете?

С++ требует довольно большого времени на вхождение. При прочих равных, раза в 2-3 дольше. Причин много

1. область применения — требует бОльше знаний
2. огромное количество механик в С++, которые большей частью низкоуровневые
3. отдельная проблема это темплейты — сам по себе полноценный язык
4. проектов, где только хороший С++, ничтожное количество. Типичный код это С++ пополам с Си. Может это мне так везёт, не знаю.
5. последствия ошибок достаточно разрушительные в силу отсутствия механизмов изоляции
6. ручная работа с памятью, многозадачностью итд итд
Re[3]: Основные минусы плюсов... лично для меня
От: LaptevVV Россия  
Дата: 25.07.23 09:19
Оценка:
LVV>>б) стандартная библиотека напротив сильно маленькая.
LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
LVV>>Это когда практически все системы стали с сетевым взаимодействием.
S>А вот ни такая уж и маленькая — хрен запомнишь. Целые книги по ней. Сетевого программирования нет, а овердофига других вещей есть.
Маленькая
Сравни с Java/C#/Go
Очень многих вещей, которые там есть, в С++ нет.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 25.07.23 11:16
Оценка: 2 (1) +2 :)
Здравствуйте, AlexGin, Вы писали:

AG>Это субъективно (точнее — из-за отсутствия опыта работы с STL).


Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++. Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.

vsb>>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...

AG>Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"

Если мне не изменяет память, я эту книгу читал году в 2005.
Re[4]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 25.07.23 11:41
Оценка: +2
Здравствуйте, vsb, Вы писали:

vsb>Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.


По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.

Собственно, на фоне того, как определять собственные formatter-ы для fmtlib, operator<< для вывода собственного типа до сих по выглядит /мега/удобно.

vsb>>>В С++ — начинаешь проект и сходу начинаешь писать свой класс строки, свой класс массива, свой класс связанного списка...


Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?
Re: Основные минусы плюсов...
От: Разраб  
Дата: 25.07.23 11:42
Оценка:
Здравствуйте, Shmj, Вы писали:

S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.


S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?


Да. Потому что кресты это только про язык. а перечисленное это фрэймворки.
Но! Есть адекватная замена крестам https://codeberg.org/kiesel-js/kiesel
zig run core.zig

И ВОТ https://bun.sh
https://github.com/lassade/c2z
☭ ✊ В мире нет ничего, кроме движущейся материи.
Отредактировано 25.07.2023 11:45 Разраб . Предыдущая версия . Еще …
Отредактировано 25.07.2023 11:43 Разраб . Предыдущая версия .
Re[5]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 25.07.23 11:52
Оценка:
Здравствуйте, so5team, Вы писали:

S>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?


Например чтобы использовать человеческий UTF-8. А не непойми что.
Re[6]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 25.07.23 11:57
Оценка:
Здравствуйте, vsb, Вы писали:

S>>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?


vsb>Например чтобы использовать человеческий UTF-8. А не непойми что.


Ну это строки. А массивы-то зачем?

PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?
Re[7]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 25.07.23 12:27
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>Я еще могу понять когда пишут собственный интрузивный список если в проект еще не затянули условный Boost. Но строки и массивы в XXI-ом веке для каких целей сами делают?


vsb>>Например чтобы использовать человеческий UTF-8. А не непойми что.


S>Ну это строки. А массивы-то зачем?


Уже не помню.

S>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?


Не пользовался им. Это же что-то большое на мегабайты? Мне от строк нужна итерация по кодепоинтам. Всякие заумности обычно не нужны. UTF-8 достаточно простой формат и реализуется в несколько десятков строк кода. Если там какие-нибудь сортировки по национальным символам будут нужны, видимо да, ICU нужен будет. А там свой класс строк есть?
Re[8]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 25.07.23 12:40
Оценка:
Здравствуйте, vsb, Вы писали:

S>>Ну это строки. А массивы-то зачем?


vsb>Уже не помню.


Тогда это похоже на "для красного словца"

S>>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?


vsb>Не пользовался им. Это же что-то большое на мегабайты? Мне от строк нужна итерация по кодепоинтам. Всякие заумности обычно не нужны. UTF-8 достаточно простой формат и реализуется в несколько десятков строк кода. Если там какие-нибудь сортировки по национальным символам будут нужны, видимо да, ICU нужен будет. А там свой класс строк есть?


Да, ICU -- это большая штука. Поменьше есть https://github.com/nemtrif/utfcpp

Свой класс строк там есть, UnicodeString, но, скорее всего, там унутрях не UTF-8 представление.

ЕМПИП, итерироваться по кодепоинтам можно и храня содержимое в std::string, просто сделав несколько свободных функций (вспомогательных классов).
Re[4]: Основные минусы плюсов...
От: AlexGin Беларусь  
Дата: 25.07.23 13:14
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, AlexGin, Вы писали:


AG>>Это субъективно (точнее — из-за отсутствия опыта работы с STL).


vsb>Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++.

Мы (вроле как) о C++ и об STL, а не о других языках. Да, в .NET и в Java сделано иначе. Но это не означает, что в STL хуже.

vsb>Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.

Всё логично — мы можем двигать биты, и можем двигать информацию на вывод. Всё логично и просто.

AG>>Откройте для себя книгу Н. Джосаттиса "Стандартная библиотека C++"


vsb>Если мне не изменяет память, я эту книгу читал году в 2005.


Это старая редакция, теперь уже есть по C++11 (и выше).
Re[2]: Основные минусы плюсов...
От: ononim  
Дата: 25.07.23 13:17
Оценка: +1 :)
Р>Но! Есть адекватная замена крестам https://codeberg.org/kiesel-js/kiesel
Как много веселых ребят, и все делают велосипед...
Re[5]: Основные минусы плюсов...
От: CRT  
Дата: 25.07.23 15:21
Оценка: +2 :)
Здравствуйте, so5team, Вы писали:


S>По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.


Для выводы обычных строк, символов, чисел printf удобней
Re[6]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 25.07.23 15:30
Оценка:
Здравствуйте, CRT, Вы писали:

S>>По тем временам, когда в наличии был только Си-шный printf и в языке даже на шаблоны еще намека не было, это был прям таки прорыв.


CRT>Для выводы обычных строк, символов, чисел printf удобней


Расскажите эту байку кому-нибудь помоложе.
Re[5]: Основные минусы плюсов... лично для меня
От: SaZ  
Дата: 25.07.23 15:49
Оценка:
Здравствуйте, so5team, Вы писали:

S>...

S>Скорее всего, там была не запарка, а сознательное решение обеспечить сохранность итераторов при модификации, чтобы std::unordered_map мог быть прямой заменой std::map. В результате убили главное преимущество хэш-таблиц и получили рекомендацию не использовать std::unordered_map там, где требуется производительность.

А где про это можно почитать? Очень интересно. У нас наоборот тащат везде unordered_map, типа он быстрее (понятно что в идеальных случаях на больших контейнерах — да).
Re[6]: Основные минусы плюсов... лично для меня
От: so5team https://stiffstream.com
Дата: 25.07.23 16:29
Оценка:
Здравствуйте, SaZ, Вы писали:

SaZ>А где про это можно почитать? Очень интересно. У нас наоборот тащат везде unordered_map, типа он быстрее (понятно что в идеальных случаях на больших контейнерах — да).


Боюсь это все раскидано в разных блог-постах, вопросах на Stackoverflow, докладах на разных конференциях и т.д.
Типа вот такого: https://www.reddit.com/r/programming/comments/5pwgtn/hash_map_benchmark_stdunordered_map_seems_very/

Большая статья с бенчмарками: https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html
Re[7]: Основные минусы плюсов...
От: CRT  
Дата: 25.07.23 17:04
Оценка: +2
Здравствуйте, so5team, Вы писали:

CRT>>Для выводы обычных строк, символов, чисел printf удобней


S>Расскажите эту байку кому-нибудь помоложе.

Конечно, ведь
std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;
гораздо удобней чем
printf("0x%04x\n", 0x424);
Отредактировано 25.07.2023 17:05 CRT . Предыдущая версия .
Re: Основные минусы плюсов...
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 25.07.23 18:10
Оценка: 3 (1) +1 :)
Здравствуйте, 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.


//машины ответ
Re[4]: Основные минусы плюсов...
От: CreatorCray  
Дата: 25.07.23 20:16
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Кстати STL далеко не самое ужасное, что есть в C++.

STL это не в С++, это для С++. Никто им пользоваться не заставляет.

vsb>Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.

А этим извращением разве кто то всё ещё пользуется?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: Основные минусы плюсов...
От: CreatorCray  
Дата: 25.07.23 20:16
Оценка:
Здравствуйте, so5team, Вы писали:

S>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?

Ты не поверишь но да!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Основные минусы плюсов...
От: CreatorCray  
Дата: 25.07.23 20:16
Оценка:
Здравствуйте, so5team, Вы писали:

S>это был прям таки прорыв.

Разишо канализации.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: Основные минусы плюсов...
От: CreatorCray  
Дата: 25.07.23 20:16
Оценка:
Здравствуйте, CRT, Вы писали:

CRT>Для выводы обычных строк, символов, чисел printf удобней

printf-like — да. Но сам сишный printf таки нет.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 04:20
Оценка:
Здравствуйте, CRT, Вы писали:

S>>Расскажите эту байку кому-нибудь помоложе.

CRT>Конечно, ведь
CRT>std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;

Это, вообще-то говоря, необязательно. И запросто может быть преобразовано к чему-то вроде:
std::cout << format("0x04{}", 0x424) << std::endl;


CRT>гораздо удобней чем
CRT>printf("0x%04x\n", 0x424);
CRT>


Во-первых, примеры не эквивалентны. Вариант с printf-ом требует еще одну строчку с вызовом fflush.

Во-вторых, давайте пройдемся по тонкому льду:

Делай раз:
#if PLATFORM_ONE
typedef int value_t;
#else
typedef unsigned long value_t;
#endif

void show(value_t v) {
  printf("0x04x\n", v);
}


Делай два:
typedef double value_t;

void show(value_t v) {
  printf("0x04x\n", v); // Нет, компиляторы далеко не всегда проверяли форматную строку.
}


Делай три:
void as_string(unsigned v) {
  char buf[7]; // 0x1234\0
  sprintf(buf, "0x04x", v);
  ...
}
...
as_string(UINT_MAX);
Re[5]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 04:22
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

vsb>>Кстати STL далеко не самое ужасное, что есть в C++.

CC>STL это не в С++, это для С++. Никто им пользоваться не заставляет.

С момента фиксации STL в стандарте это C++.

CC>А этим извращением разве кто то всё ещё пользуется?


Да. За пределами яблочного ядра есть жизнь. А у вас нет прерогативы на единственно правильное мнение.
Re[8]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 04:26
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>PS. Неужели проще самому бабахаться с UTF-8, нежели воспользоваться ICU?

CC>Ты не поверишь но да!

Поверю, сам простую работу с UTF-8 реализовывал. Но там на уровне проверки корректности последовательности или трансляции из UCS-16 в UTF-8 на Windows.

Если же нужно, например, регистронезависимую сортировку сделать, то лучше уж ICU задействовать.
Re[6]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 04:27
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>это был прям таки прорыв.

CC>Разишо канализации.

Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.
Re[9]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 05:15
Оценка:
Здравствуйте, so5team, Вы писали:

S>Это, вообще-то говоря, необязательно. И запросто может быть преобразовано к чему-то вроде:

S>
S>std::cout << format("0x04{}", 0x424) << std::endl;
S>


Всё ещё мрак и кошмар.

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, значит пора закрыть эту страницу.
Всем пока
Re[7]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 05:15
Оценка:
Здравствуйте, so5team, Вы писали:

S>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.

В плюсах можно было. Я делал типобезопасный printf-like вывод через использование оператора запятая.
С появлением вариадиков тут же переписал на них, стало на порядок удобнее.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 05:15
Оценка: -1
Здравствуйте, so5team, Вы писали:

S>С момента фиксации STL в стандарте это C++.

Всё, что может быть полностью написано на С++ не является частью языка.
Что бы там себе теоретики не фантазировали.

CC>>А этим извращением разве кто то всё ещё пользуется?

S>Да. За пределами яблочного ядра есть жизнь.
Выдыхай, бобёр! Хочешь пользоваться отвратительно спроектированным интерфейсом — ветер в спину.

S> А у вас нет прерогативы на единственно правильное мнение.

У меня есть прерогатива на собственный опыт, от ядер до финансового софта.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Основные минусы плюсов...
От: Vzhyk2  
Дата: 26.07.23 05:15
Оценка: +1
vsb>Это от наличия опыта. И наличия опыта работы с библиотеками в других языках. Кстати STL далеко не самое ужасное, что есть в C++. Больше всего меня ужасает ввод-вывод. Это же надо догадаться было — перегрузить операторы битового сдвига. Какая-то шизофрения.
Это ты valarray еще не трогал.
Re[10]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 05:18
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

S>>Это, вообще-то говоря, необязательно. И запросто может быть преобразовано к чему-то вроде:

S>>
S>>std::cout << format("0x04{}", 0x424) << std::endl;
S>>


CC>Всё ещё мрак и кошмар.


Тем не менее, это можно было сделать еще в "Си с классами".

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 вывести объект собственного типа?
Re[6]: Основные минусы плюсов...
От: Vzhyk2  
Дата: 26.07.23 05:18
Оценка:
vsb>Например чтобы использовать человеческий UTF-8. А не непойми что.
https://icu.unicode.org тебе в помощь. Бо сам unicode еще то безумие.
Re[8]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 05:19
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.

CC>В плюсах можно было.

Давайте конкретнее: как?

CC>Я делал типобезопасный printf-like вывод через использование оператора запятая.


Объекты пользовательских типов посредством чего выводились?
Re[7]: Основные минусы плюсов...
От: Vzhyk2  
Дата: 26.07.23 05:21
Оценка:
CRT>>Для выводы обычных строк, символов, чисел printf удобней
S>Расскажите эту байку кому-нибудь помоложе.
Те кто помоложе часто любят совать пальцы в розетки, когда взрослеют, то понимают, что не нужно это делать.
Re[7]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 05:23
Оценка: +1 :)
Здравствуйте, CreatorCray, Вы писали:

S>>С момента фиксации STL в стандарте это C++.

CC>Всё, что может быть полностью написано на С++ не является частью языка.
CC>Что бы там себе теоретики не фантазировали.

Частью языка является то, что зафиксировано в стандарте.

Чтобы там практики с "прерогативой на собственный опыт" не фантазировали.

CC>>>А этим извращением разве кто то всё ещё пользуется?

S>>Да. За пределами яблочного ядра есть жизнь.
CC>Выдыхай, бобёр! Хочешь пользоваться отвратительно спроектированным интерфейсом — ветер в спину.

Предложите лучше.

А да, у вас же есть мега альтернатива fmtlib, которую никто никогда не увидит.

S>> А у вас нет прерогативы на единственно правильное мнение.

CC>У меня есть прерогатива на собственный опыт, от ядер до финансового софта.

Если включить мозги (хотя мозги вряд ли могли бы позволить ЧСВ раздуться до такого уровня), то можно увидеть, что ваш опыт у вас никто не отнимает, а вот над желанием высказать единственно правильное мнение скоро будут откровенно стебаться.
Re[11]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 05:57
Оценка: +2
Здравствуйте, so5team, Вы писали:

CC>>С появлением вариадиков я вообще могу написать вот такое:

CC>>
CC>>crprintf (L"%s %f %i", 0.5, 123, -PI);
CC>>

CC>>И оно напечатает "0.5 123 -3"

Кстати говоря, за то, что дабл выводится там, где требуется строка, а вещественное значение неявно преобразуется к целому (да и наоборот), руки нужно отрывать. Подобные вещи должны приводить к ошибкам, желательно времени компиляции.
Re[11]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 06:09
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[9]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 06:09
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.

CC>>В плюсах можно было.

S>Давайте конкретнее: как?

Да так же. Просто не через operator<<

S>Объекты пользовательских типов посредством чего выводились?

Мне юзерская расширяемость нафиг не надо была, задача была полностью заменить printf. Впрочем любой новый тип добавляется туда элементарно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 06:09
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[7]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 06:09
Оценка: +1
Здравствуйте, Vzhyk2, Вы писали:

V>Бо сам unicode еще то безумие.

+100500!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[12]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 06:18
Оценка:
Здравствуйте, so5team, Вы писали:

S>дабл выводится там, где требуется строка

А что должно выводиться? Какое будет строковое представление для double?

S> а вещественное значение неявно преобразуется к целому

Выводится тот тип, что был попрошен в форматной строке, ибо она задаёт отображение.

S> Подобные вещи должны приводить к ошибкам, желательно времени компиляции.

Форматная строка ж не обязательно фиксирована в момент компиляции.
И если там что то было неправильно, то желательно в логах увидеть хоть какое то разумное значение а не просто "нишмагла".
Впрочем у меня таки ругается если в тот же "%i" передать строку.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Основные минусы плюсов...
От: Константин Б. Россия  
Дата: 26.07.23 07:13
Оценка: +1
Здравствуйте, velkin, Вы писали:

У меня неловкий вопрос. Вот это всё всеръёз было или я слишком тонкий сарказм не уловил?
Re[2]: Основные минусы плюсов...
От: Alekzander  
Дата: 26.07.23 07:29
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>2. Адекватная стандартная библиотека. В С++ она просто максимально мегаужасна. Там просто всё плохо, от начала до конца.


Мне иногда кажется, что в Villain Pub собрались собрались самые ужасные суперзлодеи — Палпатин, Джокер, Танос, Волдеморт и Александр Александрович Степанов — и стали её проектировать:

— А давай вместо Add() назовём метод push_back()?
— Давай! И ещё отделим алгоритмы от данных, вынеся их в отдельные классы! И пусть remove не remov'ит, а erase — не eras'ит.
— MWAHAHAHAHA! Ты просто гений злодейства!!!
Отредактировано 26.07.2023 7:37 Alekzander . Предыдущая версия .
Re[12]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 07:35
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Тем не менее, это можно было сделать еще в "Си с классами".

CC>Можно было сделать удобнее.

Можно было сделать по всякому, суть в том, что не обязательно повседневное использование C++ должно было выглядеть вот так:
std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;


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;") объект собственного типа?

Да легко:
class my_bcd_4 {
  unsigned char data[4];
public:
  ...
  unsigned to_unsigned() const;
};

ostream & operator<<(ostream & to, const my_bcd_4 & what) {
  return (to << what.to_unsigned());
}
...
my_bcd_4 v;
...
std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << v << std::endl;


CC>Впрочем если припрёт то всё что надо это определить функцию в namespace которая будет принимать контекст и const& на нужный тип и внутри сама форматировать его в строку.


Ну вот в fmtlib пошли по этому пути, только там не функцию, а специализацию шаблона нужно определять. И кода нужно понаписать поболее, чем в случае с operator<<
Re[10]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 07:40
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>>>Интересно было бы послушать, как можно было бы сделать в 1980-х вывод произвольных пользовательских типов без перегрузки операторов, с сохранением безопасности по типам.

CC>>>В плюсах можно было.

S>>Давайте конкретнее: как?

CC>Да так же. Просто не через operator<<

Ну так как?

Напомню, что в C++ образца 1983-го года не было шаблонов. И единственный способ сделать функцию с переменным количеством аргументов был в использовании сишных va_args.

Можно было, наверное, сделать функцию print(stream, arg), которую можно было бы перегружать для пользовательских типов. Но тогда вместо:
cout << "Elapsed " << sec << "second(s)" << endl;

пришлось бы писать:
print(cout, "Elapsed ");
print(cout, sec);
print(cout, "second(s)" );
flush(cout);


Что ничуть не лучше. По крайней мере точно нашлись бы люди, которые от этого плевались бы не меньше, чем другие до сих пор плюются от operator<<.

S>>Объекты пользовательских типов посредством чего выводились?

CC>Мне юзерская расширяемость нафиг не надо была, задача была полностью заменить printf.

А другим (включая меня) надо было.
Re[9]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 07:47
Оценка:
Здравствуйте, 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.
Re[13]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 07:52
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>дабл выводится там, где требуется строка

CC>А что должно выводиться?

Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.

S>> а вещественное значение неявно преобразуется к целому

CC>Выводится тот тип, что был попрошен в форматной строке, ибо она задаёт отображение.

Округлять вещественное до целого можно по разному, пользователь должен задавать это явным способом, неявных преобразований в C++ и так выше крыши, к сожалению (хотелось бы сильно поменьше этих самых неявных преобразований).

S>> Подобные вещи должны приводить к ошибкам, желательно времени компиляции.

CC>Форматная строка ж не обязательно фиксирована в момент компиляции.

Значит должна быть ошибка в run-time.

PS. Это все к разговору о том, что у разных людей разные требования и взгляды на то, как "нормально".
Re[11]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 08:11
Оценка:
Здравствуйте, so5team, Вы писали:

S>Во-вторых, как с помощью мифического crprintf вывести объект собственного типа?


Релизовать интерфейс наподобие

class printable {
public:
  virtual void print(output_stream stream) = 0;
};


Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.
Re[12]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 08:13
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Релизовать интерфейс наподобие


vsb>
vsb>class printable {
vsb>public:
vsb>  virtual void print(output_stream stream) = 0;
vsb>};
vsb>


vsb>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.


И получаем ООП головного мозга на ровном месте.
Re[13]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 08:26
Оценка:
Здравствуйте, so5team, Вы писали:

vsb>>Релизовать интерфейс наподобие


vsb>>
vsb>>class printable {
vsb>>public:
vsb>>  virtual void print(output_stream stream) = 0;
vsb>>};
vsb>>


vsb>>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.


S>И получаем ООП головного мозга на ровном месте.


Я бы не назвал это ООП. Ну в любом случае мне такой подход нравится куда больше, чем шаблоны. Хотя бы потому, что он нормально работает с раздельной компиляцией.
Re[14]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 08:29
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>>>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.


S>>И получаем ООП головного мозга на ровном месте.


vsb>Я бы не назвал это ООП.


И что же это? Какой-то деградировавший ФП?

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


У вас C++ные проекты компилируются по 8 часов?
Re[15]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 08:34
Оценка:
Здравствуйте, so5team, Вы писали:

vsb>>>>Если интерфейс реализовывать не хочется или не получается, написать обёртку для класса, реализующую этот интерфейс.


S>>>И получаем ООП головного мозга на ровном месте.


vsb>>Я бы не назвал это ООП.


S>И что же это? Какой-то деградировавший ФП?


ООП в моём понимании это наследование классов с данными. Реализация интерфейса на ООП не тянет. Я не знаю, как её назвать, но к примеру в Go или Rust эта модель есть, а полновесного ООП нет. Наверное можно назвать это ООП здорового человека.

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


S>У вас C++ные проекты компилируются по 8 часов?


У меня травма детства, когда я видел C++ проект от "деда", который компилировался за долю секунды и при этом в нём было несколько десятков тысяч строк. Там использовалась только C-шная библиотека и шаблоны очень редко. Когда простой хелло-ворлд с STL компилируется на железе в 5 раз мощней — несколько секунд, я понимаю, что в раздельной компиляции есть свой смысл. И C++ с его подходом с повсеместными шаблонами, возможно, ушёл немножко не туда.

Впрочем может быть современные компиляторы научились компилировать шаблоны один раз? Плохо представляю, как это может работать, но вроде были какие-то precompiled headers, которые я так и не смог "завести".
Отредактировано 26.07.2023 8:35 vsb . Предыдущая версия . Еще …
Отредактировано 26.07.2023 8:35 vsb . Предыдущая версия .
Re[7]: Основные минусы плюсов...
От: CRT  
Дата: 26.07.23 08:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:



CRT>>Для выводы обычных строк, символов, чисел printf удобней

CC>printf-like — да. Но сам сишный printf таки нет.

сишный printf с его языком форматирования гораздо удобней чем cout, но опаснее. Но я про удобство.
Хотя некоторые компиляторы умеют проверять аргументы на соответствие формату в printf
Re[8]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 08:37
Оценка: +1
Здравствуйте, CRT, Вы писали:

CRT>>>Для выводы обычных строк, символов, чисел printf удобней

CC>>printf-like — да. Но сам сишный printf таки нет.

CRT>сишный printf с его языком форматирования гораздо удобней чем cout, но опаснее. Но я про удобство.

CRT>Хотя некоторые компиляторы умеют проверять аргументы на соответствие формату в printf

Вроде в C++ уже должно хватать возможностей, чтобы реализовать интерфейс printf безопасно? Ну может не с ошибкой компиляции, но по крайней мере без порчи стека и прочих спецэффектов при неправильном формате.
Re[11]: Основные минусы плюсов...
От: CRT  
Дата: 26.07.23 08:43
Оценка:
Здравствуйте, so5team, Вы писали:

S>Напомню, что в C++ образца 1983-го года не было шаблонов.


а в образце 1991 были
а STL в 1994 появилась
в конце 90-х шаблоны были довольно прилично развиты.

а этот format() когда появился?
Re[16]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 08:45
Оценка: 1 (1)
Здравствуйте, vsb, Вы писали:

vsb>ООП в моём понимании это наследование классов с данными. Реализация интерфейса на ООП не тянет.


Тем не менее. Здесь классический ООП-ный runtime-полиморфизм.

А если добавить, что для printable потребуется не один виртуальный метод, а два (первый нужен для хранения результатов разбора форматной строки), то выяснится, что в наследнике printable будут какие-то данные, а это уже и инкапсуляция в придачу.

Посему это именно что ООП.

vsb>У меня травма детства, когда я видел C++ проект от "деда", который компилировался за долю секунды и при этом в нём было несколько десятков тысяч строк. Там использовалась только C-шная библиотека и шаблоны очень редко. Когда простой хелло-ворлд с STL компилируется на железе в 5 раз мощней — несколько секунд, я понимаю, что в раздельной компиляции есть свой смысл. И C++ с его подходом с повсеместными шаблонами, возможно, ушёл немножко не туда.


C++ пока еще очень сдерживает модель компиляции, унаследованная из C: одни и те же заголовочные файлы приходится парсить помногу раз. Повсеместное пришествие поддержки модулей из C++20 должно улучить ситуацию. Ускорить где-то на 1/3

PS. Цифра 1/3 взята, по сути, с потолка. Когда-то замерял затраты компилятора на обработку cpp-файла с активным использованием шаблонов. Там стадия препроцессинга как-раз треть занимала. Остальное -- это кодогенерация после инстанциирования шаблонов.
Re[12]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 08:49
Оценка:
Здравствуйте, 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 был написан.
Re: Основные минусы плюсов...
От: Константин Б. Россия  
Дата: 26.07.23 08:55
Оценка: +1 :))
Здравствуйте, Shmj, Вы писали:

S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.


S>А вот почему на Java/C#/Dart/etc. — писать проще и комфортнее? Есть ли однозначный ответ?


Есть. C++ расчитан на мифических программистов которые никогда не допускают ошибок. А другие языки наоборот на то что программисты могут и будут ошибаться.
Re[17]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 09:05
Оценка:
Здравствуйте, so5team, Вы писали:

S>А если добавить, что для printable потребуется не один виртуальный метод, а два (первый нужен для хранения результатов разбора форматной строки)


Не понял. Предполагается, что метод print просто печатает текущий объект в output_stream посимвольно.

Более простой вариант — сделать вместо этого метод to_string(). Но тут придётся между печатью хранить строку. В большинстве языков делают именно так, хотя мне это кажется не оптимальным и даже менее удобным для реализации.

Т.е. используется это так: printf("%s", my_obj). И printf уже вызовет у my_obj метод print, которым он напечатает себя в stdout.

Использовать что-либо кроме %s для печати своих объектов мне кажется странной идеей, но можно и это сделать, просто в метод print передавать вторым парамметром запрошенный модификатор форматирования. Наверное это может иметь смысл для своих числовых типов.
Re[13]: Основные минусы плюсов...
От: CRT  
Дата: 26.07.23 09:07
Оценка:
Здравствуйте, so5team, Вы писали:


S>Смотря где. В VC++ нормальная поддержка шаблонов из C++98 появилась только в VS2003.


Тоже давным давно уже


CRT>>а этот format() когда появился?


S>После принятия C++11, т.к. ему вариадики нужны были.


а cppreference.com пишет C++20

в стандарте его не было
Re[18]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 09:16
Оценка:
Здравствуйте, 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, то и всякие ошибки с форматом выявляются именно там.

Выделенное жирным является сутью этой дискуссии: кому-то кажется одно, но с большой долей вероятности этот кто-то даже не представляет, что кажется и что нужно другим людям.
Re[14]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 09:18
Оценка:
Здравствуйте, 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.
Re[15]: Основные минусы плюсов...
От: CRT  
Дата: 26.07.23 09:23
Оценка:
Здравствуйте, so5team, Вы писали:


CRT>>а cppreference.com пишет C++20


CRT>>в стандарте его не было


S>Речь не про std::format, а про fmtlib из которой std::format и появился. Эта самая fmtlib стала возможной только после принятия C++11.


Так я о чем и говорю что в стандарт они его добавили недавно. То есть частью языка (если считать стандартные библиотеки частью языка), он стал совсем недавно
Re[19]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 09:27
Оценка: +2
Здравствуйте, so5team, Вы писали:

S>Выделенное жирным является сутью этой дискуссии: кому-то кажется одно, но с большой долей вероятности этот кто-то даже не представляет, что кажется и что нужно другим людям.


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

Поэтому когда я говорю, что мне кажется, что использовать что-то кроме %s для пользовательских типов не нужно, в основном это вызвано тем, что я не знаю ни одного языка, где это было бы. В Java есть String.format, в нём %s вызывает toString() у пользовательского объекта. В Objective C есть %@, там тоже какой-то подобный метод. В Go то же самое. И если вдруг понадобится какой-то нестандартный метод для форматирования, достаточно просто написать метод to_custom_string(), возвращающий строку или же написать объект-обёртку, если этот объект такой гигантский, что промежуточная строка ну никак не подходит.

Допускаю, что на этих языках есть люди, которые страшно страдают от того, что не могут указать свой формат для форматирования прямо в строке. Но мне кажется, что таких людей мало. А людей, которые продуктивно используют простую и понятную систему — много.
Re[16]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 09:41
Оценка:
Здравствуйте, CRT, Вы писали:

CRT>Так я о чем и говорю что в стандарт они его добавили недавно. То есть частью языка (если считать стандартные библиотеки частью языка), он стал совсем недавно


Э... А как это меняет тот факт, что в 1980-х в C++ смогли сделать только безопасный по типам operator<<?
Re[20]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 09:45
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Поэтому когда я говорю, что мне кажется, что использовать что-то кроме %s для пользовательских типов не нужно, в основном это вызвано тем, что я не знаю ни одного языка, где это было бы.


Это логика из категории "если миллионы мух"...

C++ очень сильно отличается от Java или Objective C.
Например, в нем ООП не обязательно.
Следовательно, нет какой-то вершины иерархии, вроде Object, в которую можно было зафигачить toString.

Кроме того, в C++ многие упарываются по производительности и накладным расходам.
И если навязать подход, когда парсинг только в run-time, для вывода нужно вызывать виртуальный toString, а этот toString еще и вернет std::string с динамической аллокацией внутри, то подобное решение очень быстро закидают гнилыми помидорами.
Re[21]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 10:37
Оценка:
Здравствуйте, 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, поэтому динамическая аллокация тут не обязательна.

А виртуальный вызов? Ну это же ввод-вывод. Это не то, что будет тормозить.
Re[22]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 11:01
Оценка: +1
Здравствуйте, 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>А виртуальный вызов? Ну это же ввод-вывод. Это не то, что будет тормозить.


Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.
Re[23]: Основные минусы плюсов...
От: vsb Казахстан  
Дата: 26.07.23 11:55
Оценка:
Здравствуйте, so5team, Вы писали:

vsb>>А виртуальный вызов? Ну это же ввод-вывод. Это не то, что будет тормозить.


S>Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.


А текущая система iostreams — она как в таком раскладе работает? Много слышал про её тормоза, сам не мерял, правда.
Re[24]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 12:08
Оценка:
Здравствуйте, vsb, Вы писали:

S>>Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.


vsb>А текущая система iostreams — она как в таком раскладе работает? Много слышал про её тормоза, сам не мерял, правда.


Да, говорят, что тормозит. Например, на github-е fmtlib есть такие результаты:

libc++(std::ostream) -> 2.49s
{fmt} 9.1 (fmt::print) -> 0.74

Но, помнится по рассказам тех, кто в std::ostream погружался, там куча заморочек с локализацией, что добавляет тормозов.
В принципе, можно свою реализацию ostream-а сделать, где бы лишнего не было. Но это непросто, насколько я помню.
Re[14]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>дабл выводится там, где требуется строка

CC>>А что должно выводиться?
S>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.

А вот представь что это логгинг в ветке, которая редко выполняется. В итоге мы знаем что что то пошло не так но вообще не знаем ничего больше.
Так что на порядки лучше получить не совсем правильно отформатированные данные чем совсем ничего.

S>Округлять вещественное до целого можно по разному, пользователь должен задавать это явным способом

См выше.

S>Значит должна быть ошибка в run-time.

Вывод сообщения об ошибке вернул ошибку и ничего не вывел — это проблема куда хуже.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[8]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, CRT, Вы писали:

CRT>сишный printf с его языком форматирования гораздо удобней чем cout, но опаснее.

Нынче (да и раньше тоже) легко на С++ делался printf с тем же языком только безопасный.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, so5team, Вы писали:

S>Можно было, наверное, сделать функцию print(stream, arg), которую можно было бы перегружать для пользовательских типов.


Просто перегрузи оператор запятая для класса форматтера, который вернёт основное тело printf_core(const char* fmt)
Потом через вариадик-макрос делается обёртка, которая строку форматирования передаёт в функцию, которая возвращает объект форматтера а все аргументы __VA_ARGS__ автоматом туда добавит через запятую, ну и заворачивает это всё в скобочки чтоб не вылезло.
Оператор запятая там работает абсолютно так же как и operator<<
Вариадик темплейты это всё делают банально сильно аккуратнее, без необходимости перегрузки именно оператора, тупо функцию форматтер добавляешь для нужного типа.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, so5team, Вы писали:

CC>>Да вон даже в стандарте std::format наконец предложили. Только он всё равно какой то корявый у них вышел.

S>Так в том-то и фокус: однозначно лучше не получилось.
Да потому я и не люблю стандартную библиотеку — они там гонятся за тем, чтоб сделать её максимально generic и получается что то недоубоваримое. Всё такое расширяемое, такое гЫбкое что на ногах не стоит.

S>Как только вы ее выпустите в свет

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

S>Т.е. эпитеты "отвратительно спроектированный интерфейс"

А лепить цепочку через << это и есть отвратительный интерфейс. Ибо это кошмарно неудобно, особенно на фоне других решений.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, CRT, Вы писали:

CRT>а cppreference.com пишет C++20

CRT>в стандарте его не было

Это уже вопрос к аффтарам, чего они так долго чесались. У меня с появления ранней поддержки вариадиков компиляторами это уже как часы работало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Впрочем может быть современные компиляторы научились компилировать шаблоны один раз? Плохо представляю, как это может работать, но вроде были какие-то precompiled headers, которые я так и не смог "завести".


ICC давно умеет в автоматические precompiled headers для которых вообще ничего врукопашную делать не надо. Работает замечательно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 16:00
Оценка:
Здравствуйте, so5team, Вы писали:

S>C++ пока еще очень сдерживает модель компиляции, унаследованная из C: одни и те же заголовочные файлы приходится парсить помногу раз.

Давно решено на уровне компилятора в нормальных компиляторах. Результаты кэшируются.

S> Повсеместное пришествие поддержки модулей из C++20 должно улучить ситуацию. Ускорить где-то на 1/3

Да уже лет 10 как проблемы на практике нету
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[15]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 16:29
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

S>>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.


CC>А вот представь что это логгинг в ветке, которая редко выполняется.


Вот поэтому compile-time проверки гораздо лучше run-time.

CC>Так что на порядки лучше получить не совсем правильно отформатированные данные чем совсем ничего.


Вообще-то говоря еще на порядки лучше иметь протестированные даже редко выполняемые ветки. Иначе там проблемы похлеще неправильного логирования могут жить.

S>>Округлять вещественное до целого можно по разному, пользователь должен задавать это явным способом

CC>См выше.

Если не будет неявных преобразований типа, то не придется ссылаться "См выше".
Re[14]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 16:32
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

CC>Для printf-like достаточно было оператора запятая.

Так речь об операторе точка или операторе запятая?

Если об операторе запятая, то мы меняем шило на мыло. Точнее мыло на шило, ибо, подозреваю, на это шило бы напарывались бы побольше.

S>>>>Во-вторых, как с помощью мифического crprintf вывести объект собственного типа?

CC>>>А где в исходнои примере ("std::cout << "0x" << std::hex << std::setfill('0') << std::setw(4) << 0x424 << std::endl;") объект собственного типа?
S>>Да легко:
CC>Ты не понял вопроса.

Если вопрос важен, то может его переформулируете, чтобы было понятнее?
Re[12]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 16:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Можно было, наверное, сделать функцию print(stream, arg), которую можно было бы перегружать для пользовательских типов.


CC>Просто перегрузи оператор запятая для класса форматтера, который вернёт основное тело printf_core(const char* fmt)

CC>Потом через вариадик-макрос делается обёртка, которая строку форматирования передаёт в функцию, которая возвращает объект форматтера а все аргументы __VA_ARGS__ автоматом туда добавит через запятую, ну и заворачивает это всё в скобочки чтоб не вылезло.

__VA_ARGS__, если верить беглому гуглению, появился в C99, т.е. это уже 1990-е годы. А operator<< берет свое начало в первой половине 1980-х.

Так что незачет.
Re[18]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 26.07.23 16:37
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>> Повсеместное пришествие поддержки модулей из C++20 должно улучить ситуацию. Ускорить где-то на 1/3

CC>Да уже лет 10 как проблемы на практике нету

Ну-ну, ну-ну... Я не самый большой любитель упарываться шаблонной магией, но местами компиляция одного (всего одного) .cpp файла в течении 10-15 секунд -- это вполне себе обыденно.
Re[2]: Основные минусы плюсов... лично для меня
От: Carc Россия http://www.amlpages.com/home.php
Дата: 26.07.23 17:52
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>а) язык реально очень большой.

LVV>б) стандартная библиотека напротив сильно маленькая.
LVV>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
LVV>Это когда практически все системы стали с сетевым взаимодействием.
АСE: ADAPTIVE Communication Environment
кроссплатформенная C++-либа для низкоуровневого сетевого программирования.

PS: опыта личного, прям вот ручками, прям вот с так называемыми «кодами» у меня нет, прям вот чтобы в живом проекте, по делу, «Чтобы коды прям с утра, и тряслись и трепетали..» (С) — да такого не дошло как-то.

Но несколько лет назад прочитал книжку на русском про ACE. В целом мне понравилась (сама концепция ACE, да и книга толково написана. Название манускрипта с ходу не скажу, мне надо на полке его поискать...).
Aml Pages Home
Отредактировано 26.07.2023 17:59 Carc . Предыдущая версия . Еще …
Отредактировано 26.07.2023 17:53 Carc . Предыдущая версия .
Re[3]: Основные минусы плюсов... лично для меня
От: Carc Россия http://www.amlpages.com/home.php
Дата: 26.07.23 17:57
Оценка:
Здравствуйте, Carc, Вы писали:

C>Здравствуйте, LaptevVV, Вы писали:


LVV>>а) язык реально очень большой.

LVV>>б) стандартная библиотека напротив сильно маленькая.
LVV>>Например, до сих пор в стандартной библиотеке нет ничего про сетевое программирование
LVV>>Это когда практически все системы стали с сетевым взаимодействием.
АСE: ADAPTIVE Communication Environment
кроссплатформенная C++-либа для низкоуровневого сетевого программирования.

PS: опыта личного, прям вот ручками, прям вот с так называемыми «кодами» у меня нет, прям вот чтобы в живом проекте, по делу, «Чтобы коды прям с утра, и И тряслись и трепетали..» (С) — да такого не дошло как-то.

Но несколько лет назад прочитал книжку на русском про ACE. В целом мне понравилась (сама концепция ACE, да и книга толково написана. Название манускрипта с ходу не скажу, мне надо на полке его поискать...).
Aml Pages Home
Re[3]: Основные минусы плюсов... лично для меня
От: LaptevVV Россия  
Дата: 26.07.23 19:38
Оценка: 1 (1)
Спасибо. У меня эта книжка есть.
Двухтомник из серии C++ in Depth
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[16]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 19:44
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.

CC>>А вот представь что это логгинг в ветке, которая редко выполняется.
S>Вот поэтому compile-time проверки гораздо лучше run-time.
Не не всегда применимы

CC>>Так что на порядки лучше получить не совсем правильно отформатированные данные чем совсем ничего.

S>Вообще-то говоря еще на порядки лучше иметь протестированные даже редко выполняемые ветки. Иначе там проблемы похлеще неправильного логирования могут жить.
Это ортогонально.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[15]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 19:44
Оценка:
Здравствуйте, so5team, Вы писали:

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

CC>>Для printf-like достаточно было оператора запятая.
S>Так речь об операторе точка или операторе запятая?
Оператор запятая необходим чтоб замакрить это всё чтоб выглядело как обычный printf, ибо __VA_ARGS__ вставляет аргументы именно через запятую.

CC>>Ты не понял вопроса.

S>Если вопрос важен, то может его переформулируете, чтобы было понятнее?
Мне уже и так скучно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: Основные минусы плюсов...
От: CreatorCray  
Дата: 26.07.23 19:44
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[3]: Основные минусы плюсов...
От: velkin Удмуртия https://kisa.biz
Дата: 26.07.23 22:33
Оценка: +1 :)
Здравствуйте, Константин Б., Вы писали:

КБ>У меня неловкий вопрос. Вот это всё всеръёз было или я слишком тонкий сарказм не уловил?


Я об этом писал в
1. Независимость программ от фреймворков
2. Катастрофа ООП и многомерные модели данных
3. Почему программисты прошлого были умнее

Ещё раз процитирую.

Линус Торвальдс о С++

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++.

Вот так у нас появилась целевая аудитория под каждый язык программирования. Каждый язык имеет своё предназначение и это хорошо. Зачем нам универсальный инструмент, в этом нет смысла. Самое главное, что выучить только одну область такую как формошлёпство, веб или даже битомолки проще, чем все сразу. Потому одни языки программирования проще других.
Re[4]: Основные минусы плюсов...
От: CreatorCray  
Дата: 27.07.23 00:28
Оценка: 1 (1) +1
Здравствуйте, velkin, Вы писали:

V>Ещё раз процитирую.

V>Линус Торвальдс

Вот как раз мнение этого пЫнгвина касательно чего угодно не интересует совершенно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Основные минусы плюсов...
От: velkin Удмуртия https://kisa.biz
Дата: 27.07.23 00:38
Оценка:
Здравствуйте, CreatorCray, Вы писали:

V>>Ещё раз процитирую.

V>>Линус Торвальдс
CC>Вот как раз мнение этого пЫнгвина касательно чего угодно не интересует совершенно.

А как тебе такое Илон Маск.

https://www.youtube.com/watch?v=JbovJbKALzA
Re[6]: Основные минусы плюсов...
От: CreatorCray  
Дата: 27.07.23 04:17
Оценка: +1
Здравствуйте, velkin, Вы писали:

V>https://www.youtube.com/watch?v=JbovJbKALzA

Ты правда думаешь что я про этот его высер не в курсе?
Надо же nVidia не захотела плясать под его хотелки, какая беда! Не хотят свой код отдавать под вирусную GPL — вот жеж сволочи какие!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 27.07.23 04:34
Оценка: +1 :)
Здравствуйте, CreatorCray, Вы писали:

S>>>>Должна быть ошибка, ибо если ждали строку, а получили double, то что-то явно пошло не так.

CC>>>А вот представь что это логгинг в ветке, которая редко выполняется.
S>>Вот поэтому compile-time проверки гораздо лучше run-time.
CC>Не не всегда применимы

Если проблемы не ловятся в compile-time, то остается только тестировать.

Ну или убеждать себя в том, что написав %s вместо %e все равно что-то да выведется и это хорошо.
Re[14]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 27.07.23 04:39
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>__VA_ARGS__, если верить беглому гуглению, появился в C99, т.е. это уже 1990-е годы. А operator<< берет свое начало в первой половине 1980-х.


CC>Можно без него, но тогда использование выглядеть будет странноватее:

CC>
CC>printflike ("%u %i %f"), a, b, c;
CC>


Ну и получаем, что:

* перегрузка оператора все равно нужна, так что дальше лишь дело вкуса: кому-то не нравится перегрузка operator<<, кому-то перегрузка operator,;
* придется объяснять новичкам, что же делает эта конструкция и почему она так отличается от обычного вызова функции;
* непонятно зачем городить для простых случаев форматную строку со спецификаторами типов, если в C++ мы и так точно знаем типы параметров;
* непонятно как встраивать в этот механизм поддержку вывода для пользовательских типов.

Так что, как и было сказано ранее, шило на мыло. Для хорошего решения в начале 1980 в C++ просто не было достаточных выразительных средств.
Re[18]: Основные минусы плюсов...
От: CreatorCray  
Дата: 27.07.23 04:55
Оценка:
Здравствуйте, so5team, Вы писали:

S>Если проблемы не ловятся в compile-time, то остается только тестировать.

А вода — мокрая!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 27.07.23 05:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Если проблемы не ловятся в compile-time, то остается только тестировать.

CC>А вода — мокрая!

Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая.

Но если кому-то printf-like стиль настолько нравится и есть возможность апеллировать к афигенному опыту, то все остальное будет уродским и извращенным, да.
Re[4]: Основные минусы плюсов...
От: Константин Б. Россия  
Дата: 27.07.23 06:19
Оценка: +2
Здравствуйте, velkin, Вы писали:

V>Фактически я сейчас говорю о позиционировании в маркетинге.


Ну вот это все объясняет. Вместо того чтобы рассматривать что такое С++ на самом деле, ты рассматриваешь какие-то стереотипы, которые еще и не общеприняты.
Соответственно и проблемы С++ идентифицированы не верно.
Re: Основные минусы плюсов...
От: ArtDenis Россия  
Дата: 27.07.23 06:36
Оценка: 2 (1) +1 :)
Здравствуйте, Shmj, Вы писали:

S>Как вы думаете?


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

Во вторых, даже в той области, для которой плюсы создавались, у современных плюсов есть проблемы. C++ (и ему подобные) — это языки, которые надо "уметь готовить". Поэтому вместо того, чтобы концентрироваться на задачах бизнеса, командам на с++ приходится заниматься поиском особых поваров, которые 1) никогда не используют вредных продуктов голых указателей, new, delete, 2) знают наизусть Великую поварскую книгу хотя бы Effective Modern C++, 3) разбираются в молекулярной кухне современных стандартах, 4) всегда придерживаются строгого порядка добавления ингредиентов стиля программирования (чтобы их код могли понять другие) и т.п. Ну вы понели ))
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re: Основные минусы плюсов...
От: rg45 СССР  
Дата: 27.07.23 07:06
Оценка: 1 (1) +1 :)
Здравствуйте, Shmj, Вы писали:

S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.


Есть еще один "плюс плюсов" — Shmj научился правильно выбирать форум.

От сабя лично и от лица определенного круга участников: огромное тебе человеческое спасибо, что не принес этот вопрос в профильный форум
--
Re[2]: Основные минусы плюсов...
От: B0FEE664  
Дата: 27.07.23 12:08
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну конечно не решили, скорее даже ухудшили. Если в голом C можно было передать указатель на структуру и копию структуры, то в C++ можно передать: копию объекта, указатель, ссылку, smart_ptr, ссылку на smart_ptr, указатель на smart_ptr, rvalue ссылку, rvalue ссылку на smart_ptr. Ничего не забыл?


Ещё можно ссылку на указатель.
И каждый день — без права на ошибку...
Re[3]: Основные минусы плюсов... лично для меня
От: B0FEE664  
Дата: 27.07.23 12:22
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

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

CC>Возможно меня опыт системщика приучил что всё всегда делать надо исключительно на системных примитивах ибо всегда во главу угла выходил фокус на максимальную оптимальность под конкретной системой а не чтоб вышло что то обобщённое, что одинаково (плохо) работает на разных платформах.

Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок: при переходе на новый процессор или платформу всё по новой... Оно, конечно, всегда при деле, но пятый раз писать одно и то же...
И ведь самое забавное, что производительность при этом совсем не максимальна: всё время уходит на копирование структур и массивов.
И каждый день — без права на ошибку...
Re[11]: Основные минусы плюсов...
От: B0FEE664  
Дата: 27.07.23 12:33
Оценка:
Здравствуйте, so5team, Вы писали:

S>Во-первых, речь не про вариадики.

printf — это сишный вариадик.
И каждый день — без права на ошибку...
Re[20]: Основные минусы плюсов...
От: CreatorCray  
Дата: 27.07.23 20:56
Оценка:
Здравствуйте, so5team, Вы писали:

S>Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая.

И чем именно "{}" лучше чем "%s"?
Я вижу только недостаток в том, что надо маскировать два специальных символа, которые куда чаще встречаются в обычном тексте чем символ процента.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Основные минусы плюсов... лично для меня
От: CreatorCray  
Дата: 27.07.23 20:56
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок

Куда больше интересует производительность результата.

BFE> при переходе на новый процессор

Шта?

BFE> или платформу

И как часто это происходит в реальности?

BFE>всё время уходит на копирование структур и массивов.

А зачем их всё время копировать?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Основные минусы плюсов...
От: CreatorCray  
Дата: 27.07.23 20:56
Оценка:
Здравствуйте, rg45, Вы писали:

R>От сабя лично и от лица определенного круга участников: огромное тебе человеческое спасибо, что не принес этот вопрос в профильный форум

А бомбочки на что?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Основные минусы плюсов...
От: velkin Удмуртия https://kisa.biz
Дата: 28.07.23 01:55
Оценка:
Здравствуйте, Константин Б., Вы писали:

V>>Фактически я сейчас говорю о позиционировании в маркетинге.

КБ>Ну вот это все объясняет. Вместо того чтобы рассматривать что такое С++ на самом деле, ты рассматриваешь какие-то стереотипы, которые еще и не общеприняты.

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

По факту если бизнес готов заплатить за решения своих проблем десять тысяч рублей, то он заплатит столько или попробует работать иначе. Если бизнес готов заплатить десять миллионов рублей, доходы позволяют, то и десять миллионов заплатит. Кто-то вбухивает в разработку миллиарды, потому что есть окупаемость.

Люди пытаются изображать из себя объективных, но что мы видим по факту. Какой-нибудь Google создал свои системы на C++. Доход он получает не с продажи программ, а рекламодателей. И кто-то там внутри решил сделать Go. И "все" такие смотри это Go, давайте учить его.

А что только Microsoft не создавали. Языки относящие к .NET это по факту калька к Java. Какой-то бизнес решил, что им надо писать на Java или .NET языках. Он пишет вакансии, что так и так, нам нужны программисты с таким стеком технологий.

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

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

Но если у программиста есть мозги, то он может обойтись чем-то стандартным, без Ассемблер++ или СтопПарадигм++. Можно создать крутую систему на обычном Си без всяких C++.

Фактически есть два определяющих фактора для языков программирования и оба относятся к позиционированию.
1. Позиционирование языков программирование для бизнес использования программистом.
2. Позиционирование языков программирование для личного использования программистом.

Если какой-то банк пишет для себя софт на Java и их всё устраивает, то они дадут вакансию, что нам надо программистов на Java. Нет программистов на Java, а нам класть на это свой огромный болт, мы просто увеличим зарплаты на порядок и они появятся. Может не сразу, но найдутся люди готовые с этим заморочиться за такие то деньги.

А смысл нам докапываться почему банком был выбран Java, а не что-то для каждого. Ткни в небо, назови случайный язык программирования. Будет ли выбор для личного использования адекватным. Для адекватного выбора нужно разбираться в предмете. Новичок он на то и новичок, что в нём не разбирается.

Так что не исключено, что "объективным" фактором станет случайный Васёк Пупкин на форуме, или хайп, что типа смотрите как много вакансий, или смотрите вакансий на порядок меньше, зато высокие зарплаты. И потом люди ходят, мы такие классные, полностью объективные, наш выбор правильный, верной дорогой идём товарищи.
Отредактировано 28.07.2023 2:15 velkin . Предыдущая версия .
Re[21]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 28.07.23 04:44
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая.

CC>И чем именно "{}" лучше чем "%s"?

Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений, ведь актуальные типы все равно точно известны. Так что хоть "{}", хоть "%%", хоть "<>", ...

Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр., и пр. То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).
Re[6]: Основные минусы плюсов...
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.07.23 11:57
Оценка:
Здравствуйте, velkin, Вы писали:

V>А смысл нам докапываться почему банком был выбран Java, а не что-то для каждого. Ткни в небо, назови случайный язык программирования. Будет ли выбор для личного использования адекватным. Для адекватного выбора нужно разбираться в предмете. Новичок он на то и новичок, что в нём не разбирается.


Был недавно в сбере, получал новую карточку. У меня вызвал смех тот факт, что менеджер работал с планшетом, а не на компютере.
То есть создать приложение для того же андроида это нормально, а вот для Windows как то руки не дошли?
На том же MAUI это не проблема. Или просто Xamarin с различным гуем, но единой кодовой базой.
Вэб приложение мне лично не удобно
и солнце б утром не вставало, когда бы не было меня
Re[22]: Основные минусы плюсов...
От: CreatorCray  
Дата: 28.07.23 16:44
Оценка:
Здравствуйте, so5team, Вы писали:

S>Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений

Да пофигу на метки типов. Считай что "%s" это "%*", универсальный тип. Но такой формат таки позволяет единообразно уточнить в каком виде мы хотим видеть конкретное значение.

S>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр.

И что же мешало делать то же самое с %?
Так что нет, не удобны. Всё это уже было и работало.

S>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).

Этот новострой неудобнее как раз традиций.
Ну и к тому же типичный NIH
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[23]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 28.07.23 17:02
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений

CC>Да пофигу на метки типов.

Если пофигу, то зачем вы за них так держитесь?

S>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр.

CC>И что же мешало делать то же самое с %?

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

S>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).

CC>Этот новострой неудобнее как раз традиций.

В C++ из традиций были только iostreams с operator<< (от которых многие, включая вас, плюются) и унаследованный из Си printf (от которого больше вреда, чем пользы). А тут хороший опыт и традиции в другом языке, который в последние годы плотно C++ сопровождает. Грех было не воспользоваться.
Re[24]: Основные минусы плюсов...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 28.07.23 18:32
Оценка: +1
Здравствуйте, vsb, Вы писали:

S>>Смотря куда будет вывод идти, если в буфер в разделяемой памяти, то вполне может тормозить, особенно если вызывается несколько миллионов раз в секунду.


vsb>А текущая система iostreams — она как в таком раскладе работает? Много слышал про её тормоза, сам не мерял, правда.


А ей кто-то пользуется, ну кроме примеров и задачек на leetcode?
Маньяк Робокряк колесит по городу
Re[24]: Основные минусы плюсов...
От: CreatorCray  
Дата: 28.07.23 19:06
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[7]: Основные минусы плюсов...
От: m2user  
Дата: 29.07.23 05:01
Оценка: 1 (1) :)
S> Был недавно в сбере, получал новую карточку. У меня вызвал смех тот факт, что менеджер работал с планшетом, а не на компютере.

Кстати недавно тоже наблюдал что-то подобное в Сбербанке:
ПК у сотрудника нет, но есть планшет, причем судя по происходившему цирку с конями единственный работающий на всё отделение (ну или на услугу в очереди, на которую, я был).
И они его попеременно передавали друг другу. Отчего всё с черепашьей скоростью и двигалось.
Вместо распечатки черновика на бумаге передают планшет клиентам на проверку.

Для сравнения в 2021 всё было быстро, без очередей. Оператор работала на десктопе.
Распечатала на бумаге черновой вариант, потом чистовой на подпись.

S> То есть создать приложение для того же андроида это нормально, а вот для Windows как то руки не дошли?

S>На том же MAUI это не проблема. Или просто Xamarin с различным гуем, но единой кодовой базой.
S> Вэб приложение мне лично не удобно

Там же по сути заполнение формы и всё. Веб приложение вполне годится.
Re[24]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.08.23 09:44
Оценка: +1
Здравствуйте, so5team, Вы писали:

S>>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр.

CC>>И что же мешало делать то же самое с %?
S>Тем, что в случае с % не очевидно, что должно быть %% когда дополнительных параметров нет.

Эээ... Вообще-то %% во всех printf-like означает одиночный символ '%', а не "дополнительных параметров нет". Или вы как-то очень странно выражаетесь.

S> Тогда как со скобками это очевидно.


И что же именно очевидно-то?
Что надо писать %% чтобы передать пробел — ну да, надо доку прочитать.
Точно так же надо доку прочитать чтобы понять, что надо писать {{ и }} чтобы они не понимались как управляющие.
А вот что {} означает "сам выбери самый полезный вариант" — для этого аналога нет — его надо было бы изобретать явно.
Хотя в Java, например, %s работает для этого — что бы ни было, оно сначала подвергается toString(). Для C|C++ придётся таки изобретать своё (если вообще делать).

S>>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).


В C# оно было введено значительно раньше Python. И первое или нет — не знаю как смотреть, может, кто-то знает про более ранний пример.
Я думаю, что влияние со стороны C# было не менее существенно, чем из Python.
The God is real, unless declared integer.
Re[23]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.08.23 09:53
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Конкретно скобки удобны тем, что в них можно размещать дополнительные параметры форматирования очередного значения (ширину, выравнивание, префиксы/суффиксы, представление (hex/oct/bin/dec, ...) и пр.

CC>И что же мешало делать то же самое с %?
CC>Так что нет, не удобны. Всё это уже было и работало.

Совместимость. Большинство вариантов, которые можно задать не меняя полностью стиль, уже занято какими-то комбинациями (даже в стандарте, а тем более в конкретных имплементациях).

Изобретать методы как впихнуть туда что-то новое -- привело бы к какому-нибудь "птичьему" языку стиля того, что мы наблюдаем с регулярными выражениями и особенно с их продвинутыми расширениями, где всякие (?<:...).

Вариант с {} (начался с C# или даже раньше), во-первых, делает всё с нуля, во-вторых, использует рефлексию (или compile-time аналог) для того, чтобы именно тип значения не надо было передавать. Поэтому там концентрация на том, _как_ форматировать, а не том, _что_ форматировать из входного потока байтов или регистров.

S>>То, что это именно фигурные скобки -- это просто дань традиции (влияние Python format).

CC>Этот новострой неудобнее как раз традиций.
CC>Ну и к тому же типичный NIH

Уже давно нет.
The God is real, unless declared integer.
Re[25]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 02.08.23 11:36
Оценка:
Здравствуйте, 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.

А я здесь не думаю, уж простите, а цитирую фрагмент из официального README:

Format string syntax similar to Python's format

Может Python-овский формал позаимствовал чуть больше, чем все, из C#. Может быть.
Но автор fmtlib ссылается именно на Python-овский format, так что логичным было бы назвать это влиянием Python format.
Re[26]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.08.23 11:50
Оценка:
Здравствуйте, 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.


Oook.
The God is real, unless declared integer.
Re[26]: Основные минусы плюсов...
От: CreatorCray  
Дата: 02.08.23 16:16
Оценка:
Здравствуйте, so5team, Вы писали:

S>Если мы этот самый спецификатор шлем вдоль

А зачем? Всё равно надо терминатор, так что ничего не трогаем, оставляем как есть, меняется только смысл спецификаторов, которые теперь означают не тип передаваемого параметра а желаемое преставление параметра. Т.е. "s" банально становится as string, что одновременно становится аналогом "{}"
Что и обеспечивает обратную совместимость и не приводит к парадоксам типа "%%".

S>Суть в парности символов открытия и закрытия спецификации формата вывода.

А нафига?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[24]: Основные минусы плюсов...
От: CreatorCray  
Дата: 02.08.23 16:16
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[25]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.08.23 17:44
Оценка:
Здравствуйте, CreatorCray, Вы писали:

N>>Совместимость.

CC>Сломана нахрен.

Из printf в printf? То есть раньше %s, %d и так далее в printf — значили одно, а сейчас другое? Пример в студию, или считаю, что соврал.

N>>Поэтому там концентрация на том, _как_ форматировать, а не том, _что_ форматировать из входного потока байтов или регистров.

CC>Я уже несколько раз пальцем показал как это сделать на С++ с %
CC>И это у меня работало ещё до появления C++0x

У тебя был разборщик форматной строки в compile-time до C++0x? На чистом C++98?
The God is real, unless declared integer.
Re[26]: Основные минусы плюсов...
От: night beast СССР  
Дата: 02.08.23 19:21
Оценка:
Здравствуйте, netch80, Вы писали:

N>У тебя был разборщик форматной строки в compile-time до C++0x? На чистом C++98?


mpl не в C++0x появился, так что принципиальных ограничений (кроме как на фиксированый лимит аргументов) не было
другое дело что вряд-ли кто-то этим для принта заморачивался
Re[26]: Основные минусы плюсов...
От: CreatorCray  
Дата: 02.08.23 22:15
Оценка:
Здравствуйте, netch80, Вы писали:

N>У тебя был разборщик форматной строки в compile-time

У меня был type safe/agnostic printf где то в 2008м.
Тот самый в котором можно было на любой тип писать %s и оно правильно работало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[27]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 03.08.23 05:11
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Если мы этот самый спецификатор шлем вдоль

CC>А зачем? Всё равно надо терминатор, так что ничего не трогаем, оставляем как есть, меняется только смысл спецификаторов, которые теперь означают не тип передаваемого параметра а желаемое преставление параметра. Т.е. "s" банально становится as string, что одновременно становится аналогом "{}"
CC>Что и обеспечивает обратную совместимость и не приводит к парадоксам типа "%%".

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

Ну и иметь print, который по %i будет автоматом отображать float не поперхнувшись, ну такое себе. Я бы не хотел.

Как и объяснять в XXI веке почему используется синтаксис вида %02xs тем, что когда-то, когда меня еще не было на свете, дедушка Керниган с дедушкой Ричи придумали язык Си, в котором был printf, в котором был специальный синтаксис со спецификаторами типов, потом, спустя почти пять десятилетий, оставили всего один спецификатор типа s, который сейчас означает любой тип... В общем, ширина дорожной колеи все еще определяется размерами задниц лошадей в Древнем Риме.

S>>Суть в парности символов открытия и закрытия спецификации формата вывода.

CC>А нафига?

Проще.
Re[27]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.08.23 05:54
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, netch80, Вы писали:


N>>У тебя был разборщик форматной строки в compile-time

CC>У меня был type safe/agnostic printf где то в 2008м.
CC>Тот самый в котором можно было на любой тип писать %s и оно правильно работало.

Это ответ программиста — ясный, точный и абсолютно бесполезный.
Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался (например, как разбирал форматную строку).
Может, у тебя вообще там через препроцессор вызывался конвертер в ostream<<something
The God is real, unless declared integer.
Re[28]: Основные минусы плюсов...
От: CreatorCray  
Дата: 03.08.23 06:14
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался

Я это уже несколько раз говорил, как то надоело повторяться. Супер секретное расширение под названием оператор запятая + __VA_ARGS__ чтоб использование было такое же визуально как и printf, т.е. функция с переменным колвом аргументов

N> например, как разбирал форматную строку.

Этож вообще банальщина. Особенно когда не надо больше поддерживать всякое старьё для указания размерности, типа h или l, потому как тип переданного значения известен на момент компиляции и левой памяти из стека уже не зачерпнуть.

N>Может, у тебя вообще там через препроцессор вызывался конвертер в ostream<<something

Это не получится ибо совместить с форматной строкой будет ну уж очень гемор, но принцип был похожий: класс форматтера, в который кормятся параметры через оператор запятая.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[28]: Основные минусы плюсов...
От: CreatorCray  
Дата: 03.08.23 06:14
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[27]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.08.23 06:41
Оценка:
Здравствуйте, 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... — финальные? Где логика, кроме того что всё запоминать?
Ну а раз есть потребность в таком терминаторе, то сделать его какой-то из закрывающих скобок велел сам Отец Тьюринг.
The God is real, unless declared integer.
Re[29]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.08.23 07:25
Оценка:
Здравствуйте, CreatorCray, Вы писали:

N>>Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался

CC>Я это уже несколько раз говорил, как то надоело повторяться. Супер секретное расширение под названием оператор запятая + __VA_ARGS__ чтоб использование было такое же визуально как и printf, т.е. функция с переменным колвом аргументов

__VA_ARGS__ нет в стандарте. Значит, расширения.

N>>Может, у тебя вообще там через препроцессор вызывался конвертер в ostream<<something

CC>Это не получится ибо совместить с форматной строкой будет ну уж очень гемор,

Вроде легко
The God is real, unless declared integer.
Re[29]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 03.08.23 07:31
Оценка:
Здравствуйте, 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>Кому? И чем?

Мне. Логичнее и проще запоминать.
Re[30]: Основные минусы плюсов...
От: _NN_ www.nemerleweb.com
Дата: 03.08.23 07:33
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, CreatorCray, Вы писали:


N>>>Ты ничего не сказал ни про какие расширения C++ в промежутке от 98 до 11 на это работали (а у большинства компиляторов были какие-то из них), ни какой общий принцип использовался

CC>>Я это уже несколько раз говорил, как то надоело повторяться. Супер секретное расширение под названием оператор запятая + __VA_ARGS__ чтоб использование было такое же визуально как и printf, т.е. функция с переменным колвом аргументов

N>__VA_ARGS__ нет в стандарте. Значит, расширения.


В стандарте C99 уже давно.
Стандартизировали и для C++ немного позже.

https://eel.is/c++draft/cpp.subst

https://en.cppreference.com/w/cpp/preprocessor/replace#
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[31]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.08.23 08:25
Оценка:
Здравствуйте, _NN_, Вы писали:

N>>__VA_ARGS__ нет в стандарте. Значит, расширения.

_NN>В стандарте C99 уже давно.

Я имел в виду C++98. По контексту это должно достаточно легко читаться.

_NN>Стандартизировали и для C++ немного позже.


Угу.
The God is real, unless declared integer.
Re[30]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.08.23 08:29
Оценка:
Здравствуйте, 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 даже при точной единице — уже может быть подсказкой.
The God is real, unless declared integer.
Re[31]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 03.08.23 08:47
Оценка:
Здравствуйте, 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>Вот тут сомнительно, что именно исключение. Может быть, лучше предупреждение в логе специальной меткой рядом со значением.


Я со своей колокольни смотрю и свое мнение высказываю. Как по мне, так исключение надежнее всего (хотя исключения в проекте вообще могут быть под запретом).

Так-то понятно, что могут быть разные требования и разные взгляды. Но здесь же каждый свое ИМХО излагает. Благодаря чему можно оценить насколько все разнообразно.
Re[5]: Основные минусы плюсов... лично для меня
От: B0FEE664  
Дата: 03.08.23 16:11
Оценка:
Здравствуйте, CreatorCray, Вы писали:

BFE>>Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок

CC>Куда больше интересует производительность результата.
Результат должен укладываться в норму, не более.

BFE>> при переходе на новый процессор

CC>Шта?
Ага.

BFE>> или платформу

CC>И как часто это происходит в реальности?
От конторы зависит. В одной из контор это было регулярно, каждый год новая плата с абсолютно другой сборкой, процессором и входами/выходами...

BFE>>всё время уходит на копирование структур и массивов.

CC>А зачем их всё время копировать?
Потому, что "электронщики" не умеют иначе. Хотите кому-то послать данные? Ну-давайте-мы-их-скопируем-в-свой-буфер и будем медленно, битик за битиком посылать... Обменяться указателями на буфер? Это вы чего тут выдумали? Мы так не умеем... Вот наш буфер, мы им дорожим и никому не отдаём. Все данные только через него.
И каждый день — без права на ошибку...
Re[30]: Основные минусы плюсов...
От: CreatorCray  
Дата: 03.08.23 21:31
Оценка:
Здравствуйте, 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, значит пора закрыть эту страницу.
Всем пока
Re[31]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 04.08.23 05:15
Оценка:
Здравствуйте, 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 и пр., легче.
Re[32]: Основные минусы плюсов...
От: CreatorCray  
Дата: 04.08.23 08:04
Оценка:
Здравствуйте, so5team, Вы писали:

S>Продолжая логическую цепочку...

Не знаю как тебе а мне эта сказка про белого бычка уже надоела...

S>Если критичная ветка не была протестирована

Очень далеко не всё и не всегда можно протестировать.

S>Но расстреливать вы собираетесь гонца, который принес вам дурную весть. Ну, OK.

Не, я как раз хочу чтоб никого не расстреляли и гонец хоть что то промямлил.

S>Позволю себе процитировать ув.тов.netch80, который уже все хорошо расписал:

Он за деревьями не увидел леса.
После того, как тебе не надо задавать передаваемые размерности всякие "нефинальные" попросту отмирают.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[32]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.08.23 08:41
Оценка:
Здравствуйте, so5team, Вы писали:

S>>>А я бы предпочел получить исключение в run-time, если вместо int-а оказывается float, т.к. отображая float как int мы теряем часть информации даже не зная об этом.

N>>Вот тут сомнительно, что именно исключение. Может быть, лучше предупреждение в логе специальной меткой рядом со значением.
S>Я со своей колокольни смотрю и свое мнение высказываю. Как по мне, так исключение надежнее всего (хотя исключения в проекте вообще могут быть под запретом).

Так исключения для целевого кода — могут как раз быть осмысленными, если ему лучше остановиться, чем сделать плохое — но тут точно вопрос контекста и даже вкуса.
А вот выбить логгирование — имеет смысл только тогда, когда это портит сам лог (ну типа скинуть бинарный блоб в текстовую форму, или гигабайт мусора), тут я не вижу, чем можно вообще возражать.

S>Так-то понятно, что могут быть разные требования и разные взгляды. Но здесь же каждый свое ИМХО излагает. Благодаря чему можно оценить насколько все разнообразно.


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

(Не думаю, что речь шла о целевом логгировании)
The God is real, unless declared integer.
Re[33]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.08.23 08:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Позволю себе процитировать ув.тов.netch80, который уже все хорошо расписал:

CC>Он за деревьями не увидел леса.
CC>После того, как тебе не надо задавать передаваемые размерности всякие "нефинальные" попросту отмирают.

Нет, я же объяснил, почему.
Десятичный (d), шестнадцатиричный (x), восьмеричный (o) формат для целых.
Фиксированная точка (f), чисто плавающая (e), смешанная (g), машинно-читаемая (a) для плавучих.
Выбор локали (хотя бы — применяется или универсальный формат для машины).

Для C|C++ ещё и применение целого как кода символа (увы, char это целое).

Как ты вообще читаешь, если пропускаешь такое?

S>>Продолжая логическую цепочку...

CC>Не знаю как тебе а мне эта сказка про белого бычка уже надоела...

Если бы ты хоть пытался читать что тебе пишут, ты бы давно перестал её рассказывать, за ненадобностью.
The God is real, unless declared integer.
Re[34]: Основные минусы плюсов...
От: CreatorCray  
Дата: 04.08.23 08:58
Оценка:
Здравствуйте, netch80, Вы писали:

CC>>После того, как тебе не надо задавать передаваемые размерности всякие "нефинальные" попросту отмирают.

N>Нет, я же объяснил, почему.
И не близко. Ты там вообще о чём то ортогональном...

N>Десятичный (d), шестнадцатиричный (x), восьмеричный (o) формат для целых.

N>Фиксированная точка (f), чисто плавающая (e), смешанная (g), машинно-читаемая (a) для плавучих.
И какие же из них "нефинальные", которые надо "держать в голове"?

N>Как ты вообще читаешь, если пропускаешь такое?

Какое, такое? Не имеющее отношение к обсуждаемому вопросу? Да, не вижу смысла уводить на это тему.

N>Если бы ты хоть пытался читать что тебе пишут


Попытайся прочитать что тебе пишут.

Ладно, мне уже совсем надоело, пора похоже от этой ветки отписаться.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[35]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.08.23 09:12
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

N>>Десятичный (d), шестнадцатиричный (x), восьмеричный (o) формат для целых.

N>>Фиксированная точка (f), чисто плавающая (e), смешанная (g), машинно-читаемая (a) для плавучих.
CC>И какие же из них "нефинальные", которые надо "держать в голове"?

В твоём варианте с %s — все перечисленные.

N>>Если бы ты хоть пытался читать что тебе пишут

CC>
CC>Попытайся прочитать что тебе пишут.

У меня как раз с этим проблем нет.

CC>Ладно, мне уже совсем надоело, пора похоже от этой ветки отписаться.


Заранее спасибо за снижение уровня бессмысленного шума. (Можешь расширить на прочие ветки.)
The God is real, unless declared integer.
Re[33]: Основные минусы плюсов...
От: so5team https://stiffstream.com
Дата: 04.08.23 09:21
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ну вот я и не могу понять из каких соображений может быть лучше не логгировать — или даже вышибать работу целевого кода из-за проблем отладочно-диагностического логгирования.


N>(Не думаю, что речь шла о целевом логгировании)


А я не про отладочно-диагностическое. Я про "целевое" логирование в вашей терминологии, по котором затем с инцидентами на проде разбираться будут. Если в таком логировании вместо int-а подсунут float и этот float автоматически сконвертируется в int, то значит мы теряем информацию, которая может быть критически важна для тех самых разбирательств. И если это происходит тайком от всех, то это не есть хорошо.
Re[36]: Основные минусы плюсов...
От: CreatorCray  
Дата: 04.08.23 17:31
Оценка:
Здравствуйте, netch80, Вы писали:

CC>>И какие же из них "нефинальные", которые надо "держать в голове"?

N>В твоём варианте с %s — все перечисленные.
Они как раз все финальные, включая %s

CC>>Попытайся прочитать что тебе пишут.

N>У меня как раз с этим проблем нет.
Да вот что то в глаза не бросается.

N>Заранее спасибо за снижение уровня бессмысленного шума. (Можешь расширить на прочие ветки.)

Ты явно пытаешься добиться того, чтоб я все твои опусы ехидно комментировал?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: Основные минусы плюсов...
От: Pitirimov США  
Дата: 04.08.23 18:44
Оценка: -1
Здравствуйте, Shmj, Вы писали:
S>Как вы думаете?

Если человек обожает Си++, назубок выучил шаблоны проектирования, свободно использует стандартную библиотеку с "Бустом" и прочими библиотеками, а также следит за модными системами сборки проекта вроде "Симэйка", то на решение ответственных задач я бы такого программиста постарался не брать и сейчас поясню почему.
Чтобы сделать что-либо лучше остальных придётся разобраться в задаче от истока досконально и всё делать самому. Для этого, к примеру, "Тесла" занимается изготовлением собственной бортовой электронной аппаратуры и аккумуляторов с электродвигателями, хотя вполне могла бы поручить изготовление составных узлов автомобиля стороннему производителю.
Если же программист при обучении привык к переиспользованию чужого кода и склонен к использованию сторонних библиотек вместо написания собственного кода, наилучшим образом подходящего под задачу, то создать ПО, превосходящее всё остальное ПО, с таким товарищем вряд ли получится.
Делать как у всех смысла не имеет ибо крупные предприятия выдавят с рынка мелких лавочников наличием больших денег и, соответственно, привлечением лучших инженеров с рынка труда.
Побеждают зануды, всегда идущие от истока, вроде Линуса Торвальдса и Илона Маска, а неудачники-переиспользователи, вроде Бьёрна Страуструпа, лишь пишут одну книгу за другой ибо собственный успешный проект создать не способны.
Re: Основные минусы плюсов...
От: karbofos42 Россия  
Дата: 04.08.23 19:06
Оценка: :)
Здравствуйте, Shmj, Вы писали:

S>О плюсах плюсов вроде говорили — настоящая кроссплатформенность, скорость запуска (нет JIT и прочего), большая кодовая база.


Настоящая кроссплатформенность — это когда один и тот же код по-разному везде работает, а где-то и вовсе отказывается компилироваться?

S>Можно сказать что из-за управления памятью. Но вроде умные указатели таки можно сказать вопрос решили. Но даже если этот вопрос убрать — то все-равно, как ни крути, а как-то медленнее получается писать (читать) и я затрудняюсь ответить почему так.


Умные указатели нужно уметь использовать. Код нужно писать по неким правилам и трястись чуть ли не над каждым исключением.
Иначе вылезет что-то в каком-нибудь конструкторе не то и утекла память.
Или массив решил принять на вход, забыл проверить размерность или не ту передал — попортил память.

S>Как вы думаете?


Простота выстрелить себе в ногу и сложность реализации базовых вещей.
Можно сравнить хотя бы строковые типы в C#, Java и C++.
Re[2]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 04.08.23 19:18
Оценка:
Здравствуйте, Pitirimov, Вы писали:

P>Побеждают зануды, всегда идущие от истока, вроде Линуса Торвальдса и Илона Маска, а неудачники-переиспользователи, вроде Бьёрна Страуструпа, лишь пишут одну книгу за другой ибо собственный успешный проект создать не способны.


Разве Страуструп не больший зануда? Вроде Маска так никто еще не унижал.
Re[2]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 04.08.23 19:23
Оценка:
Здравствуйте, karbofos42, Вы писали:

K>Настоящая кроссплатформенность — это когда один и тот же код по-разному везде работает, а где-то и вовсе отказывается компилироваться?


Чистый код без системных вызовов то как раз 100% компилируется везде.

K>Умные указатели нужно уметь использовать. Код нужно писать по неким правилам и трястись чуть ли не над каждым исключением.

K>Иначе вылезет что-то в каком-нибудь конструкторе не то и утекла память.

Правила есть, согласен. Но это — плата за нейтивность.

K>Или массив решил принять на вход, забыл проверить размерность или не ту передал — попортил память.


Так vector же подвезли вместо массивов.

S>>Как вы думаете?


K>Простота выстрелить себе в ногу и сложность реализации базовых вещей.

K>Можно сравнить хотя бы строковые типы в C#, Java и C++.

Чем так уж std::string плох?
Re[2]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 04.08.23 19:30
Оценка:
Здравствуйте, Pitirimov, Вы писали:

P>Делать как у всех смысла не имеет ибо крупные предприятия выдавят с рынка мелких лавочников наличием больших денег и, соответственно, привлечением лучших инженеров с рынка труда.


Тут не просто. Велосипедить тоже далеко не всегда уместно.

Тесла с миллиардными капиталами может велосипедить — но есть ли у вас эти миллиарды?
Re[2]: Основные минусы плюсов...
От: CreatorCray  
Дата: 04.08.23 20:45
Оценка:
Здравствуйте, Pitirimov, Вы писали:

P>Если человек обожает Си++

P>Если же программист при обучении привык к переиспользованию чужого кода и склонен к использованию сторонних библиотек вместо написания собственного кода, наилучшим образом подходящего под задачу, то создать ПО, превосходящее всё остальное ПО, с таким товарищем вряд ли получится.

А теперь объясни при чём тут С++?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Основные минусы плюсов...
От: karbofos42 Россия  
Дата: 05.08.23 09:06
Оценка:
Здравствуйте, 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, т.к. нужный метод внезапно умеет работать только с таким контейнером.
Re[4]: Основные минусы плюсов...
От: Shmj Ниоткуда  
Дата: 05.08.23 10:22
Оценка:
Здравствуйте, 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 — то все аналогично.
Re[5]: Основные минусы плюсов...
От: karbofos42 Россия  
Дата: 05.08.23 12:31
Оценка: :)
Здравствуйте, Shmj, Вы писали:

S>Это больше страхи.


Нет. Это больше опять к тому, что на C++ свободно можно наворотить всякого, но потом окажется, что это работает нормально только у тебя.
Нужно долго ковыряться и изучать язык, чтобы собрать в голове что и как лучше делать и где какие нюансы.
Банально будешь использовать int в надежде на 4 байта, потом код будет собран под платформу, где он будет 2 байта, в процессе работы пойдут переполнения и успехов в отладке этого кроссплатформенного кода.
Вроде и программист сам дурак, что такое написал, а вроде и в чём кроссплатформенность языка, если он такие подставы на каждом шагу устраивает?

S>Но медленная и требует установки среды


Ну, компиляция в байт-код никак не связана с синтаксисом языка.
В .NET завезли AOT, для Java по-моему тоже что-то подобное было или есть.

S>Сколько минимальный размер бинарника для WebAssembly на Java?


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

S>Так std::string же есть, старые строки зачем использовать?


А их можно не использовать?
std::string str = "строка";
// эквивалент
std::string str("строка");

"строка" — это же const char * в обоих случаях
Я давно за плюсами не слежу, они там в новых стандартах уже нормальные строковые константы добавили?

S>А в Java и C# строка — это ведь тоже UTF-8 и если понадобится UTF-16 — то все аналогично.


По-моему UTF-16 в обоих языках идёт.
В любом случае, в Java и C# строки идут как строки, а в C++ — массив символов, а строки уже отдельно прикручиваются.
Re[6]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.08.23 13:41
Оценка: 1 (1)
Здравствуйте, karbofos42, Вы писали:

K>Банально будешь использовать int в надежде на 4 байта, потом код будет собран под платформу, где он будет 2 байта, в процессе работы пойдут переполнения и успехов в отладке этого кроссплатформенного кода.

K>Вроде и программист сам дурак, что такое написал, а вроде и в чём кроссплатформенность языка, если он такие подставы на каждом шагу устраивает?

Я думаю, на такой платформе будет побольше проблем;\
Но в общем да, заложиться на ресурс и потом страдать от скрытых ошибок от его недостатка — это жестокий сюр.

K>"строка" — это же const char * в обоих случаях

K>Я давно за плюсами не слежу, они там в новых стандартах уже нормальные строковые константы добавили?

"строка"sv
начиная с C++17.
The God is real, unless declared integer.
Re[5]: Основные минусы плюсов...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.08.23 13:42
Оценка:
Здравствуйте, Shmj, Вы писали:

S>UB нужно не применять, его подсвечивают.


Кто? Где? Какая IDE? Все случаи? "Имя, сестра!"
The God is real, unless declared integer.
Re[7]: Основные минусы плюсов...
От: _NN_ www.nemerleweb.com
Дата: 05.08.23 16:20
Оценка:
Здравствуйте, netch80, Вы писали:

N>"строка"sv

N>начиная с C++17.

А ещё лучше в стиле zsv где сохраняется нулевой символ.
Очень жаль, что в комитете считают его ненужным.
http://rsdn.nemerleweb.com
http://nemerleweb.com
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.