Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата korvin @ 22.03.12, 09:26

Цитата --Ins-- @ 22.03.12, 09:14

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

Не, не работает, у меня в предыдущем посте вон сколько приклеенных

Цитата D_KEY @ 22.03.12, 09:24

instance ScalarProduct a => ScalarProduct (Cons a) where scalarProduct (Cons n1 a1) (Cons n2 a2) = n1 * n2 + scalarProduct a1 a2

Во что, согласно твоему подходу, должен быть скомпилирован такой инстанс?

в что-то вроде

compiler.instances[ScalarProduct, Cons] = new Instance {
  scalarProduct = new Function (c1, c2) {
    // compile body
  }
}

Что-то меня на этой неделе переклинило, я взял себя в руки и допилил-таки почти до конца свои мультиметоды. Дореализовано:

• возможность использовать параметры, не требующие позднего связывания;
• раннесвязываемые параметры могут иметь любые типы включая квалифицированные и ссылочные (возможно - не проверял - кроме исходно volatile, иначе, боюсь, резко упадёт производительность);
• однопараметрические мультиметоды (в целом в их поддержке есть определённый смысл);
• беспараметрические мультиметоды (до кучи, бессмысленно, но было несложно).

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

• C++98 больше не поддерживается, требуется C++03. Это связано с использованием сведений ссылок. Пофиксать несложно, по меня просить - я вас умоляю. Так что у кого несвежий MSный компилер, будут получать ошибки reference to reference is illegal.
• Не используется C++11. Просто потому, что его поддержка ещё весьма хромает, и старые компиляторы ещё приличное время будут оставаться на сцене, тогда как переписать списки типов на вариадики, если кому надо - дело получаса.
• Позднесвязываемые параметры могут приниматься только по неквалифицированному указателю. Впрочем, возможно, что только пока. Мне как-то лениво параметризировать политикой кортежы. Кому надо, могу помочь советом, что где и как изменить, а там глядишь, через полгода у меня снова руки дойдут. (Хотя, я вот подумал, если за спиной у диспетчеров взять и квалифицировать как требуется параметры у своих перекрытий, то возможно всё и срастётся благодаря неявным кастам.)
• И наконец, готовьтесь видеть отчёты об ошибках, длиной в парсеки, если где напутаете с параметрами, типами или неоднозначностью . Впрочем, если ошибка длиной в парсек, то вероятно дело в неверном вызове вами диспетчера. Если ошибка возникает уже при вызове диспетчером вашего перекрытия, то тексты скорее всего будут довольно коротки, понятны и даже не сильно-то и отличаться от текстов при подобных ошибках с вызовами обычных методов и функций.

Осталось только причесать, покоментить, очень сильно потестировать и можно в буст .

Добавлено 10.06.12, 19:28
Да, сложность осталась прежней - два виртуальных вызова на каждый позднесвязываемый параметр. Всё остальное обрабатывается в статике, весьма хорошо оптимизируется, поэтому основным оверхедом будут вызовы конструкторов копии для объектов, передаваемых по значению.

Qraizer
линк?..

Ну, ещё причёсывается.
Вообще вот думаю, куда выложить. Сюда можно, тут где-то был предыдущий релиз. Можно в C++ Общие, но тема как бы не для обсуждения проблемы. Можно в FAQ, но на часто задаваемый вопрос вроде не тянет. В Наших Проектах вроде самое то, но как-то мелковато.

Цитата Qraizer @ 11.06.12, 12:33

Сюда можно, тут где-то был предыдущий релиз

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

Сообщение отредактировано: --Ins-- - 11.06.12, 13:32

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

Добавлено 11.06.12, 14:44
Вроде причесал. Счас ещё хоть чуток тестов напишу. Нормальных, а не тех, что родились в процессе процесса. Что б можно было как примеры использования показывать.

может Github или Bitbucket?

Сообщение отредактировано: Radagast - 11.06.12, 20:17

Не-не-не. Первая публикация будет исключительно на Сорсах. А дальше хоть в CodeProject, хоть в буст, хоть куда.

Цитата Qraizer @ 11.06.12, 21:40

Не-не-не. Первая публикация будет исключительно на Сорсах.

Why?

Qraizer, у нас вообще-то раздел есть для таких вещей: Наши Исходники

Кстати, когда они уже будут?

Этот процесс называется "начал писать программу-будильник и не заметил, как написал свою ОС". Как только начал тестить, заметил, чде что подпраивть и улучшить можно. Теперь не остановлюсь всё никак.

Цитата Qraizer @ 28.06.12, 11:33

Этот процесс называется "начал писать программу-будильник и не заметил, как написал свою ОС". Как только начал тестить, заметил, чде что подпраивть и улучшить можно. Теперь не остановлюсь всё никак.

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

А здесь что сравнивают: возможности самих языков или же их реализаций (компиляторов в среде запуска)?