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

> Но, ты, браток, завираешься.

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

Замучали АО, ей-богу.

>Ага, никчемные полутородневные язычки!

они самые. куда ж нам до тебя, такого умного :)

>количество этой гадости (язычков-однодневок) год от года растет экспоненциально

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

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

для случая более одного аргумента - верно. при чём тут хаскель, впрочем, всё равно непонятно

> А теперь подробно, с полными выкладками, чтобы не было возможности впоследствии срулить куда-нибудь вдаль объясняем, где я _заврался_. Вот прямо на основе того сообщения по пунктам.

Ты страдаешь критиканством. Ибо C++ есть место в числодробилках -- по крайней мере лично я нашел использование его удобным, и производительность от фортрана практически не отличается, а писать -- удобнее.

> "чуть более хороший C" для задачи реализации драйверов

Хм. да он же чисто декларативный.

>В любом случае, я не понял твоей метафоры

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

>в C++ присутствуют шаблоны, действует RAII

присутствуют. действует. не спорю

>Хм. да он же чисто декларативный.

чем и приятен; в рамках задачи - просто-таки прелесть. рекомендую поискать статью "evaluation of the devil approach", там обзор применимости

> Ты страдаешь критиканством.

Итак, для очередного не умеющего читать АО я повторяю вопрос:

>> А теперь подробно, с полными выкладками, чтобы не было возможности впоследствии срулить куда-нибудь вдаль объясняем, где я _заврался_. Вот прямо на основе того сообщения по пунктам.

Сколько ждать ответа?

> Ибо C++ есть место в числодробилках

Есть, ни вопрос. Я что, с этим спорю, что С++ есть место? Более того, С++ есть место и в более других областях. Просто место это определяется зачастую не подходящестью(trademark 8)) ) языка под задачу, а грудой более других факторов, один из которых -- незнание программистом других средств, например.

Когда ж вы перестанете спорить с выдуманными голосами в своей голове, присваивая их реплики окружающим?

>> Хм. да он же чисто декларативный.

> чем и приятен; в рамках задачи - просто-таки прелесть

тебе виднее; но на звание "лучшего Си" он претендовать таки не может.

> рекомендую поискать статью "evaluation of the devil approach"

Читал. По-моему, ты же и ссылку дал :)

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

Если тебя не понимают многие, задумайся о голосе из своей головы.

>но на звание "лучшего Си" он претендовать таки не может.

я ж в контексте драйверов исключительно - он не Тьюринг-полный, вообще говоря

>По-моему, ты же и ссылку дал :)

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

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

Извини, я тебя понял (и, видимо не только я). Общее ощущение от твоих сообщений состоит в том, что ты утверждаешь, что C++ нет места в расчетах. С моей точки зрения -- есть и не потому, что программисты не знают других средств, а потому, что среди "эффективных для вычислений" языков -- C, Fortran и C++ последний обладает наибольшей выразительностью, позволяя делать многое из того, чем обладают только "высокие" языки, типа Scheme -- создавать, опереровать и передавать функциональные объекты, например. Да, на C тоже можно извернуться с указателями и структурами типа void* (как это сделано в GSL, например), но на C++ получается красивее, понятнее и естественнее.

Я не горожу гомоморфные иерархие классов, но возможность определять сложные пользовательские типы данных очень удобна. Более того, C++ хорош тем, что можно писать фактически на C, задействуя возможности C++ по мере надобности. Никто же с пистолетом у виска не требует непременно делать все через классы, чай не java.

> Извини, я тебя понял

Извини, я тебя НЕ понял

Мда, время идёт, а плюсофилы не меняются. Всё то же дремучее невежество и агрессивное неприятие всего иного на фоне зашкаливающего ЧСВ. Хотя персонаж linuxfan выглядит уж слишком собирательным. Ну просто все мыслимые повадки плюсатых фанбоев в себе воплотил. Даже мысли об утонченном троллинге напрашиваются.

> Общее ощущение от твоих сообщений состоит в том, что ты утверждаешь, что C++ нет места в расчетах.

Просто не надо выдумывать -- и всё будет просто, понятно и прозрачно.

Я утверждаю, что утверждение "числодробилки -- ниша C++" требует подтверждения. Собственно, если я ничего не упустил, подтверждение может быть по следующим направлениям:

1) исторически. Тут, очевидно, полная птичка-обломинго, исторически числодробилки, как я понимаю, ниша фортрана.

2) фичи языка, на что упирал Reset. По фичам тоже облом получился.

3) подавляющее большинство числодробилок написано на плюсах

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

В любом случае, даже если числодробилки не являются нишей С++, место последнему в этой нише есть. Более того, даже если завтра выпустят язык Guzcill, который будет рвать плюсовку и по скорости, и по выразительности -- небольшой уголочек в нише у последнего всё равно останется по разным причинам.

И всё-таки я жду ответа на вопрос или признания, что заврался кто-то другой.

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

> Утверждение было "одна из ниш С++ - числодробилки".

А оно не изоморфно "числодробилки -- (одна из) ниша C++"? Ну надо же, какие чудеса творятся в альтернативной реальности...

Это разные утверждения.

А-а-а, вот оно как... На этом разговор считаю законченным. Я как-то привык общаться на русском языке, а не альтернативно-русском. Объяснять значение каждого слова -- это как-то через чур.

>>Можно сделать что угодно. Но, например, если сделать через epoll (EPollSelector в java.nio) то суть не изменится - экзепшен долетит до селектора где можно убить коннекшен.

>Опять ты начал бредить. Причем тут java.nio? Напомню, речь о многопроцессном сервер в стиле раннего Апача.

При том что с бестредовым сервером в жабе такая же вероятность осыпания всего как и с форкующимся сервером на Си.

>> В жабе же можно сломать только свой локальный объект

>В Яве тоже бывают глобальные данные.

Типичная аргументация от TG в стиле "противопожарные рвы не имеет смысла рыть поскольку они не отменяют проблему пожаров вообще" вкупе с "если все будут идеально и дисциплинированно соблюдать противопожарную безопасность то проблема пожаров решится сама собой". Проблема с глобальными данными решается чисто механически: клонирование данных на границе модуля.

> При том что с бестредовым сервером в жабе такая же вероятность осыпания всего как и с форкующимся сервером на Си.

То есть жабский сервер таки может осыпаться? Ну слава ТНБ, мы пришли к консенсусу. Теперь можешь обосновать принципиально более высокую надежность многонитевого (в пределах JVM) жабского сервера по сравнению с форкающимся Си-сервером?

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

Типичное Absurd'ное понимание аксиом "за всё надо платить" и "серебряной пули не бывает".

> Ну надо же. Кто в геймдеве пользуется stl?

пользуется очень много кто. в геймдеве идиотов не меньше чем везде.

> пользуется очень много кто. в геймдеве идиотов не меньше чем везде.

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

По крайней мере, у меня по редкому почитательству геймдевщиков в блогах и на форумах сложилось устойчивое впечателение, что от плюсовки там остаются ТАКИЕ огрызки... Какой stl, какое RAII, о чём Вы... 8))

> Ну я имел в виду достаточно хардкорный геймдев, очевидно.

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

>Теперь можешь обосновать принципиально более высокую надежность многонитевого (в пределах JVM) жабского сервера по сравнению с форкающимся Си-сервером?

Модель памяти отличается от unsigned char memory[2^31].

>Типичное Absurd'ное понимание аксиом "за всё надо платить"

Банальность плоская как утиный нос. Можно хороший товар купить задешево. А можно и говно купить по цене золота. Вопрос видимо в адекватности цены.

>"серебряной пули не бывает"

То же самое - можно на медведя охотиться с луком. А можно и с "Сайгой". Вопрос видимо в том "а нафига стрелять в медведя из лука когда есть Сайга".

> В детстве я был здоровым развитым ребенком и сам мог накостылять чахлым функциональщикам.

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

> Вообще-то STL -- это не беда. Беда -- это boost.

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

> Не работает кнопочка "Сохранить", какая фигня.

Придётся coredump сохранять... :(

>> Теперь можешь обосновать принципиально более высокую надежность многонитевого (в пределах JVM) жабского сервера по сравнению с форкающимся Си-сервером?

> Модель памяти отличается от unsigned char memory[2^31].

Не катит на принципиальность. По капотом Явы - тот же Си++ :)

>>Типичное Absurd'ное понимание аксиом "за всё надо платить"

>Банальность плоская как утиный нос

Ага. Но это ты заставил меня сказать это %)

> Можно хороший товар купить задешево. А можно и говно купить по цене золота.

Банальность, плоская как утиный нос^W^W^W^W^WЧто значит сия метафора?

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

О! А чем так плох STL? И что используют вместо него? Ведь коллекции/контейнеры почти в любой программе нужны.

> Ведь коллекции/контейнеры почти в любой программе нужны.

не нужны

> не нужны

и что же вы пишите?

> и что же вы пишите?

это нетрудно выяснить из моего гугл-профиля :)

если такого плана:

https://sourceforge.net/dbimage.php?id=228167

то не впечатляет

> А чем так плох STL?

Тормоз он...

> И что используют вместо него?

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

> Ведь коллекции/контейнеры почти в любой программе нужны.

struct something somevar[MAX_VARS] -- коллекция/контейнер? Если да -- то нужны, но на stl свет клином не сошёлся. Если нет -- тогда Вы неправду сказали. 8))

> struct something somevar[MAX_VARS] -- коллекция/контейнер?

ну а например замена stl::map?

П.С. во многих случаях за [MAX_VARS] надо обрывать руки

>Ведь коллекции/контейнеры почти в любой программе нужны.

Да вот хз - Саттер пишет что на практике связанный список обгоняет массив на рандомных вставках начиная где-то с ~1000 элементов. Кроме того, рандомные вставки в играх не особо-то не нужны: весь уровень обычно представляет собой статическую структуру которую надо отрендерить. Ну, для обработки событий геймплея возможно нужны LIFO и FIFO структуры которых можно построить на базе массивов фиксированного размера.

> то не впечатляет

это хобби. про работу видимо плохо искал :)

> П.С. во многих случаях за [MAX_VARS] надо обрывать руки

за std::map надо отрывать яйца

> это хобби. про работу видимо плохо искал :)

прям щас все брошу и начну искать :)

> за std::map надо отрывать яйца

у тебя их нет - тебе не страшно

> за std::map надо отрывать яйца

И что в нем такого ужасного?

> П.С. во многих случаях за [MAX_VARS] надо обрывать руки

Ты в курсе, что в современной операционной системе до первого обращения к неинициализированной странице память выделена не будет? Поэтому [MAX_VARS] не так страшно на самом деле, как кажется.

ну вот, школьники обиделись :)))

> это хобби. про работу видимо плохо искал :)

Ну найдёт название конторы, где ты работаешь, и что с того? ;)

> ну а например замена stl::map?

А ты уверен, что оно там надо? 8))

В любом случае, в зависимости от задачи даже на чистом С адекватно заменяется, хотя требует "немного подумать". Собственно, ещё одна беда любителей^2 stl -- как раз нежелание "немного подумать". Нужен ассоциатившый массив -- фигле, вот у нас std::map есть, чего думать, трясти надо...

> П.С. во многих случаях за [MAX_VARS] надо обрывать руки

А во многих других случаях руки надо обрывать, скажем, за динамическое выделение памяти. И? Случаи -- они такие, да. Они разные бывают. 8))

>> за std::map надо отрывать яйца

>у тебя их нет - тебе не страшно

Алгоритм балансировки в std::map конечно очень красивый, но сама идея практически малополезна, т.к всегда будет сливать бинарному поиску по отсортированному массиву или простой lookup-таблице на базе хеша фиксированного размера. Вот B*-деревья которые используются для построения индексов в БД они да, полезны. Но наверное для БД а не для игр.

> Ты в курсе, что в современной операционной системе до первого обращения к неинициализированной странице память выделена не будет?

Зависит от настроек overcommit :) Да и вообще дело мутное.

> Ну найдёт название конторы, где ты работаешь, и что с того? ;)

это, очевидно, даст ему ответ на его вопрос "и что же вы пишите?"

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

не люблю "магические числа" вроде MAX_VARS, иногда их использование оправдано, но если уж имеешь под рукой что-то вроде vector, то лучше использовать его, чем гадать с размерами( и не факт, что потом программа не "захочет" немного больше ) и добавлять в код счетчик