Тип dependent sum в C++

[Pphantom]

arseniiv в сообщении #1421967 писал(а):

А cppreference пишет, что не совсем любые:

Да, действительно. Я как-то не подумал, что под слово "любые" эти случаи тоже подходят. Впрочем, Qt-шные действительно годятся.

[realeugene]

(Оффтоп)

Когда-то давным-давно на заре плюсов читал историю, что когда-то был такой очень популярный язык PL/I. И он был настолько популярен, что в него постоянно добавляли всем так необходимые новые фичи. В результате руководство по нему разрослось до размеров, которые мало уже кто мог осилить. И язык умер.

[Pphantom]

(Оффтоп)

realeugene в сообщении #1421992 писал(а):

Когда-то давным-давно на заре плюсов читал историю, что когда-то был такой очень популярный язык PL/I. И он был настолько популярен, что в него постоянно добавляли всем так необходимые новые фичи. В результате руководство по нему разрослось до размеров, которые мало уже кто мог осилить. И язык умер.

Я еще застал PL/I (хотя и на излете), и тогда это действительно выглядело страшно. Сейчас - на фоне нынешних стандартов C++ - смешно вспомнить, что это считали сложным языком с гигантским количеством возможностей.

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

[realeugene]

К слову, вот исходник std::variant из gcc: https://github.com/gcc-mirror/gcc/blob/ ... td/variant
У меня он вызывает священный трепет.

[arseniiv]

(Оффтоп)

realeugene в сообщении #1421972 писал(а):

Т. е. до оптимизации по памяти его можно безболезненно заменить на struct из альтернатив.

Ну я не знаю, я бы не воспринимал это как оптимизацию. Это очень страшно (мне), перерасход памяти растёт почти линейно по количеству вариантов, по-моему такое нельзя иметь в коде почти никогда, когда такие объекты собираются ещё и в какие-нибудь коллекции по много штук. Особенно на фоне и ООП-ной альтернативы, и уже упомянутых. Я правда не понимаю, что можно увидеть страшного даже в union. Можно писать криво с использованием чего угодно.

[realeugene]

(arseniiv)

arseniiv в сообщении #1422015 писал(а):

Это очень страшно (мне), перерасход памяти растёт почти линейно по количеству вариантов

С современным количеством оперативки это может стать критичным только в случаях с очень большим количеством объектов. Но и в этом случае std::variant может быть не лучшим выходом, так как он имеет размер, равный максимальному размеру содержимого плюс размеру поля индекса типа size_t. Для каждой точки в списке. Раздельные массивы по типам фигур могут оказаться гораздо эффективнее.

https://en.cppreference.com/w/cpp/utility/variant/visit - std::visit требует по перегруженной функции для каждого сочетания типов в посещаемых вариантах. Вручную такие методы в визиторе писать утомительно, но у нас есть шаблоны! Отличная экспоненциальная граната.

[aa_dav]

george66 в сообщении #1421928 писал(а):

Но для плоскости одно число и тип параметров, для прямой другое, а для точки третье. Это то, что в функциональных языках называется dependent sum type. Можно ли это сделать в C++?

Эта задача стала одной из тех из которых вырос классический ООП.
Например вот тут Алан Кэй (создатель Smalltalk и пионер в области ООП в целом) пишет: http://userpage.fu-berlin.de/~ram/pub/p ... kay_oop_en

Цитата:

"...the early work of Doug Ross at MIT (AED and earlier) in
which he advocated embedding procedure pointers in data structures,
Sketchpad (which had full polymorphism — where e.g. the same offset
in its data structure meant "display" and there would be a pointer to
the appropriate routine for the type of object that structure
represented, etc...."

То есть да, он относит к зарождению ООП в том числе момент когда некто Doug Ross из MIT вложил указатели на код в данные визуального редактора Sketchpad со смыслом "нарисовать себя", а это полиморфизм и предыстория ООП.
В общем в рамках C++ никаких variant тут не надо - нужны классы с объектами как уже в общем то показали.
Полиморфные (ООП) объекты надо хранить по указателям - например в контейнере std::vector< Figure * > и внешний код в идеале не должен обращаться к полям этих объектов - только давать им методы по смыслу типа "нарисуй себя" или "находишься ли ты по координатам (x,y)?", хотя если речь про OpenGL может быть будет уместно что-то вроде "сложи мне свои трианглы в вершинный буфер сюда то" - тут по объёму задачи и сложности рендера надо смотреть.
Для очень большого числа объектов и массивной отрисовки бывает смысл отказываться от ООП и переходить на какой нибудь data-driven где каждый тип описан компактно в массивах однородных данных, рисуется через инстансинг и т.п.