"шаблоны (templates) рулят"

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

(Reply to this) (Thread)

А вы предлагаете каждый раз, когда нужен, скажем, связанный список для нового типа, писать его с нуля, с новыми глюками? Разработчики первоначальной версии программы, о которой я говорю, сперва так и сделали. Потом по своему же адресу сказали немало тёплых слов.

Нет, есть, конечно, люди, которые тащатся, в тысячный раз реализуюя хэш-таблицу, динамический массив или, там, бинарный поиск. Но я к их числу не отношусь. "Не мой кайф".

(Другое дело, что по сравнению с воспетыми Луговским макросами Common Lisp, или с системой типов Хиндли — Милнера, позволяющей просто не указывать типы там, где это не надо, шаблоны — отстой. Но речь-то о C++).

(Reply to this) (Parent) (Thread)

>А вы предлагаете каждый раз, когда нужен, скажем, связанный список для нового типа, писать его с нуля, с новыми глюками

Написать список один раз для типа Object, потом пихать туда объекты соответсвующего типа, при извлечении -- мануально преобразовывать обратно. Немного некрасиво, но никаких реальных трудностей не несёт.


>Но речь-то о C++
...который, в отличие от C, годящегося для написания ОС, не годится вообще ни для чего.

(Reply to this) (Parent) (Thread)

Написать список один раз для типа Object, потом пихать туда объекты соответсвующего типа, при извлечении -- мануально преобразовывать обратно. Немного некрасиво, но никаких реальных трудностей не несёт.

Ага, но "есть один нюанс"© — хранить так можно только потомки Object. А это

• слегка неудобно, когда типы, которые вам надо хранить — например, целые в одном случае и вещественные в другом;


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

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

(Reply to this) (Parent) (Thread)

1. Ну, я не одобряю т.н. "простые типы"

2. Перегрузка операторов не обязательно должна быть статической. Вроде, что-то подобное реализовано в Перл, хотя я не разбирался и никогда не пытался использовать.

(Reply to this) (Parent) (Thread)

Ну, я не одобряю т.н. "простые типы"

А, Java любите, небось? "Что ж, понимаю".

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

Дык, Перл-то динамически типизированный, там и не такое бывает.

(Reply to this) (Parent) (Thread)

Java -- не очень. ПРостые типы ненавижу, например, и ещё множественного наследования очень не хватает.

(Reply to this) (Parent) (Thread)

А вот кстати — вам какой-то из популярных ЯП нравится, если не секрет? Широко используемый ЯП без простых типов и со множественным наследованием я навскидку могу назвать один — Питон. Но он местами тоже очень странен.

(Reply to this) (Parent)

...который, в отличие от C, годящегося для написания ОС, не годится вообще ни для чего

Дык, о чём и речь: библиотеки для осмысленного программирования десктопных приложений есть в основном под языки, которые уродливы целиком (С++), либо имеют достаточно неприятные стороны (Java, С#, Python).

Конкретно с C++ открытие в том и заключалось, что у него есть ряд уродств, лекарства от которых часто хуже болезни (например, ошибки в программе с активным использованием templates это отдельная боль, о да). Но без них он не просто уродлив, а недопустим к использованию. Так что шаблоны таки рулят. Потому что без них наступает такое, из чего проекту не выбраться живым (кстати, придумал ещё один уродливый способ обойтись без шаблонов, дорогие коллеги его на днях, кажется, чуть было сгоряча не использовали — сериализация и хранение char*).

(Reply to this) (Parent)

Или вы сторонник фокусов типа хранения void*?

(Reply to this) (Parent) (Thread)

void* не позволяет делать instanceof, если б это было возможно -- пожалуй. сошёл бы и он.

(Reply to this) (Parent) (Thread)

Ну, instanceof в C++ нет, потому что там нет нормальной метаобъектной системы. Но в принципе — есть typeid.

Собственно, это и есть 10 правило Гринспуна в полный рост. "Стоило делать статически типизированный язык".

(Reply to this) (Parent)

По поводу схемы рекомендую посмотреть блог ketmar и пообщаться с ним, в частности: постинг о klisp. Предупреждая закон Гринспуна, он реализовал схему, встроил её в свои проекты, и таким образом легко перемещает код между С и Лиспом. Поэтому можно расширить сознание и не мыслить в чёткой дихотомии "или весь проект на схеме, или ничего"... ведь можно, программируя на _некотором языке_, использовать схему в той и только той мере, в которой ты готов её использовать.

(Reply to this) (Thread)

Спасибо.

Однако, мы с ним по поводу этого интерпретатора уже общались. К сказанному в том треде могу добавить только, что KLisp, кажется, и не Scheme вовсе — по крайней мере, я не обнаружил на странице проекта никаких ключевых слов типа, собственно, "Scheme" или, там, "R5RS".

Если мне нужна будет scripting engine, я, наверное, схвачусь всё-таки за Guile — не лучшую, но зато наиболее применимую практически реализацию. Но это всё же не то (почему — я пытаюсь объяснить в треде по ссылке).

(Reply to this) (Parent)