[C++?] Серьезный вопрос.

> А можно понизить градус абстрактности, а то как-то не воспримается?

тебе уже сказали - расскажи, что делать будешь с открытием дверей ключами (это тоже самое).

>А если у тебя варьируются не только данные, а алгоритмы?

http://www.sgi.com/tech/stl/sort.html обратить внимание на class StrictWeakOrdering

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

> Ты прежде чем пытаться уныло троллить, хоть чуточку просветись в вопросе троллинга.

Дурачок, comp - это function object, т.е. эта функция сортировки и является high order function.

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

>А можно понизить градус абстрактности, а то как-то не воспримается?

Ну есть у тебя иерархия идущая от базового класса "Entity". Например какое-нибудь ынтерпрайзное говно типа "Account", "Order", "Employee" итд в том же роде. Есть множество таких же унылых ынтерпрайзных операций: сериализовать для RPC, занести в БД, логировать, отобразить на графике, тид.

Расклад такой: a) количество операций которые должны будут над этими сущностями совершаться неизвестно наперед и будет постоянно расти, их нельзя оформить в виде виртуальных функций б) Эти операции нужно вносить не трогая код классов-сущностей, так как в рамках каждой подсистемы будет свой сет операций и писать их будут разные программисты.

Налицо необходимость в двухмерной диспетчеризации - множество сущностей X множество операций.

> Налицо необходимость в двухмерной диспетчеризации - множество сущностей X множество операций.

Какое решение с вашей точки зрения будет красивым? (язык любой)

Note: я ни с чем не спорю, мне интересно. спасибо

>Это с какими же? Оперативная память со свойством склероза чтоли?

ну что я говорил? типичный же представитель

>ты не осилил асм и затаил злобу на всех, кто овладел этим чудным инструментом

ты знал! ты знал! :)

>> Налицо необходимость в двухмерной диспетчеризации - множество сущностей X множество операций.

>Какое решение с вашей точки зрения будет красивым? (язык любой)

В жабе и ++ тут обычно делают switch по метке сущности которую получают из виртуальной функции. Можно соорудить Visitor, но он не пользуется популярностью и обладает радом крупных недостатков. Напрашивается мультиметод зависящий от двух рантаймоваых параметров: сущность и операция.

> В жабе и ++ тут обычно делают switch по метке сущности которую получают из виртуальной функции. Можно соорудить Visitor, но он не пользуется популярностью и обладает радом крупных недостатков. Напрашивается мультиметод зависящий от двух рантаймоваых параметров: сущность и операция.

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

Также мультиметоды были в питоне - как расширение в http://peak.telecommunity.com/, сейчас проект мертв.

>Дарагой друх, а что такое есть частичная специализация шаблонов как не паттерн-матчинг?

паттерн-матчинг, да, только хреновый,- ограничений у него побольше чем у boost.lambda, а использование требует использования boost.enable_if сокомпания. очень удобно для вписывания в резюме слова SFINAE разве что - а вот в практической разработке больше проблем, чем пользы

Еще о языках. Заинтересовался вопросом из серии "серьезных". А что сейчас используется чаще из OCaml, Haskell и ... F#?

> С++ был моим первым языком программирования

Это очень заметно. Не обижайся, но тебя и твои мысли я тоже в коллекцию клинических крестофилов занес. Хотя до linuxfan тебе ещё работать и работать :)

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

C++ is an octopus made by nailing extra legs to a dog (c) Как то так :)

> Еще о языках. Заинтересовался вопросом из серии "серьезных". А что сейчас используется чаще из OCaml, Haskell и ... F#?

OCaml

>А что сейчас используется чаще из OCaml, Haskell и ... F#?

используется где? используется кем? используется для чего? что это вообще за вопрос такой?

впрочем, libastral говорит следующее:

http://www.google.com/trends?q=haskell%2C+ocaml%2C+f%23

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

(Вопрос знатокам) С какого ЯП лучше всего начать изучение функционального программирования?

LISP, Haskell, Scheme, ML?

>LISP, Haskell, Scheme, ML?

http://kmmbvnr.livejournal.com/62197.html

> что это вообще за вопрос такой?

Это был общий вопрос. За ссылки спасибо. Между тем, "порадовала" статистика PHP :)

Получается, что все три языка применяются редко, а хаскель чаще цитируют.

jtootf во всем этом треде Вы самый невменяемый опонент, кричите тут, флудите, вместо того, чтобы конкретно отвечать на вопросы развели блин срач, человек же вроде серьезно вопрос задал. Может Вы пойдете остынете, правда лечится Вам надо

> Подумай, почему на С наивный подход double integral( double a, double b, double f(double) ) проваливается и тогда может быть поймешь, что и в С нужны лямбды, не только в плюсах. >Без лямбд приходится лепить void* например в >int pthread_create(pthread_t *thread, const pthread_attr_t *attr, >void *(*start_routine)(void*), void *arg);

Ну, если ты хочешь сказать, что этот код запутанный, то да, я с тобой соглашусь. Но ведь эта проблема запутанности элементарно решается с помощью typedef! Тебя этому в школе не учили? Для более изощерённых случаев есть boost, да и в С++0x лямбды будут!

>ООП - недоделанный (нет мультиметодов, не полностью объективный), метапрограммирование, точнее пародия на него через ужасные темплейты, система типов убогая донельзя

Мультиметоды можно реализовать самостоятельно и это было сделанно уже около 10 лет назад Андреем Александреску (почитай "Современное проетирование на С++") Сейчас же это часть boost. Темплейты вовсе не ужасны, а ужасно полезны и удобны (почитай того же Александреску и, например, "Порождающее программировоание" Чарнецки раздел про метапрограммирование на С++)

> И да буст - говно еще то. Использовать его себе дороже. Ну, конечно, у каждого своё мнение, но по-моему такие слова лишь свидетельствуют о том, что ты не смог разобраться в нём.

>сериализацию потока? сериализацию процесса? код решения удобными методами на C++ в студию! Тормозишь прцесс/поток, а далее юзаешь boost. Всё достигается простыми конструкциями. Да, конечно, вы можете сказать, например, что если в классе нету ручных динамических массивов. Но ведь в той же жабе любой массив по-сути вектор, а для векторов и в С++ всё элементарно. Описание с примерами можешь глянуть, например здесь: http://wiki.shelek.ru/index.php/C%2B%2B_сериализация_данных

>Куча народа начинала с ZX-бейсика, и ничаво.

Да, конечно, так тоже можно научится, но по-моему это будет дольше и сложнее, чем если начинать не с мёртвых языков.

>Pascal (благо учится легко и быстро, забывается так же. Но именно оригинальный виртовский паскакаль, не надо никаких объектных расширений и прочей ереси) -> C -> какая-нибудь высокая функциональщина типа хаскелля -> какой-нибудь вменяемый ОО язык -> и вот только теперь C++

Ну, не согласен с этим. По-моему оптимально как-то так: С->ассэмблер->C++ (причём при изучении представляем, как бы мы реализовали каждую конструкцию этого языка на асме)->java или что-то подобное, чтоб понять, как можно писать на чистом ООП->что-нибудь функциональное

>Расклад такой: a) количество операций которые должны будут над этими сущностями совершаться неизвестно наперед и будет постоянно расти, их нельзя оформить в виде виртуальных функций б) Эти операции нужно вносить не трогая код классов-сущностей, так как в рамках каждой подсистемы будет свой сет операций и писать их будут разные программисты.

Ну, можно для этих целей написать что-то своё на подобии COM, как делается в ряде случаев, можно заюзать Kpart, Bonboo, можно сваять что-то, например, на основе qtscript. Выбор за вами. Но, конечно, язык со статической типизацией здесь неоптимален.

>>Pascal (благо учится легко и быстро, забывается так же. Но именно оригинальный виртовский паскакаль, не надо никаких объектных расширений и прочей ереси) -> C -> какая-нибудь высокая функциональщина типа хаскелля -> какой-нибудь вменяемый ОО язык -> и вот только теперь C++

>Ну, не согласен с этим. По-моему оптимально как-то так: С->ассэмблер->C++ (причём при изучении представляем, как бы мы реализовали каждую конструкцию этого языка на асме)->java или что-то подобное, чтоб понять, как можно писать на чистом ООП->что-нибудь функциональное

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

Тесплейты ему не ужасны...

>Жуткие костыли представляем как единственный вариант нормы

Ну, во-первых, никаких совсем уж ужасных костылей нету. Да, кончено, для любой штуковины существует язык, где она реализована лучше, чем в С++. Но проблема-то в том, что какой-нибудь другая важная вещь в этом языке будет отсутствовать в-принципе, а => язык не будет подходить нам для решения задачи.

А шаблонные конструкции и метапрограммирование с их помощью вовсе не ужасно, если правильно организовать код. (Основываюсь хотя бы на книгах, указанных выше)

Q.E.D.

> А шаблонные конструкции и метапрограммирование с их помощью вовсе не ужасно, если правильно организовать код. (Основываюсь хотя бы на книгах, указанных выше)

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

>Ты еще си-диез предложи. Или паскакаль.

До-диез - если употребляешь русские буквы и музыкальную терминологию.

> Андреем Александреску (почитай "Современное проетирование на С++")

А на твой взгляд насколько близка к практике эта книга? Не является ли она сугубо теоретической? Может быть, в реальной жизни си-пи-пишные програмеры используют менее замысловатые подходы. А то местами заносит автора... Может быть, от скудости языка, с которым приходится периодически сражаться... Как думаешь, the_best_goose?

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

Да, в обычной жизни, мы нечасто применяем такие подходы, но мы постоянно используем boost и STL, которые были бы невозможны без этих подходов... Также такие подходы бывают полезны при написании собственных обобщённых библиотек.

Не соглашусь относительно STL. Он намного проще в смысле проектных решений. Например, там нет такого извращения как Typelist.

Люди, использующие Loki, говорят, что время компиляции резко увеличивается. И это в C++, который итак компилурует о-очень медленно. А с Loki так вообще тормоз редкостный получается. По-моему в консерватории что-то не так.

Так выходит, что все-таки труд Александреску на практике непосредственно вы не используете?

> Если ты живёшь или можешь переехать в нерезиновск, то учи плюсы, они по прежнему нужны. Во всей остальной стране только 1С.

Живу в Рязани. C++/Qt. Для поддержки старых проектов иногда нужна Delphi. 1С НИКОГДА (к счастью) не занимался, хотя знакомые 1Сники имеются. ЧЯДНТ?

Да, и ещё... у тебя описана довольно типичная ситуация:

> я разобщался с человеком, который уже насколько лет работал в нерезиновой программистом. Он мне и открыл глаза на мир: "Delphi здох. Его уже похоронили и забыли. Сейчас необходимо знание C++, C#. Необходимо занание паттернов проектирование". Вобщем много чего он мне наговорил.

Проверено: в 9 случаев из 10 чел, орущий "Паскаль говно, сипипи рулез", либо наоборот, толком не прочувствовал ни тот, ни другой. Главное для программиста - это не знание некоего набора синтаксисов и библиотек (хотя это тоже важно), а профессиональная культура. Не валить в один модуль логику и представление, комментировать код там, где надо, давать осмысленные имена, ставить, наконец, отступы, $# &^%$ @#, понимать, что в 90% случаев прозрачность кода важнее копеечной эффективности и вместе с тем выявлять те места, где эта эффективность оказывается далеко не копеечной, и др.

Человек, знающий несколько языков, в какой-то момент постигает, что незначительные синтаксические различия между Паскалем и C++ (к примеру) на структуру программы влияют гораздо слабее, чем принятая архитектура программы. К примеру, различие между гуёвыми программами, написанными на плюсах и дельфях, гораздо меньше, чем между гуёвой и консольной программой, написанных на одном языке.

Да, ещё: первый ответ насчёт русского языка был вполне уместен.

>Так выходит, что все-таки труд Александреску на практике непосредственно вы не используете?

Я использую boost, где всё это используется. Самому же делать такие проетные решения приходится редко, но понимать всё это необходимо, чтобы нормально освоится с boostом. Да, время компиляции действительно увеличивается примерно в 2 раза, но по-моему это не так критично.

> /me всегда сокрушался по поводу стабильно высокого спроса на 1С. программисты на С++ знают больше, а получают меньше.

Из фольклора 90-х:

"Пишешь на Си - зарплату не проси!"

> понимать, что в 90% случаев прозрачность кода важнее копеечной эффективности и вместе с тем выявлять те места, где эта эффективность оказывается далеко не копеечной

Ой, ну вот это точно не про плюсовиков. 90% их занимаются преждевременной оптимизацией и очень этим гордятся. А так как процесс утомительный, до реальной оптимизации часто руки не доходят. А потом появляются в блогах откровения: "Ой, внезапно выяяснилось, что моя утилитка xxx сливает в 5 раз подобной питоньей yyy на тех же входных данных! Что я делаю не так???"

>А потом появляются в блогах откровения: "Ой, внезапно выяяснилось, что моя утилитка xxx сливает в 5 раз подобной питоньей yyy на тех же входных данных! Что я делаю не так???"

Ну, быдлокодер, он и на С++, и на Python быдлокодер))

+ 1024

> Ну, быдлокодер, он и на С++, и на Python быдлокодер))

Нет, сам язык C++ располагает к преждевременной оптимизации.

> Хождение по граблям плюсов само по себе отнюдь не необходимо (в отличие от таких вещей, как "хождение по граблям многопоточного программирования", "все эти сложности для избегания goto"),

А зачем нужны сложностти для избежания goto -- уже обсудили? Лень читать тред.

>jtootf во всем этом треде Вы самый невменяемый опонент

спасибо на добром слове

>вместо того, чтобы конкретно отвечать на вопросы

какие например?

>человек же вроде серьезно вопрос задал

а я серьёзно на вопрос ответил. на который из, кстати?

>Может Вы пойдете остынете, правда лечится Вам надо

ко мне можно и на "ты", я не гордый

> Лень читать тред.

Это очень зря. Тут масса интересных ссылок по... Хаскелю! :)

> Чтобы не быть совсем голословным, давай я скажу, что написать quick sort на C можно, но его придется оборачивать в макрос/переписывать для сортировки целочисленных или вещественных массивов. В C++, благодаря template<typename ValueT>, ты будешь иметь эффективный qsort без необходимости ручного заката солнца.

И большая разница по эффективности и объёму работы между макросом вокруг qsort и шаблоном?

> И большая разница по эффективности и объёму работы между макросом вокруг qsort и шаблоном?

Огромная. Макрос хоть отладить можно, если вдруг что... 8))

> Это очень зря. Тут масса интересных ссылок по... Хаскелю! :)

Как и в любом другом си++ - сраче :)

> Это очень зря. Тут масса интересных ссылок по... Хаскелю! :)

Да, уже не выдержал и читаю.

>А зачем нужны сложностти для избежания goto -- уже обсудили? Лень читать тред.

Нет, в этом треде не обсудили. Но, имхо, и так всё понятно. Нас сплошных goto никто в наш просвещённый век не пишет. Вообще я хотел сказать, что программирование без goto заставляет правильно проектировать программу (да вообще хоть как-то проектировать и то хорошо), а этот скил лишним не будет. Обход плюсограблей лишь требует заучить места, где они лежат, скилов - никаких не образуется.

К счастью, мощь плюсов перевешивает грабли.

Haskell получается?

>Haskell получается?

да. не факт, что он подойдёт в продакшене (по той же производительности в результате может быть выбран *ML), но как язык для изучения ФП - самое то

>Тормозишь прцесс/поток, а далее юзаешь boost

эээ...щито? каким образом я должен заюзать boost, чтобы получить сериализацию потока? чтобы потом можно было его десериализовать и запустить снова?

при чём тут массивы/векторы - не уловил

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

Если хаскель это позволяет делать, то я буду только рад. Мне это очень интересно. Но первое впечатление такое, что с этим там будут проблемы. Пока же заинтересовался окамлем и его реинкарнацией f#.

> А как в хаскеле обстоит дело с циклическими структурами данных, которые все из себя императивные? Например, графы объектов.

Что-то типа http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Graph.html?

> А еще как быть с реализацией событийной модели, где есть объект, испускает событие, и есть другой объект, который слушает это событие?

Бррр... Либо я чего-то не понимаю, либо в чём проблема-то может быть?

> Что-то типа http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Graph.html?

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

А можно сделать так, чтобы объект а указывал на объект b, который в свою очередь указывал на объект а? То есть, два объекта указывали друг на друга.

> ибо я чего-то не понимаю, либо в чём проблема-то может быть?

Такая связь может быть циклична (см. выше). Интересует сама теоретическая возможность. О хаскале знаю очень мало.

> А можно сделать так, чтобы объект а указывал на объект b, который в свою очередь указывал на объект а? То есть, два объекта указывали друг на друга.

Проблема в том, что в момент создания объекта а нам нужен уже готовый объект b, и наоборот. Либо мутабельность...