C++ не годится для рогаликов?

Есть масса контейнерных либ для си: списки, деревья, сортировка, ... Они нормально принимают указатели на любые объекты, man qsort хотя бы, или http://library.gnome.org/devel/gobject/stable/gobject-Value-arrays.html

>Есть масса контейнерных либ для си: списки, деревья, сортировка, ...

... в которых гомогенное хранение реализуется посредством void * и отсутствует проверка типов.

>Я *знаю* что с кодом на Си с набитым глазом можно работать сколько угодно не компилируя. По себе. И я *знаю* как с этим в плюсах

а я *знаю*, что с кодом на плюсах с набитым глазом можно работать сколько угодно не компилируя. По себе. И я *знаю*, как с этим в C

аргументация у тебя, конечно, фееричная

>Сам ты гиена.

man гиена, обязательно огненная

>Карлсон, так я ведь не сказал что это за язык. Палитесь :)

Малыш, нука приведи мне примеры языков аналогичных плюсам по возможности низкоуровневой работы, производительности и стройной моделью ооп и обобщенным программированием. Только, малыш, не надо мне про D, ладно? ) Пойдем полетаем! %)

> Это слив?

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

>man гиена, обязательно огненная

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

>>Есть масса контейнерных либ для си: списки, деревья, сортировка, ...

>... в которых гомогенное хранение реализуется посредством void * и отсутствует проверка типов.

Зато раздельной компиляции не мешает.

>copy-on-write (implicit sharing) != explicit data-sharing, а я говорил именно о нем.

А, спасибо, понял. А то тут меня уже коровой какой-то обзывают. )

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

Brainfuck

>Я бы еще добавил что программы на С++ одинаково плохо читаются и компьютером и человеком

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

или ты утверждаешь что на C++ в принципе нельзя писать читаемый код, т.е. что язык C++ язык самообфусцирующийся ? :)

P.S. какое слово, однако, красиваое :)

>Малыш, нука приведи мне примеры языков аналогичных плюсам по возможности низкоуровневой работы, производительности и стройной моделью ооп и обобщенным программированием. Только, малыш, не надо мне про D, ладно? ) Пойдем полетаем! %)

Нет уж спалился так спалился. Теперь нужно, дорогой Карлсон, поставить Вам диагноз. Какие еще ЯП помимо С/С++/D Вы знаете?

>Малыш, нука приведи мне примеры языков аналогичных плюсам по возможности низкоуровневой работы, производительности и стройной моделью ооп и обобщенным программированием. Только, малыш, не надо мне про D, ладно? ) Пойдем полетаем! %)

А зачем Вам все лепить в 1 язык? Это как минимум глупо. Не лучше ли решать высокоуровневую и низкоуровневую части на соответствующих языках, а потом связать все это воедино?

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

Тоесть таки слив. Я рад, что Вы так быстро научились признавать свои ошибки и не упорствовать на ровном месте.

>Я бы еще добавил что программы на С++ одинаково плохо читаются и компьютером и человеком.

Ты как, здоров? =О

>> Есть масса контейнерных либ для си: списки, деревья, сортировка, ... Они нормально принимают указатели на любые объекты, man qsort хотя бы, или

А теперь представь какая будет разница в скорости. Сам подумай: в случае C будет куча лишних вызовов аллокатора памяти, плюс ко всему многие функции будут дёргаться через указатель (для сравнения при сортировке например). В то время как в C++ аллокатор будет вызываться один раз на кучу объектов, а простые функции инлайниться. На C это безусловно тоже можно реализовать, но это будет гораздо сложнее чем просто тупо заюзать STL.

>>Я бы еще добавил что программы на С++ одинаково плохо читаются и компьютером и человеком

>компьютером вообще кроме машинных кодов хреново что-то читается. по вполне понятным причинам.

Код на С++ читает компилятор. А он для С++ самый медленный.

>Зато раздельной компиляции не мешает.

Скажите, как проверка типов мешает раздельной компиляции?

А нужна она в _данном_ контексте? Нет. Что void*, что template<class T> и потом T* - ты что о том типе ничерта не знаешь, что об этом. Никакой проверки здесь и подавно не нужно. Ты просто работаешь с абстрактным указателем, называй его как хочешь: void* или T*. А С++ здесь еще и нагенерирует кода из шаблонов, хотя в данном случае это _совсем_ не нужно, зато проблем создаcт с сопровождением.

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

>Brainfuck

Вы тоже уловили сходство?...

> Я рад, что Вы так быстро научились признавать свои ошибки

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

>или ты утверждаешь что на C++ в принципе нельзя писать читаемый код, т.е. что язык C++ язык самообфусцирующийся ? :)

Ну код темплейтов точно "самообфусцирующийся"...

>>Зато раздельной компиляции не мешает.

>Скажите, как проверка типов мешает раздельной компиляции?

std::sort надо компилировать для каждой инстанциации в каждой единице трансляции.

> Какие еще ЯП помимо С/С++/D Вы знаете?

Дык не знаю, вот и спрашиваю. Малыш?

>Скажите, как проверка типов мешает раздельной компиляции?

Шаблоны мешают. Иди мальчик, С++ учи.

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

так. низкоуровневая работа и производительность - C, лучше C99. стройная модель ООП...CLOS ? ;) FFI у CL поди есть, в чём проблема-то ? обобщённое программирование - ну посмотри на Haskell. прежде всего на связку Haskell + C не через FFI, а с помощью кодогенерации. вот здесь, например, такой подход для GameDev'а применяют - и вполне успешно :

http://www.program-ace.com.ua/

>А нужна она в _данном_ контексте? Нет. Что void*, что template<class T> и потом T*

Нужна. push_back(T) проверять не будем? Пусть пихают что попало?

>А С++ здесь еще и нагенерирует кода из шаблонов, хотя в данном случае это _совсем_ не нужно, зато проблем создаcт с сопровождением.

Я не говорил, что шаблоны C++ -- лучший из механизмов обобщенного программирования. Я лишь сказал, что без проверки типов плохо. Проверка типов != C++ templates.

>Не лучше ли решать высокоуровневую и низкоуровневую части на соответствующих языках, а потом связать все это воедино?

Бывают "низкоуровневые" задачи довольно большого объема.

>Шаблоны мешают. Иди мальчик, С++ учи.

"Шаблоны" != "проверка типов". Дядя, идите учить мат-часть.

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

Понятно. Упорствовать отучились, а вот пытатся выкрутится прибегая к словоблудию - нет. По сути приведеной мной цитаты у Вас возражения есть? Или вы один их тех милых пионеров имени Александреску, за которыми шлейфом тянутся "клевер-компайл-тайм-трики" ака колстыли, который даже остальные члены секты(а иногда и сам пионервожатый) не осиливают прочитать?...

>Код на С++ читает компилятор. А он для С++ самый медленный

кто именно медленный ? парсер/лексер ? ну дык это вроде бы и не смертельно. или кодогенератор плохой код генерирует ? тоже вроде бы не скажешь, GCC вон по бенчмаркам хорошо так держится. во всяком случае на однопроцессорных машинах :)

>Бывают "низкоуровневые" задачи довольно большого объема.

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

>Ну код темплейтов точно "самообфусцирующийся"...

темплейтов - да. но их всегда можно вынести за вполне себе читаемый обьктно-базированный интерфейс, Blitz++ мне в свидетели :)

>Дык не знаю, вот и спрашиваю. Малыш?

Тогда на основе чего вы утверждаете о "производительности" и "стройной модели ООП"? С какой другой реализацией поддержки ООП на уровне языка Вы сравнивали?

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

> Понятно. Упорствовать отучились, а вот пытатся выкрутится прибегая к словоблудию - нет.

Я просил ссылку на мою ошибку.

> По сути приведеной мной цитаты у Вас возражения есть?

Нет. Отличная цитата.

> Или вы один их тех милых пионеров имени Александреску

И ты меня в словоблудии упрекаешь? :D

Ну так будет ссылка на мою ошибку, или на заболтаешь вопрос?

Если у Вас нет возвражения по сути цитаты зачем было кидатся избитыми фразами про пирожки и переходить на личные оскорбления?

>А теперь представь какая будет разница в скорости.

Воистину, во что превращает людей радиация...

Для нерасширяемых контейнеров в Си используются обычные, нормальные массивы. Потом его можно без труда отсортировать qsort'ом. Если мы имеем дело со связанной структурой данных, то аллокатор будет работать и в Си, и в С++. Или С++ черпает память из астрала?

>С какой другой реализацией поддержки ООП на уровне языка Вы сравнивали?

кстати да. что мы всё про C++ да про C++ ? даёшь флейм CLOS vs Snit :)

>push_back(T) проверять не будем? Пусть пихают что попало?

Хм. Ну если использовать GObject, то все нормально проверяется.

Хотя нет, вру ;)

>Поясните что Вы имеете в виду под " "низкоуровневой" задачей довольно большого объема"?

Жесткие требования к производительности и/или работа с железом, при условии, что невозможно выделить незначительные по объему критичные участки. Вообщем, все то, что вы бы писали на Си, но когда хочется, или же просто необходима, более совершенная организации проекта с помощью ООП и обобщенное программирование.

> Если у Вас нет возвражения по сути цитаты зачем было кидатся избитыми фразами про пирожки

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

> и переходить на личные оскорбления?

Ааааааафигеть... фраза про пирожки уже стала личным оскроблением? O_O

Там GValue есть, а это довольно неплохая вещь. Она динамическая, но в этом только плюс.

>Тогда на основе чего вы утверждаете о "производительности" и "стройной модели ООП"? С какой другой реализацией поддержки ООП на уровне языка Вы сравнивали?

Про стройную модель - это не ко мне. Про язык я ответил, что не знаю другого такого. Все остальное либо чисто высокоуровневое, либо не лишено своих недостатков. Так и будем вопросом на вопрос отвечать? Знаешь - давай ссылку! Родина - зовет!

>> Для нерасширяемых контейнеров в Си используются обычные, нормальные массивы.

Для обощённых, т.е. реализация которых не зависит от того что в них класть? Хотелось бы посмотреть на это чудо =).

>> Если мы имеем дело со связанной структурой данных, то аллокатор будет работать и в Си, и в С++. Или С++ черпает память из астрала?

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

На C это всё тоже _можно_ написать, я не спорю, это даже уже написано в куче разных велосипедах. Я говорю про то, что в C++/STL этим пользоваться проще.

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

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

C++ здесь не единственное решение уж точно. самое распространённое, но не единственное

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

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

Если для Вас это очевидный факт, то с какой целью Вы интересовались "А что такое "работа с кодом", если она не подразумевает компиляции?"?

>Ааааааафигеть... фраза про пирожки уже стала личным оскроблением? O_O

Не шлангуйте, я про вругое Ваше сообщение.

Снова начинаете упортсвовать? Зря, Вы же почти смогли перебороть себя и бросить...

>так. низкоуровневая работа и производительность - C, лучше C99. стройная модель ООП...CLOS ? ;)

А теперь все вместе, можешь? ;)

>прежде всего на связку

Связка не всегда возможна.

>прежде всего на связку Haskell + C не через FFI, а с помощью кодогенерации.

Тут ничего не могу сказать, хаскель не видел.

>Знаешь - давай ссылку! Родина - зовет!

Вы хотите ссылку на серебряную пулю? Кажется, Вы таки малыш а не Карлсон :)

>или вы один их тех милых пионеров имени Александреску

Александреску кстати вменяем. Судя по Loki сразу видно чего ему в плюсах недостает - мне того же в общем. Кроме того его высказываение "Память это не ресурс. Память это Память. Я давно пытался объяснить твердобобым баранам вокруг С++ community что GC - это краеугольный камень type safety, но без успеха" тоже заслуживает внимания.