Почему C++ сосет (редакция 2016 года)

без понимания тонкостей работы которого, невозможно писать реальные программы.

Да ладно?

Не))

Ну если C<T> реализован как C : public T, то очень даже зависит.

Это не внутренности, а наружности.

https://www.youtube.com/watch?v=ND-TuW0KIgg

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

Почему? К тому же, импортировать из модуля всё сразу можно через *.

Гораздо лучше, когда эти вещи дополняют друг друга.

Возможно. С другой стороны: меньше сущностей - проще язык. Опять же, «принудительные неймспейсы» в виде модулей принуждают писать «более правильно». Хотя я согласен, что это не особо серьёзный аргумент.

😂

Это не внутренности, а наружности.

Ну ок.

Кстати, oператор преобразования и разыменования, через которые можно наблюдать D и B, тоже наружностями считаешь?

К тому же, импортировать из модуля всё сразу можно через *.

Ну хорошо тогда.

Возможно.

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

То же пространство имен std можно расширять специализацией стандартных шаблонов под свои типы.

Модули же, как правило, закрытые сущности.

Не совсем понял, про что ты.

Короче, зря я, наверное, понёсся в сторону type covariance/contravariance. Я всего лишь хотел сказать, что шаблоны это шаблоны, а не ООП.

Ох уж эти адепты жабки.

Список ААА игр на жабке/C# в студию. Ах да, они же все на С/С++.

А так да, оптимизация не нужна.

Список ААА игр

Школьник в треде, все в продлёнку!

Мне кажется, что в разговорах про C++ные namespaces забывают о том, что пространства имен в C++ открыты.

Да, это упустил из внимания. Пожалуй, может быть полезно/удобно, даже если не принимать во внимание «необходимость» специализировать шаблоны в чужом пространстве имён (это может через другие языковые механизмы делать).

Уже там :)

Короче, зря я, наверное, понёсся в сторону type covariance/contravariance.

Да нет, я тебя понял, просто не (совсем) согласен, что наследование от шаблонного параметра - это «наружности», вот и придираюсь. С тем, что «по умолчанию» шаблоны никак не связаны друг с другом согласен.

В общем и целом согласен. Пофиг, сколько страниц в стандарте, другие языки если и лучше, то не на порядок. Да это и неважно, можно успешно кодить, даже если докУмент в глаза не видел, и можно вызубрить талмуд, но не мочь ни строчки напрограммировать.

По поводу потенциального добавления модулей в C++ меня волнует совсем другие вещи. Вот, например, сделают возможность указать в main.cpp:

import std.vector;
import some.supercool.library;

g++ -o test -IP import_path main.cpp

Или же с именами библиотек придется трахаться точно так же, как и сейчас?

Или же с именами библиотек придется трахаться точно так же, как и сейчас?

Честно говоря, не в курсе - особо не вникал в имеющиеся «экспериментальные» реализации.

Что видно на скриншоте — Java-решение есть и работает. Уже одно это значит дофига. Недостатки, конечно, есть.

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

Жручесть CPU зависит от оптимизаций. Оптимизации зависят от числа разработчиков. А их по гитхабу 14 против 139, ровно в 10 раз разница.

Опять же, ты или я даже на крестах не запилим хоть какой-то эмулятор, а тот же Фабрис Беллард на JS-е запустил эмулятор, поддерживающий линукс. Разные люди — разные результаты.

Кстати, какая у тебя видяха? В readme пишут, что с AMD бывают проблемы. У тебя NVIDIA, и точно включено аппаратное ускорение?

***

Unity 10 лет, Unreal Engine вообще растет из 90-х. Разумеется, их начали писать на CPP, не бросать же его, когда есть хорошее решение, есть команда и есть продажи.

Если игра работает на WebGL (а Юнити так умеет), то все приложение работает на JS, без нативных модулей. Целиком и полностью, ядро не на C++, а на Asm.js. К тому же, подозреваю, что чисто по объему кода C# в Юнити не меньше, чем на CPP.

А вот libGDX, начатый одним человеком где-то в 2012, написан в основном на Java. На плюсах в основном биндинги, а работа с текстурами, шейдерами и геометрией, графом сцены, кнопками-переключателями — на Java. Все работает очень неплохо.

***

Кстати, о скриптопараше. В 1991 вышла игра Another World. Разработчик сбацал виртуальную машину, для которой и написал саму игру. Получилось шикарно.

Спасибо, интересно.

В такие затыки по CPU не упирался. На практике все случаи, когда ява лагала, были при создании кучи (реально дофига!) объектов. Как правило, в циклах.

Вторая главная претензия (но это уже теория пошла) — простых структур в Java нет, только объекты. Если это 2d-вектор, то кроме двух float-ов на 4*2 байта данных будет столько же (или больше) метаданных, плюс выравнивание. В итоге кэш процессора используется вдвое хуже, в итоге а-та-та.

Но как такое надежно протестировать — не представляю, так что это просто убедительно звучащая теория.

Твои претензии смотрятся менее значимыми, JIT-ы нынче крутые пошли, а многопоточность в Java — один из коньков.

***

Вот что реально может раздражать в GUI-софте, так это первая компиляция. В Swing-е, если показывать диалог по кнопке, то в первый раз есть ощутимая задержка. Меньше секунды, но заметно и неприятно. Дальше все происходит мгновенно. Не знаю, в чем дело — то ли в подгрузке класса, то ли в JIT-е, но бяка таки есть.

***

Числодробилки числодробилкам рознь. По-моему, самое актуальное — нейросетки на GPU, например, как в библиотеке caffe. Там все на плюсах.

Про Java для числодробилок не слышал, она для кластеров используется. Hadoop там, или Spark. Но тут роялит именно многопоточность из коробки и сетевые возможности оттуда же.

тебе, наверное, кроме лора свое компетентное мнение и высказать-то негде? :)

Минекрафте. Пришел один человек, осчасливил фигову тучу народа, и стал миллиардером (!). Кто из AAA-разработчиков так смог? Да никто.

В 90-е Кармак поднял денег на Феррари на аркадном попрыг-платформере. Гейб-наш-халфлайфер надыбал денег, работая на MS, и уже потом с громадной кучей народа пилил λ/2.

в 00-х историй успеха нет, один Нотч за всех отдувается в 10-е.

Именно так.

Дяденька, а что это вы на нашу продлёнку пришли? Сегодня же выходной!

У тебя NVIDIA, и точно включено аппаратное ускорение?

Да/да. Оно всё равно неиграбельно.

Кстати, о скриптопараше. В 1991 вышла игра Another World. Разработчик сбацал виртуальную машину, для которой и написал саму игру. Получилось шикарно.

Он и графику векторную сбацал просто отличную.

В итоге кэш процессора используется вдвое хуже, в итоге а-та-та.

Это еще полбеды. Такой подход препятствует отпимизации агрегатов, вроде http://llvm.org/docs/doxygen/html/SROA_8cpp.html#details

Печально, что не робит. Может, допилят когда-нибудь.

Stop Teaching C

дальше не смотрел

Каша в голове - это обычное состояние жабиста. Один майнкрафт(про тормоза которого только ленивый не писал) на жабке против тысяч на плюсах.

А по поводу состояния:

http://www.forbes.com/profile/gabe-newell/

http://www.forbes.com/profile/markus-persson/

Про Кармака вообще ересь, тогда рынок был совсем другой.

Один майнкрафт(про тормоза которого только ленивый не писал)

хм? У меня не тормозит даже на галакси S3 древнем.

А вот minetest плюсовый тормозит просто адово даже на десктопе, который в разы сильнее.

Да, похоже, куча оптимизаций идет лесом. Но вот конкретно по словам «scalar replacement of aggregates» выдаются доки, что Hotspot что-то там умеет. В очень редких случаях, безо всякой гарантии, но умеет раскидывать небольшие объекты в стек/регистры. Общего положения не спасает, но приятно.

Про тормоза Minecraft только слышал. Но тормоза на PC всю жизнь были нормой. Точно помню, как местами лагал Half-Life, и как не запустился Quake III. Hardware T&L ему подавай, понимаешь!..

***

Гейб вкалывал в Микрософте (13, блин, лет!), разработал халфу, вторую халфу, наколбасил стим (Apple поднялась на iTunes, здесь то же самое, только для игр), создал вторую халфу, приютил CS, Team Fortress и Portal.

И его состояние всего вдвое больше, чем у Нотча, создавшего Minecraft, два ярда против одного.

***

Про Кармака встречалась такая информация. Может, врут, а может, и нет.

Так что просто факты. Первые игры, принесшие id software значимые деньги, были платформеры. Commander Keen, Dangerous Dave.

Вольфенштейн и Дум вышли в 92-94 годах, в это время у Кармака то ли появилась, то ли уже была машина. Он ее ара-тюнил в свое удовольствие и в начале 97-го года отдал победителю какого-то турнира по кваке.

Феррари стоила где-то 60к зеленых, ну пусть сотня. Доход за 94-й у всей компании был ~8 млн. В ID, насколько понимаю, работало меньше 10 человек. Ромеро, Холл и какой-то чувак-мормон были дизайнерами, Адриан Кармак художничал, Джон Кармак программировал.

Итог. Деньги на машину появились то ли после Doom, то ли после платформеров.

В любом случае, по нынешним меркам ни одна из этих игр не AAA (маловато народу и мало бюджета).

Классные, новаторские, технологические продвинутые, но не AAA.

***

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

У меня не тормозит даже на галакси S3 древнем.

Лол. Minecraft под андроид на крестах написан. См. Libs в apk.

Как можно говорить о том, что C++ «сосёт», когда в Java и .NET размер массива ограничен 2 (двумя) гигабайтами хоть ты тресни (для .NET - четырьмя, если с бубном)? Идите в сад с такими заявлениями.

хм? У меня не тормозит даже на галакси S3 древнем.
А вот minetest плюсовый тормозит просто адово даже на десктопе, который в разы сильнее.

Скорость и переносимость, то что Java не смогла дать:

http://minecraftpocketedition.wikia.com/wiki/Minecraft_Pocket_Edition

Между прочим этих проблем нет во Freepascal-)

Откуда дровишки? Размер массива ограничен Integer.MAX_INT (чуть меньше, на десяток). Для byte-ов это будет 2 ГБ, а для double-ов в 8 раз больше, 16 ГБ.

Если нужно больше (ни разу о таком не слышал), то можно заинкапсулировать в два массива максимальной длины. Стандартные sort/search/copy, разумеется, придется заменить велосипедами, но это не проблема.

Integer.MAX_INT (чуть меньше, на десяток)

Побуду буквоедом немного, праздник все-таки :) В большинстве реализаций VM это MAX_INT - 5, то есть MAX_INT - 4 уже бросит вам java.lang.OutOfMemoryError.

Для byte-ов это будет 2 ГБ, а для double-ов в 8 раз больше, 16 ГБ.

Всегда думал что размер массива, это допустимое количество элементов.

Если нужно больше (ни разу о таком не слышал), то можно заинкапсулировать в два массива максимальной длины. Стандартные sort/search/copy, разумеется, придется заменить велосипедами, но это не проблема.

Вы, наверное, хотели сказать «используй 2D-массивы», но очепятались :)

Джентльмен выше по треду указал 2 ГБ, а не 2 млрд. элементов, вот к этому я докопался.

Можно и 2d-массив, можно и два простых, по факту в яве это одно и то же.

Джентльмен выше по треду указал 2 ГБ

Это понятно, я процитировал ваши слова в этом же контексте

Для byte-ов это будет 2 ГБ, а для double-ов в 8 раз больше, 16 ГБ.

И сказал

Всегда думал что размер массива, это допустимое количество элементов.

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

массива ограничен 2 (двумя) гигабайтами хоть ты тресни

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

Можно и 2d-массив, можно и два простых, по факту в яве это одно и то же.

И здесь тоже не совсем понял. Можете объяснить? Два простых массива - это some[] и some[], то есть MAX_INT + MAX_INT. А двумерный массив, это some[N][M], то есть стандартная матрица N*M, что между ними может быть общего? Или я что-то не понял?

Да можно, только осторожно. «Массив сожрал всю память виртуалки, и мы грохнулись с OOME». Размер массива (в байтах) слишком большой для этого случая, надо памяти добавить. Или перейти с double-ов на float-ы.

Про двумерность. В Java нет квадратных матриц. «float[2][2] matrix» записывает три массива: два одномерных по два float-а, и саму matrix с двумя ссылками на эти массива.

matrix[0] вернет одномерный массив, matrix[0][0] отдаст его первый элемент.

Так что «float[2][2] matrix;» будет абсолютно тем же самым, что и «float[2] row0; float[2] row1;». C-шная экономность, когда matrix[j] = matrix[size*i + j], тут не работает. Зато квадратность необязательна: можно одну строку сделать на 100 элементов, вторую на 10, и простаивающих ячеек не будет.

не подразумевающий, что int размером 32 бита

int размером 32 бита почти на всех платформах

It’s a barely portable language
«You’re stupid, that doesn’t work under the C++14 compiler under Windows except for Microsoft’s» (с)

Омг, астрологи объявили неделю проекций баттхерта на инструменты... «Ступид» писал «кроссплатформенный» код на основе предположений(?) про поддержку "кровоточащихсравнительно новых фич" С++14? Эталонный ССЗБ.

Про двумерность. В Java нет квадратных матриц. «float[2][2] matrix» записывает три массива: два одномерных по два float-а, и саму matrix с двумя ссылками на эти массива.

Извиняюсь, вы видимо меня не так поняли. Я говорю об абстракции. Как это внутри реализовано, мне совершенно не интересно. Мне, допустим, намного удобнее будет работать с двумерным массивом если представлять его в виде some[блок][элемент], и если нужен i-элемент, получать индекс блока (IB) как i/BLOCK_MAX_SIZE, а индекс элемента как i - (IB*BLOCK_MAX_SIZE). То есть при работе с двумерным массивом, я не нуждаюсь в связях, я воспринимаю массив как одно целое. Если же я работаю с some_rel_ar[root] -> some_rel_ar[level], то уже не воспринимаю данные как одно целое. (Здесь представим ситуацию, что нужно загрузить файл размером manyManyGb в byte-массив, допустим :D)

Сразу уточню, чтобы не было вопросов

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

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

UnrealEngine — ну он везде на C++,

UnrealScript. Это блюпринты, только его вот так спрятали, чтоб с лицензиатами проблем не было. Так что фактически там на крестах только ядро, посмотри как там тот же RPC сделан.

Как можно быть таким контуженым?

Кажется ТС сам посасывает, но пытается себя обманут за счет окружающей среды.

когда в Java и .NET размер массива ограничен 2 (двумя) гигабайтами хоть ты тресни

И часто ты массивы в 2гб+ в C++ создаёшь?

UnrealScript. Это блюпринты

Слышал про блюпринты, что на них только элементарные вещи делать можно. Сам далёк от геймдева, так что поверю на слово, если скажешь, что это не так.

Вопрос из серии «кому может понадобиться больше 640K RAM?».