С++23 уже почти здесь

Опять бред. Тебе что-то мешает в плюсах использовать forward declaration и функции?

Нет. Просто, это уже не плюсы.

Forward declaration не плюсы? Вы меня разочаровываете…

Мне кажется Вы не «котиков не любите», а Вы их «готовить не умеете»…

Forward declaration не плюсы? Вы меня разочаровываете…

ну давай, что там из плюсов?

Forward declaration не плюсы? Вы меня разочаровываете…

ну давай, что там из плюсов?

А что там НЕ из плюсов?

А вот как по мне всё наоборот, код на Си++, если его писал именно плюсовик, а не Сишник или Джавист - читать одно удовольствие.

А вот Си я как раз хейтю. Ну для лаболаторных студентов вполне себе может подойти для обучения (вместо или совместно с Паскалём). Но вот в реальных, больших проектов, как для меня, кода на Си становится вырвиглазным, из-за отстуствия ооп (привет уродливая Glib), из-за отсутствия полиморфизма(шаблонов и перегрузов) и в связи с этим с кучей похожих ф-й отличающихся префиксами-постфиксами под нужный тип данных, с перегруженным(от понятия избыточность) интерфейсом ф-й (с их обилием входящих параметров).

В общем ужасно.

перегрузка операторов и функций откровенно вредна

чем вредна? (при условии что код пишется в современной системе (QtCreator+clangbackend или mscv), а не в текстовом редакторе).

В общем ужасно.

Все как обычно …

На баяне играть просто.  
Растягивай мехи вперед, назад и  
ВСЕ!

то в функциях могут произойти исключения

Т.е. когда вы писали вот это:

А как ты будешь обрабатывать ошибки паттерн-матчинга? Исключениями?

то вы говорили о предоставленных пользователем функциях (вроде перегруженных operator== или extract/try_extract), которые информируют об ошибках посредством исключений?

Тю…

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

if( auto * p = std::get_if<my_type>(&v); p && *p == some_value ) {...}

здесь у вас точно так же в *p == some_value может вылететь исключение.

Во-вторых, мне непонятно, к чему был вопрос «А как ты будешь обрабатывать ошибки паттерн-матчинга?» если на данный момент вариант всего лишь один – выброс исключений, т.к. по другому перегруженные операторы сообщить о проблеме в C++ не могут.

При этом ошибки эти к собственно механизму паттерн-матчинга отношения не имеют. Тут нужно ставить вопрос о том, насколько предлагаемый паттерн-матчинг окажется устойчивым к бросаемым в процессе матчинга исключениям. И ответ, скорее всего, будет простым: с паттерн-матчингом то все в порядке, это пользователю придется следить за побочными эффектами, которые сам пользователь может порождать в своих operator==/extract/try_extract.

А что ты будешь делать, если при присвоении std::variant у тебя происходит исключение и ты остаешься с valueless_by_exception?

Прежде всего я задумаюсь о том, а как у меня вообще окажется std::variant в состоянии valueless_by_exception.

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

Я изначально вел разговор про несовместимость шаблонов с разными модификаторами, а не классов.

Вот хз о чем вы вели разговор, т.к. объяснить, что есть «тег типа» вы не смогли.

dynamic_cast же при том, что C++ – это не динамически-типизированный язык, а статически. И поэтому вы работаете со следующими ситуациями:

• вы точно знаете все типы (вроде variant<int, float, point>). Поэтому компилятор даст вам по рукам, если вдруг у вас окажется unsigned long, double или point3d;
• вы видите указатель (ссылку) на базовый класс, вроде shape, за которым могут скрываться наследники (вроде circle, triangle, rectange и т.д.). И тогда вам потребуется dynamic_cast для приведения от базового типа к наследнику. А dynamic_cast может и не бросать исключений, если приведение не сработало;
• вы имеете дело с std::any или чем-то подобным. Но тогда вам не суть важно, что именно там лежит, т.к. у вас есть всего лишь N вариантов, которые вы можете обработать. Соответственно, если в std::any лежит что-то отличное от этих N вариантов, то паттерн-матчинг у вас не сработает.

Что вы хотели показать своим бредовым примером с int и const int я не понял. Компилятор дал вам по рукам, следовательно в run-time у вас не будет никаких проблем с неправильным «тегом типа», что бы вы не подразумевали под этим термином.

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

Подозреваемый путается в показаниях:

(при условии что код пишется в современной системе (QtCreator+clangbackend или mscv), а не в текстовом редакторе)

Если у тебя есть современная IDE, которая выдаст подсказки по подстроке, то в чем проблема? Дело пары дней привычки.

Вот что Glib убогая — это да. Правда, Qt и UE точно так же тоже убогие, а еще VCL. Если ты внимательно всмотришься в код реализации, именно реализации, а не красивых схем иерархий из доков, то ты увидишь, что все эти либы состоят из одного-двух-трех god object-ов, от которых наследуются тонкие прокладки конкретных компонентов. Это самое прямое следствие класс-ориентированной архитектуры. Да, в Glib это выглядит чуть более убого, но это в любом случае плюс-минус тот же сорт говна. Qt собственный препроцессор для метапрограммирования сделало, потому что метапрограммирование в C++ убого. По итогу Qt вообще ушло в сторону JS.

перегрузка операторов и функций откровенно вредна

чем вредна?

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

Если говорить просто про операторы, то их проблема в том, что у них нет никаких способов возврата ошибок. То есть, ты связан по рукам и ногам. Операторов довольно мало, новых делать нельзя, из-за чего их функция даже в стандартной библиотеке интуитивно не ясна (зачем делать битовый сдвиг над stdout?). А у доступа к массиву по индексу operator[] нельзя даже сделать несколько аргументов для многомерных массивов. В Boost на радостях сделали многомерные массивы через [][][], где доступ по индексу возвращает прокси, которая дальше индексируется. Но это всё трешак, операторы в C++ убоги и с этим сделать ничего нельзя.

Sorry, но считаю пост важным

На баяне играть просто.  
Растягивай мехи вперед, назад и  
ВСЕ!

Тем кто не освоил баян, рекомендую скрипку

Она и легче и проще ...

операторы в C++ убоги и с этим сделать ничего нельзя.

Блин, ну что же с Вами делать то… Чем больше Вы вещаете - тем больше вес Ваших утверждений падает, не обижайтесь.

Во-вторых, мне непонятно, к чему был вопрос «А как ты будешь обрабатывать ошибки паттерн-матчинга?» если на данный момент вариант всего лишь один – выброс исключений, т.к. по другому перегруженные операторы сообщить о проблеме в C++ не могут

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

При этом ошибки эти к собственно механизму паттерн-матчинга отношения не имеют

По моей ссылке автор как раз предлагал сделать исключение одной из веток для паттерн-матчинга.

с паттерн-матчингом то все в порядке, это пользователю придется следить за побочными эффектами, которые сам пользователь может порождать в своих operator==/extract/try_extract

Пока паттерн-матчинг находится на уровне hello world, то есть, std::visit, то, конечно, проблем нет. Но масштабируется по уровням абстракций это дело отвратительно.

Прежде всего я задумаюсь о том, а как у меня вообще окажется std::variant в состоянии valueless_by_exception
На C++17 работаю относительно недавно, всего года два (может два с половиной). Пока что не встречал такого явления в дикой природе. И не вижу простого способа получить подобный экземпляр variant если в коде обеспечивается хотя бы базовые гарантии безопасности исключений

Любая относительно глобальная ячейка variant с непримитивным значением рано или поздно приходит к этому состоянию. То есть, исключения обработаны, локальные ресурсы корректно высвобождены, но исключение было брошено при изменении variant, и если провтыкать/недотестить эту ветку, то можно забыть дописать сброс/установку variant в ветке обработки ошибок.

Вот хз о чем вы вели разговор, т.к. объяснить, что есть «тег типа» вы не смогли

Любой идентификатор для определения типа значения в tagged union. В чуть более развитых и динамичных языках в качестве тэга используют штуки, которые позволяют отладчиком исследовать объект без необходимости в идеально корректном контексте и полной отладочной информации (и в том числе для сложного паттерн-матчинга) — что позволяет успешно проводить отладку даже после серьезных ошибок. std::any — кандидат, но сильно не дотягивает, поскольку у C++ традиционна отвратительные RTTI и рефлексия. Предлагаю сравнить с C#, где к объектам можно обращаться как к ассоциативным массивам, по динамическим именам атрибутов. Вообще, у меня такое ощущение, что законодателей C++ вопросы отладки и тестирования совсем не волнуют.

Что вы хотели показать своим бредовым примером с int и const int я не понял. Компилятор дал вам по рукам, следовательно в run-time у вас не будет никаких проблем с неправильным «тегом типа», что бы вы не подразумевали под этим термином

Так это один и тот же int! Более того, я передал int в функцию const int.

Блин, ну что же с Вами делать то… Чем больше Вы вещаете - тем больше вес Ваших утверждений падает, не обижайтесь

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

чуть более развитых и динамичных языках в качестве тэга используют штуки

Не удержался - а что Вы делаете в этом треде?

Более того, я передал int в функцию const int

Разницы нет (даже в сигнатурах), и мы оба это знаем ;)

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

Так, стоп. А с множественным наследованием что не так?

А с множественным наследованием что не так?

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

Не удержался - а что Вы делаете в этом треде?

Четвертую звезду набиваю — что же еще?

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

Смущает. Что-то не так.

Четвертую звезду набиваю — что же еще?

А, ну если в этом счастье - «растворяюсь в тумане» :)

Не удержался - а что Вы делаете в этом треде?

Он любит обосрать то что не осилил, с растом тоже самое недавно было.

Четвертую звезду набиваю — что же еще?

Я могу поинтересоваться где Вы территориально?

Он любит обосрать то что не осилил, с растом тоже самое недавно было.

В расте не силён, а потому - без комментариев.

Он любит обосрать то что не осилил, с растом тоже самое недавно было

Отличная история. Я так понимаю, питон я тоже не осилил?

Отличная история. Я так понимаю, питон я тоже не осилил?

Шутка

Я достаю Питон из широких штанин
Дубликат бесценного груза.
Читайте, завидуйте, я -
Гражданин Советского Союза.

Я могу поинтересоваться где Вы территориально?

Украина. Пообщаться со мной приватно можно по почте мой_ник@gmail.com.

Ты сам следишь за тем, что пишешь?
В C есть forward declarations и функции.
В C/C++ есть forward declarations и функции, а еще pimpl-idiom.
Дальше ты говоришь, что «сишка лучше». Ты в порядке?

Я слежу. И некто писал выше:

С++ можно условно разделить на два уровня. Базовый язык – (за вычетом некоторых расхождений) С (возможно, с классами), и ++ сверху. Отношение достаточно сильно напоминает отношение TS и JS.

Очевидно, что он сравнивает «С» и «++».

Украина. Пообщаться со мной приватно можно по почте мой_ник@gmail.com.

https://ru.wikipedia.org/wiki/Буковина

Букови́на (буквально страна бука; укр. Буковина, рум. Bucovina) — историческая область в Восточной Европе. В настоящее время её северная часть (Северная Буковина) составляет Черновицкую область Украины (без Днестровского района), а Южная Буковина — румынский жудец Сучава.

А «3y», что означает?

Украина. Пообщаться со мной приватно можно по почте мой_ник@gmail.com.

Ok, я услышал. Есть ненулевая вероятность что договоримся ;)

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

Вы, видимо, о C++ наслышаны лишь поверхностно, поэтому вам кажется, что вопрос выглядит риторическим.

В некоторых местах в C++ можно получить исключение из-за действий, выполняемых самой языковой или библиотечной фичей. Например, при оборачивании лямбды в std::function или при создании новой короутины можно поймать bad_alloc и это вообще никак не будет связано с кодом, который пишет пользователь.

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

По моей ссылке

Есть конкретный пропозал по добавлению паттерн-матчинга в C++. На данный момент третья редакция: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf

Но масштабируется по уровням абстракций это дело отвратительно.

Опять бездоказательные эмоции? Пример можно?

Любая относительно глобальная ячейка variant с непримитивным значением рано или поздно приходит к этому состоянию.

Бла-бла-бла. Хватит уже говно из вашей башки изливать. Есть конкретный пример? Если есть, то показывайте.

То есть, исключения обработаны, локальные ресурсы корректно высвобождены, но исключение было брошено при изменении variant

То что?

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

Любое другое использование проблемного variant – это алгоритмическая ошибка программиста. А раз она допущена, то нет смысла рассматривать случаи, когда variant пошел в паттерн-матчинг и там не обработали ситуацию с отсутствием значения.

Если же в вашем коде строгая гарантия или nothrow-гарантия, то у вас не будет проблемного экземпляра variant.

Любой идентификатор для определения типа значения в tagged union.

Тогда мы возвращаемся к тому, о чем я вам уже говорил: в случае std::variant (или любого его аналога) вы в compile-time имеете список типов и какой-то «неожиданный» элемент в этом списке у вас появится не может.

Предлагаю сравнить с C#

От графомана с проблемами в логических цепочках подобного сравнения и стоило ожидать. Тут у нас как бы C++, нативный язык, где во главу угла ставится zero cost. А вы ему пытаетесь противопоставить язык со сборкой мусора, с неконтролируемыми программистом расходами на создание экземпляров reference types и т.д.

Так это один и тот же int!

Я там не вижу одного и того же int-а. Есть shared_ptr<int> и есть shared_ptr<const int>. Это разные типы.

Так что смысл вашего примера все еще не ясен.

Чоткие пацаны уже давно на JS перешли, эти всё на говне из двух плюсов пишут..

нафига блас тащить в язык?

это так нужно для дебилов, которые сами собрать не могут?

Removing Garbage Collection Support

во, хватит какашки тянуть везде.

нафига блас тащить в язык?

это так нужно для дебилов, которые сами собрать не могут?

Возможно авторы предложения сами реализуют для MS STL, libstdc++, libc++, так что будет меньше работы для разработчиков компиляторов 😀

Всегда отлично, когда авторы предложения дают и реализацию, а не только API, которое нужно реализовать 😀

К сожалению обсуждения предложений с комитетом не доступны в открытом доступе, но я спросил Guy Davidson, возможно тебе будет интересно: https://imgur.com/a/AWZyybw

Очевидно, что он сравнивает «С» и «++».

Нет, не сравнивает. Выше я уже это показывал.

Всегда отлично, когда авторы предложения дают и реализацию, а не только API, которое нужно реализовать 😀

Эта реализация ничего не стоит. Никто в здравом уме такое в stdlib не потащит. Сколько бегали с ренжами, форматом. Это треш трешака.

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

Это не рефлексия, а интроспекция. К тому же она на типах. Так, конечно, проще, но вместе с тем более ограниченно.

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

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

Есть конкретный пропозал по добавлению паттерн-матчинга в C++. На данный момент третья редакция: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf

Да, я видел, а может даже и линковал более раннюю редакцию. Хочу обратить внимание на:

The expression pattern has the form
constant-expression
and matches value v if a call to member e.match(v) or else a non-member ADL-only match(e, v) is contextually
convertible to bool and evaluates to true where e is constant-expression.

В высокоуровневых языках вся эта муть инкапсулирована средой выполнения и/или компилятором (поскольку базовые типы более высокоуровневы), и эта аналогичная логика хотя бы проще. Это как бы аргумент для:

Но масштабируется по уровням абстракций это дело отвратительно.

Опять бездоказательные эмоции? Пример можно?

Даже на элементарную функцию у тебя опять безумный ADL, выбирающий перегруженную функцию по своему хотению и щучьему велению. Какую бы фичу других языков C++ не скопировал — получится намного сложнее, многословнее, и ненадежнее.

Это парадокс C++, который привлек к нему толпу кодеров, но не позволил этим кодерам писать код: фич очень много, фичи на все случаи жизни, но почти все эти фичи намного хуже аналогичных фич в других языках. C++ является жалкой пародией на настоящее ООП, никакой инкапсуляции и гарантий надежности работы объектов-черных ящиков там нет, единственная полезная фича — это удобный механизм формирования vtable и удобный сахарок вызова оной (хотя можно поспорить по поводу гибкости в сравнении с Rust).

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

Минимально переработанный код из доков:

https://gcc.godbolt.org/z/hb3T4hhcv

Это очень круто, если ты можешь уследить за всеми-привсеми ветками выполнения и данными, корректно обрабатываешь те данные, которые не обработало RAII, но не все люди такие супермены, и даже некоторые супермены не могут справиться с чужой суперлапшой. И прежде всего я хотел бы, чтобы ты ответил на вопрос: откуда ты узнаешь, получилось ли у тебя после исключения корректное или некорректное значение variant? Или ты будешь параноидально копипастить валидацию variant в каждую щелочку?

У тебя что-то вроде рассказов «у меня в приложениях не бывает повреждений памяти» и «мои приложения не текут, поскольку я пишу на C++».

Тогда мы возвращаемся к тому, о чем я вам уже говорил: в случае std::variant (или любого его аналога) вы в compile-time имеете список типов и какой-то «неожиданный» элемент в этом списке у вас появится не может

Про любой аналог я бы не был так уверен, потому что он может быть слишком «любой».

Я там не вижу одного и того же int-а. Есть shared_ptr<int> и есть shared_ptr<const int>. Это разные типы

Смысл моего примера в том, что код на вход подает мутабельную ячейку (посколько он ее менял), но код сохраняется в хранилище незименяемых значений. Проблема в том, что уровни косвенности/контейнеры запрещают такое делать — придется разворачивать-копировать контейнеры. При том, что, подчеркиваю, каст идет из shared_ptr<int> в shared_ptr<const int>, то есть, из изменяемой ячейки в константную, что, казалось бы, по всем законам логики не должно представлять никакой проблемы.

к сожалению, в C++ настолько уродливая (и не полная) реализация ФП-шных конструкций, что лямбдами тут не поможешь

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

и ведь уже 40 лет как продолжается, ан нет, фанатики продолжают фанатеть, и, что самое печальное, смущать младые умы. Возможно им кажется, что чем больше им приходится потратить времени/ментальных усилий на обучение/написание кода/дебаг итп - тем они умнее. Но ребят, вы не умнее, вы просто задротнее!

и ведь уже 40 лет как продолжается, ан нет, фанатики продолжают фанатеть, и, что самое печальное, смущать младые умы

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

A proposal to add linear algebra support to the C++ standard library

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

Видимо потом захотят засунуть GUI тулкит

Guy Davidson изначально и хотел добавить 2d в стандартную библиотеку С++. И говорил, что 2d был ещё с Borland C++ в DOS и т.д.

В комитете С++ ему сказали, что для 2d нужны всякие матричные операции и прочее чего пока нет в стандарте, и добавлять это в один пропозал вместе с 2d не выйдет, так как это будет огромный пропозал.

Так и появился пропозал по добавлению линейной алгебры в С++ :)

Вот видео презентация по добавлению 2d графики в С++: https://www.youtube.com/watch?v=7Jk1a4cnukQ

Хорошо что отклонили

Вроде просто отложили до С++26, а не отклонили.

Опять оно здесь беснуется.

Даже на элементарную функцию у тебя опять безумный ADL, выбирающий перегруженную функцию по своему хотению и щучьему велению. Какую бы фичу других языков C++ не скопировал — получится намного сложнее, многословнее, и ненадежнее.

Показываешь фичу, которую С++ откуда-то скопировал. Ты ведь не балабол?

Минимально переработанный код из доков:

Что ты там переработал, копипаста?

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

Берёшь x = a; {x = b;} read(x); - показываешь, каким образом ты реализуешь вариант на двух состояниях.

И говорил, что 2d был ещё с Borland C++ в DOS и т.д.

А ну раз в бездарном мусоре был, то да. Повторение за помойкой не делает C++ помойкой.

И ни ты ни он так и не ответили - нахрена нужна какая-то линейная алгебра в стандарте? Понятно, почему она нужна в стандарте в случае со скриптухой. На ней невозможно реализовать эту логику, поэтому приходится реализовывать на уровне ni/ffi/vm и прочего.

Borland C++ в DOS

Этот мусор из той же оперы.

И ни ты ни он так и не ответили - нахрена нужна какая-то линейная алгебра в стандарте?

1. Это удобнее. Вот один из коментариев в том же Reddit:

Dear developers. my name is Riccardo Rossi, I am a university professor in the field of numerical methods. I would like to vocalize that standardization of linear algebra is a sorely missing feature in c++. on one side relying on libraries like ublas or eigen is not "standard" and relies on the good will of people developing the lib, on the other side linking and distributing blas is ALWAYS a pain. for these reason i would really like to give an upvote to take a decision about the "way to go" from this point on

2. Это позволит в будущем добавлять в стандарт возможности, которые зависят от линейной алгебры.

Это удобнее. Вот один из коментариев в том же Reddit:

Это не удобнее. Пусть лучше он осилит C++ - там никакая дистрибуция либам ненужна.

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

Потому как ладно, в стандарт добавится блас, и? Это будет как минимум 3 разных либы. Потому что маздайский мусор - это маздайские проприетарный мусор. Гнутая стдлиба и шланговская - разные лицензии.

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

Поддерживать две либы в разных stdlib никому не упало. У них будет разное качество и его код будет качества непостоянного. Зачем? Чтобы что? В чём проблема использовать одну общую либу, которая будет общая и одного качества.

Это позволит в будущем добавлять в стандарт возможности, которые зависят от линейной алгебры.

Это не ответ. «Ненужно добавить нужно для того, чтобы потом добавить ненужно, которые зависят от ненужно».

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

Классы и iostreams – не крестовые фишки. Это все еще сишка с классами.

И это вроде как C++ по-твоему, да? А по-моему это уже вполне себе «сишка» и она «лучше».

Да, это сишка с классами. Нет, это не «лучше».

М-м-м, идемпотентные методы с зомби-объектами, как вкусно. Правда, я пока что не понял, как на этом фоне будет обрабатываться СЛОЖНАЯ логика обработки исключения.

Шиза какая-то. Если мне важно удостовериться в том, что close отработал корректно, я могу проверить это в сишке, и могу проверить в С++. Если мне это не важно, я могу это не проверять в сишке, и могу не проверять в С++. При этом в сишке я вынужден писать руками close во всех случаях, а если это сишка с классами, то еще и проверять exception safety.

в 99% случаев мне глубоко наплевать, удачно отработает close или нет

Суть крестовой обработки ошибок.

https://github.com/byko3y/python-shared-objects/blob/33fe95e3dab9abb499d04e3dc83af0e7878ac4d5/src/shm_memory_linux.c#L96

https://github.com/byko3y/python-shared-objects/blob/33fe95e3dab9abb499d04e3dc83af0e7878ac4d5/src/shm_memory_linux.c#L113

Суть сишной обработки ошибок.

я могу спокойно присваивать между этими типами

Между многими типами можно «спокойно присваивать». Это не делает их эквивалентными.

и даже превращать int& в const int&

Можешь еще volatile добавить. Дальше что? Как возможность добавления модификаторов к типам делает их эквивалентными?

Я их уже написал.

Нет. Было нагнетание эмоций, конкретики не было.

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

Пример в студию.

Если паттерн-матчинг простой, то и смысла в нем мало.

Заблуждение. Вы, видимо, на C++ толком и не писали ничего, тем более вам не приходилось выписывать std::visit помногу раз. Отсюда и такой лютый бред в ваших постах.

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

А вы что, всерьез считаете C++ высокоуровневым?

Тогда у меня для вас плохие новости. C++ более высокоуровневый, чем C или Modula-2, но не такой высокоуровневый как Java или C#, не говоря уже про OCaml, Scala, Haskell и т.д.

То, что вы подходите к C++ с лекалами из того же C# – это показатель. Впрочем, гипотезу про отсутствие у вас мозгов я уже высказывал, пока что она подтверждается.

Это как бы аргумент для:

Очередной бездоказательный как бы аргумент. Ну ожидаемо.

Конкретика хоть какая-то будет?

Про любой аналог я бы не был так уверен, потому что он может быть слишком «любой».

Ну так опровергните мое мнение примером. Тут достаточно всего лишь одного примера. Но это ведь нужно суметь в конкретику, а…

Смысл моего примера в том, что код на вход подает мутабельную ячейку (посколько он ее менял), но код сохраняется в хранилище незименяемых значений. Проблема в том, что уровни косвенности/контейнеры запрещают такое делать — придется разворачивать-копировать контейнеры. При том, что, подчеркиваю, каст идет из shared_ptr<int> в shared_ptr<const int>, то есть, из изменяемой ячейки в константную, что, казалось бы, по всем законам логики не должно представлять никакой проблемы.

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

И, тем более, я все еще не понимаю, каким образом это все относится к паттер-матчингу.

ЗЫ. По поводу variant-а и valueless_by_exception нужно будет написать отдельно.

Минимально переработанный код из доков:

https://gcc.godbolt.org/z/hb3T4hhcv

И мы здесь видим как раз нарушение того, о чем я писал выше:

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

В показанном вами примере исключение перехватывается, но после перехвата почему-то считается, что значению var можно доверять. Хотя в случае, когда мы имеем лишь базовую гарантию, такого доверия у нас быть не должно.

При базовой гарантии мы можем лишь быть уверены в том, что:

• можно без проблем разрушить var (нигде ничего не утечет и не поломается);
• можно без проблем присвоить var новое значение (опять же, нигде ничего не утечет и не поломается).

Пытаться использовать значение var в таких раскладах – это путь к приключениям на собственную задницу.

Если программист включает голову, то желания поиметь такие приключения у него не будет. А значит и variant-ы с valueless_by_exception у него в программе появляться не будут.

И прежде всего я хотел бы, чтобы ты ответил на вопрос: откуда ты узнаешь, получилось ли у тебя после исключения корректное или некорректное значение variant?

Ниоткуда, я априори буду считать, что корректного значения внутри variant не будет. Но об этом я как раз уже писал, очень надеюсь, что вы сможете это осилить.

У тебя что-то вроде рассказов «у меня в приложениях не бывает повреждений памяти» и «мои приложения не текут, поскольку я пишу на C++».

Как бы изрядная часть написанного мной кода в OpenSource, если бы там случались «повреждения памяти» и «утечки памяти», то об этом бы быстро стало известно.

Допустить что-то подобное при написании кода не так уж и сложно (хотя на C++ сделать это сложнее, чем на чистом Си, особенно на современных плюсах). Такое регулярно происходит.

Но вот отправить код с подобными проблемами в продакшен… Это случается на порядки реже. И тут вопрос не столько в написании кода, сколько в его тестировании.

А тестировать, как показывает практика, нужно и код на Java, и код на Ruby, и код на Haskell-е. Причем код на динамических языках, вроде Python/Ruby, тестировать нужно даже больше.

I would like to vocalize that standardization of linear algebra is a sorely missing feature in c++

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