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

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

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

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

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

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

Ещё можно ссылку на указатель.

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

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

Ну вот я писал на системных примитивах и понял, что производительность труда при этом падает на порядок: при переходе на новый процессор или платформу всё по новой... Оно, конечно, всегда при деле, но пятый раз писать одно и то же...
И ведь самое забавное, что производительность при этом совсем не максимальна: всё время уходит на копирование структур и массивов.

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

S>Во-первых, речь не про вариадики.
printf — это сишный вариадик.

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

S>Вот только если вместо %s или %i в форматной строке использовать {}, как это делается в том же fmtlib, то становится пофиг насколько она мокрая.
И чем именно "{}" лучше чем "%s"?
Я вижу только недостаток в том, что надо маскировать два специальных символа, которые куда чаще встречаются в обычном тексте чем символ процента.

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

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

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

BFE> или платформу
И как часто это происходит в реальности?

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

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

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

Здравствуйте, Константин Б., Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Был недавно в сбере, получал новую карточку. У меня вызвал смех тот факт, что менеджер работал с планшетом, а не на компютере.
То есть создать приложение для того же андроида это нормально, а вот для Windows как то руки не дошли?
На том же MAUI это не проблема. Или просто Xamarin с различным гуем, но единой кодовой базой.
Вэб приложение мне лично не удобно

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

S>Именно "{}" не важен. Важно то, что в форматной строке (если уж она так уж нужна) не приходится указывать метки типов значений
Да пофигу на метки типов. Считай что "%s" это "%*", универсальный тип. Но такой формат таки позволяет единообразно уточнить в каком виде мы хотим видеть конкретное значение.

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

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

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

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

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

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

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

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

В C++ из традиций были только iostreams с operator<< (от которых многие, включая вас, плюются) и унаследованный из Си printf (от которого больше вреда, чем пользы). А тут хороший опыт и традиции в другом языке, который в последние годы плотно C++ сопровождает. Грех было не воспользоваться.

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

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

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

А ей кто-то пользуется, ну кроме примеров и задачек на leetcode?

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

S>Если пофигу, то зачем вы за них так держитесь?
Чтоб не переписывать туевы хучи кода на новые метки, doh!
Ну и да, %s == {}

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

S>В C++ из традиций были только iostreams с operator<<
Это у тех, кто кроме стандартной библиотеки мира не видел.

S>и унаследованный из Си printf (от которого больше вреда, чем пользы).
Printf написанный именно на С++ как раз работает замечательно.
То, что бесполезный комитет сумел родить это только к 20й версии (и то корявое донельзя) совсем не отменяет что у практикующих людей это всё давно уже было.

S>А тут хороший опыт и традиции в другом языке
Пусть остаются в другом языке, не надо это сюда тащить. Ничего эдакого хорошего в этом нет, банальный NIH

Мне надоело.

S> Был недавно в сбере, получал новую карточку. У меня вызвал смех тот факт, что менеджер работал с планшетом, а не на компютере.

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

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

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

Там же по сути заполнение формы и всё. Веб приложение вполне годится.

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

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

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

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

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

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

В C# оно было введено значительно раньше Python. И первое или нет — не знаю как смотреть, может, кто-то знает про более ранний пример.
Я думаю, что влияние со стороны C# было не менее существенно, чем из Python.

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

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

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

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

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

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

Уже давно нет.

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

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

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

В printf-like синтаксисе, имхо, ключевой момент в том, что % обозначает "сейчас пойдут параметры", а завершает этот необязательный список параметров обязательный спецификатор типа (s, d, x, e и т.д.). Если мы этот самый спецификатор шлем вдоль, а именно об этом я и говорю, то от printf-like синтаксиса у нас остается только %. Ну а т.к. % только открывает спецификацию вывода, то появляется задача как эту спецификацию закрыть. Например, %02x% (где x обозначает не int, а только шестнадцатиричное представление). Соответственно, если спецификация пуста, то получается %%.

То, что %% -- это обозначение для одинарного %, простите, запамятовал. За последние пару десятков лет с printf приходилось иметь дело лишь эпизодически.

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

N>И что же именно очевидно-то?

Что {} обозначает дефолтную спецификацию вывода. Тогда как {:02x} обозначает применение формата "02x".

И здесь {} можно заменить на () или [], или <>. Суть в парности символов открытия и закрытия спецификации формата вывода.

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

N>В C# оно было введено значительно раньше Python. И первое или нет — не знаю как смотреть, может, кто-то знает про более ранний пример.
N>Я думаю, что влияние со стороны C# было не менее существенно, чем из Python.

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

Format string syntax similar to Python's format

Может Python-овский формал позаимствовал чуть больше, чем все, из C#. Может быть.
Но автор fmtlib ссылается именно на Python-овский format, так что логичным было бы назвать это влиянием Python format.

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

N>>Эээ... Вообще-то %% во всех printf-like означает одиночный символ '%', а не "дополнительных параметров нет". Или вы как-то очень странно выражаетесь.
S>В printf-like синтаксисе, имхо, ключевой момент в том, что % обозначает "сейчас пойдут параметры", а завершает этот необязательный список параметров обязательный спецификатор типа (s, d, x, e и т.д.). Если мы этот самый спецификатор шлем вдоль, а именно об этом я и говорю, то от printf-like синтаксиса у нас остается только %. Ну а т.к. % только открывает спецификацию вывода, то появляется задача как эту спецификацию закрыть. Например, %02x% (где x обозначает не int, а только шестнадцатиричное представление). Соответственно, если спецификация пуста, то получается %%.

Думаю, если бы так сделали сначала, то оно было бы сильно лучше расширяемо.
Но вот имеем тяжёлое легаси.
Со введением {} по крайней мере вид форматных спецификаторов напоминает, что внутри надо ожидать совсем другое.

S>>> Тогда как со скобками это очевидно.
N>>И что же именно очевидно-то?
S>Что {} обозначает дефолтную спецификацию вывода. Тогда как {:02x} обозначает применение формата "02x".
S>И здесь {} можно заменить на () или [], или <>. Суть в парности символов открытия и закрытия спецификации формата вывода.

Да, внешняя терминация в таком виде выглядит сильно читабельнее.

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

Format string syntax similar to Python's format

Ясно. Да, в таком виде это аргумент.

S>Может Python-овский формал позаимствовал чуть больше, чем все, из C#. Может быть.

Почти так — причём специфические особенности Питона вроде !r вместо !s в основном неуместны для C++ (или должны быть поняты иначе).

S>Но автор fmtlib ссылается именно на Python-овский format, так что логичным было бы назвать это влиянием Python format.

Oook.

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

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

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