LINUX.ORG.RU

Полиморфные функции в С++


0

0

Доброе время суток

Последнее время думал над разницей в реализации шаблонов функций в C++ и полиморфных функций в Haskell; и вот вчерашнее обсуждение подтолкнуло меня к мысли о том, что полиморфные функции в С++ могут быть введены сразу же с введением концепций из C++0x : по сути концепция, описывающая неявный интерфейс в С++ является аналогом класса типов Haskell'а; уточняя с какой концепцией ведётся работа в шаблоне мы имеем возможность избежать генерации избыточного обьектного кода. Комментарии ?

★★★★★

>уточняя с какой концепцией ведётся работа в шаблоне мы имеем возможность избежать генерации избыточного обьектного кода. Комментарии ?

Так... Уточни, как ты видишь уменьшение объектного кода? Что-то такое:

Было:

функция_для_типа_А

функция_для_типа_Б

функция_для_типа_С

...

Стало:

1часть_функции_не_зависящая_от_типа

2часть_функции_для_типа_А

2часть_функции_для_типа_Б

2часть_функции_для_типа_С

Так?...

Sectoid ★★★★★
()
Ответ на: комментарий от Sectoid

>Так... Уточни, как ты видишь уменьшение объектного кода?

на данный момент неявный интерфейс в С++ на уровне языка не поддерживается - о нём знает программист, но не знает компилятор. различные проверки вроде boost.concept_check - это user level, и практически они имеют только наблюдательные качества. если же компилятор будет иметь информацию о том, с какой концепцией происходит работа в шаблоне (т.е. набор всех возможных выполнимых операций над сущностью), он будет иметь возможность провести все возможные в данном случае оптимизации. и выглядеть будет где-то так - весь код функции в единственном экземпляре, просто на точках доступа к операциям, выполняемым над сущностью - что-то вроде vtable. если я, конечно, правильно понимаю механизм реализации полиморфных функций вообще :)

jtootf ★★★★★
() автор топика
Ответ на: комментарий от jtootf

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

Идея с vtable imho не особенно удачна, т.к. придется изобретать костыли с вычислением отступов локальных переменных (если локальная переменная имеет тип параметра шаблона), вероятно создавать таблицы этих отступов и париться с этими vtable. Плюс к этому потенциально ограничивается возможность оптимизации, т.к. структура функции будет фиксироваться точками ветвления, связанными с типами, и компилятор не сможет выбрасывать куски кода.

YesSSS ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.