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

S>Частью языка является то, что зафиксировано в стандарте.
Частью именно что языка является то, для чего надо поддержка компилятором.
Всё остальное — библиотечный код. Который выбрасывается или заменяется без потери функциональности самого языка.

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

S>А да, у вас же есть мега альтернатива fmtlib, которую никто никогда не увидит.
Есть, работает замечательно. Причём ещё и заметно быстрее fmtlib, как то померял интересу ради.
Причём что крайне полезно — с бОльшего printf-like совместимо, что упрощает перенос всякого старого кода.

S>мозги вряд ли могли бы позволить ЧСВ раздуться до такого уровня
Божеж мой, да я "такое же быдло как и вы" (С)
Узбагойся и перестань пытаться что то там читать между строк. Там ничего не написано.

S>а вот над желанием высказать единственно правильное мнение
Похоже "единственно правильное" (tm) пытаешься отстаивать ты.
Я же высказываю просто своё мнение.

S>скоро будут откровенно стебаться.
Я давно уже стебусь.

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

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

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

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

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

S> Подобные вещи должны приводить к ошибкам, желательно времени компиляции.
Форматная строка ж не обязательно фиксирована в момент компиляции.
И если там что то было неправильно, то желательно в логах увидеть хоть какое то разумное значение а не просто "нишмагла".
Впрочем у меня таки ругается если в тот же "%i" передать строку.

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

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

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

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

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

— А давай вместо Add() назовём метод push_back()?
— Давай! И ещё отделим алгоритмы от данных, вынеся их в отдельные классы! И пусть remove не remov'ит, а erase — не eras'ит.
— MWAHAHAHAHA! Ты просто гений злодейства!!!

Здравствуйте, 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<<

Здравствуйте, 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.

А другим (включая меня) надо было.

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

S>>Частью языка является то, что зафиксировано в стандарте.
CC>Частью именно что языка является то, для чего надо поддержка компилятором.

Можно еще 100 раз это повторить, но факт остается фактом: в стандарте C++ определена стандартная библиотека языка. Ее принято называть STL. Следовательно, STL является частью языка.

CC>Всё остальное — библиотечный код. Который выбрасывается или заменяется без потери функциональности самого языка.

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

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

Так в том-то и фокус: однозначно лучше не получилось.

S>>А да, у вас же есть мега альтернатива fmtlib, которую никто никогда не увидит.
CC>Есть, работает замечательно. Причём ещё и заметно быстрее fmtlib, как то померял интересу ради.
CC>Причём что крайне полезно — с бОльшего printf-like совместимо, что упрощает перенос всякого старого кода.

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

S>>а вот над желанием высказать единственно правильное мнение
CC>Похоже "единственно правильное" (tm) пытаешься отстаивать ты.

Т.е. эпитеты "отвратительно спроектированный интерфейс" и "извращение" употребляете вы, а единственно правильное отстаиваю я? Ну OK.

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

S>>дабл выводится там, где требуется строка
CC>А что должно выводиться?

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

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

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

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

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

PS. Это все к разговору о том, что у разных людей разные требования и взгляды на то, как "нормально".

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

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

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

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

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

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

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

vsb>

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

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

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

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

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

vsb>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



CRT>>Для выводы обычных строк, символов, чисел printf удобней
CC>printf-like — да. Но сам сишный printf таки нет.

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

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

CRT>>>Для выводы обычных строк, символов, чисел printf удобней
CC>>printf-like — да. Но сам сишный printf таки нет.

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

Вроде в C++ уже должно хватать возможностей, чтобы реализовать интерфейс printf безопасно? Ну может не с ошибкой компиляции, но по крайней мере без порчи стека и прочих спецэффектов при неправильном формате.

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

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

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

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

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

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

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

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

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

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

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

PS. Цифра 1/3 взята, по сути, с потолка. Когда-то замерял затраты компилятора на обработку cpp-файла с активным использованием шаблонов. Там стадия препроцессинга как-раз треть занимала. Остальное -- это кодогенерация после инстанциирования шаблонов.

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

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

CRT>а в образце 1991 были

Ну так operator<< для вывода в iostream появился не в 1991-ом, а гораздо раньше.

CRT>а STL в 1994 появилась

В 1992-1993.

CRT>в конце 90-х шаблоны были довольно прилично развиты.

Смотря где. В VC++ нормальная поддержка шаблонов из C++98 появилась только в VS2003. А export template вообще всего в одном компиляторе был, который не имел широкого применения.

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

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

До fmtlib были другие инструменты, тот же Boost.Format, который для C++98 был написан.

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

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

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

Есть. C++ расчитан на мифических программистов которые никогда не допускают ошибок. А другие языки наоборот на то что программисты могут и будут ошибаться.