2014 dxdy logo

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки




На страницу Пред.  1, 2
 
 Re: Тип dependent sum в C++
Сообщение22.10.2019, 15:58 
arseniiv в сообщении #1421967 писал(а):
А cppreference пишет, что не совсем любые:
Да, действительно. Я как-то не подумал, что под слово "любые" эти случаи тоже подходят. Впрочем, Qt-шные действительно годятся.

 
 
 
 Re: Тип dependent sum в C++
Сообщение22.10.2019, 17:08 

(Оффтоп)

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

 
 
 
 Re: Тип dependent sum в C++
Сообщение22.10.2019, 18:16 

(Оффтоп)

realeugene в сообщении #1421992 писал(а):
Когда-то давным-давно на заре плюсов читал историю, что когда-то был такой очень популярный язык PL/I. И он был настолько популярен, что в него постоянно добавляли всем так необходимые новые фичи. В результате руководство по нему разрослось до размеров, которые мало уже кто мог осилить. И язык умер.
Я еще застал PL/I (хотя и на излете), и тогда это действительно выглядело страшно. Сейчас - на фоне нынешних стандартов C++ - смешно вспомнить, что это считали сложным языком с гигантским количеством возможностей.

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

 
 
 
 Re: Тип dependent sum в C++
Сообщение22.10.2019, 18:35 
К слову, вот исходник std::variant из gcc: https://github.com/gcc-mirror/gcc/blob/ ... td/variant
У меня он вызывает священный трепет.

 
 
 
 Re: Тип dependent sum в C++
Сообщение22.10.2019, 20:11 

(Оффтоп)

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

 
 
 
 Re: Тип dependent sum в C++
Сообщение22.10.2019, 20:22 

(arseniiv)

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

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

 
 
 
 Re: Тип dependent sum в C++
Сообщение23.10.2019, 13:20 
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 где каждый тип описан компактно в массивах однородных данных, рисуется через инстансинг и т.п.

 
 
 [ Сообщений: 22 ]  На страницу Пред.  1, 2


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group