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

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

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

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

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

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

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

Если не будет неявных преобразований типа, то не придется ссылаться "См выше".

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

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

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

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

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

Если вопрос важен, то может его переформулируете, чтобы было понятнее?

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

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

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

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

Так что незачет.

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

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

Ну-ну, ну-ну... Я не самый большой любитель упарываться шаблонной магией, но местами компиляция одного (всего одного) .cpp файла в течении 10-15 секунд -- это вполне себе обыденно.

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

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

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

Но несколько лет назад прочитал книжку на русском про ACE. В целом мне понравилась (сама концепция ACE, да и книга толково написана. Название манускрипта с ходу не скажу, мне надо на полке его поискать...).

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

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

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

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

Но несколько лет назад прочитал книжку на русском про ACE. В целом мне понравилась (сама концепция ACE, да и книга толково написана. Название манускрипта с ходу не скажу, мне надо на полке его поискать...).

Спасибо. У меня эта книжка есть.
Двухтомник из серии C++ in Depth

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

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

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

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

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

CC>>Ты не понял вопроса.
S>Если вопрос важен, то может его переформулируете, чтобы было понятнее?
Мне уже и так скучно.

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

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

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

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

вместо

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

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

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

Я об этом писал в
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++.

Вот так у нас появилась целевая аудитория под каждый язык программирования. Каждый язык имеет своё предназначение и это хорошо. Зачем нам универсальный инструмент, в этом нет смысла. Самое главное, что выучить только одну область такую как формошлёпство, веб или даже битомолки проще, чем все сразу. Потому одни языки программирования проще других.

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

V>Ещё раз процитирую.
V>Линус Торвальдс

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

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

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

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

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

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

V>https://www.youtube.com/watch?v=JbovJbKALzA
Ты правда думаешь что я про этот его высер не в курсе?
Надо же nVidia не захотела плясать под его хотелки, какая беда! Не хотят свой код отдавать под вирусную GPL — вот жеж сволочи какие!

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

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

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

Ну или убеждать себя в том, что написав %s вместо %e все равно что-то да выведется и это хорошо.

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

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

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

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

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

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

Так что, как и было сказано ранее, шило на мыло. Для хорошего решения в начале 1980 в C++ просто не было достаточных выразительных средств.

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

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

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

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

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

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

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

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

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

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

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

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

Во вторых, даже в той области, для которой плюсы создавались, у современных плюсов есть проблемы. C++ (и ему подобные) — это языки, которые надо "уметь готовить". Поэтому вместо того, чтобы концентрироваться на задачах бизнеса, командам на с++ приходится заниматься поиском особых поваров, которые 1) никогда не используют вредных продуктов голых указателей, new, delete, 2) знают наизусть Великую поварскую книгу хотя бы Effective Modern C++, 3) разбираются в молекулярной кухне современных стандартах, 4) всегда придерживаются строгого порядка добавления ингредиентов стиля программирования (чтобы их код могли понять другие) и т.п. Ну вы понели ))