Для любого более-менее серьезного модуля количество таких use-ов будет слишком большим, чтобы выписывать подобное ручками.
Почему? К тому же, импортировать из модуля всё сразу можно через *.
Гораздо лучше, когда эти вещи дополняют друг друга.
Возможно. С другой стороны: меньше сущностей - проще язык. Опять же, «принудительные неймспейсы» в виде модулей принуждают писать «более правильно». Хотя я согласен, что это не особо серьёзный аргумент.
К тому же, импортировать из модуля всё сразу можно через *.
Ну хорошо тогда.
Возможно.
Мне кажется, что в разговорах про C++ные namespaces забывают о том, что пространства имен в C++ открыты. Т.е. если есть пространство имен some_project, то это пространство имен может быть расширено. Даже без модификации модулей, которые реализуют это пространство имен.
То же пространство имен std можно расширять специализацией стандартных шаблонов под свои типы.
Мне кажется, что в разговорах про C++ные namespaces забывают о том, что пространства имен в C++ открыты.
Да, это упустил из внимания. Пожалуй, может быть полезно/удобно, даже если не принимать во внимание «необходимость» специализировать шаблоны в чужом пространстве имён (это может через другие языковые механизмы делать).
Короче, зря я, наверное, понёсся в сторону type covariance/contravariance.
Да нет, я тебя понял, просто не (совсем) согласен, что наследование от шаблонного параметра - это «наружности», вот и придираюсь. С тем, что «по умолчанию» шаблоны никак не связаны друг с другом согласен.
В общем и целом согласен. Пофиг, сколько страниц в стандарте, другие языки если и лучше, то не на порядок. Да это и неважно, можно успешно кодить, даже если докУмент в глаза не видел, и можно вызубрить талмуд, но не мочь ни строчки напрограммировать.
Что видно на скриншоте — 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-е.
Да, похоже, куча оптимизаций идет лесом. Но вот конкретно по словам «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-класс, и джаве места тут просто не найдется.
Как можно говорить о том, что C++ «сосёт», когда в Java и .NET размер массива ограничен 2 (двумя) гигабайтами хоть ты тресни (для .NET - четырьмя, если с бубном)? Идите в сад с такими заявлениями.
Откуда дровишки? Размер массива ограничен Integer.MAX_INT (чуть меньше, на десяток). Для byte-ов это будет 2 ГБ, а для double-ов в 8 раз больше, 16 ГБ.
Если нужно больше (ни разу о таком не слышал), то можно заинкапсулировать в два массива максимальной длины. Стандартные sort/search/copy, разумеется, придется заменить велосипедами, но это не проблема.
Для byte-ов это будет 2 ГБ, а для double-ов в 8 раз больше, 16 ГБ.
Всегда думал что размер массива, это допустимое количество элементов.
Если нужно больше (ни разу о таком не слышал), то можно заинкапсулировать в два массива максимальной длины. Стандартные sort/search/copy, разумеется, придется заменить велосипедами, но это не проблема.
Вы, наверное, хотели сказать «используй 2D-массивы», но очепятались :)
Это понятно, я процитировал ваши слова в этом же контексте
Для 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, и простаивающих ячеек не будет.
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 элементов посредством двумерного массива, а работаем мы с этим объектом как с обычным одномерным массивом.
UnrealScript. Это блюпринты, только его вот так спрятали, чтоб с лицензиатами проблем не было. Так что фактически там на крестах только ядро, посмотри как там тот же RPC сделан.