LINUX.ORG.RU

Ответ на: комментарий от Macil

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

Да ладно?

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

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

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

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

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

Ну ок.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

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

Возможно.

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

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

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

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от eao197

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

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

anonymous
()
Ответ на: комментарий от DarkEld3r

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

import std.vector;
import some.supercool.library;
Будет ли это означать возможность задать компилятору что-то вроде:
g++ -o test -IP import_path main.cpp
и компилятор с линкером сами разберутся, с чем именно нужно линковать main.o?

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от EXL

Что видно на скриншоте — 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. Разработчик сбацал виртуальную машину, для которой и написал саму игру. Получилось шикарно.

anonymous
()
Ответ на: комментарий от annulen

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

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

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

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

***

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

***

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

Именно так.

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

EXL ★★★★★
()
Ответ на: комментарий от EXL

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

anonymous
()

Stop Teaching C

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

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от annulen

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

anonymous
()
Ответ на: комментарий от anonymous

Про тормоза 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-класс, и джаве места тут просто не найдется.

anonymous
()
Ответ на: комментарий от anonymous

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

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

EXL ★★★★★
()

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

asaw ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от Kroz

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

anonymous
()
Ответ на: комментарий от asaw

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

И сказал

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

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

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

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

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

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

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

Да можно, только осторожно. «Массив сожрал всю память виртуалки, и мы грохнулись с 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, и простаивающих ячеек не будет.

anonymous
()

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? Эталонный ССЗБ.

slackwarrior ★★★★★
()
Ответ на: комментарий от anonymous

Про двумерность. В 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)

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

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

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

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

znenyegvkby
()
Ответ на: комментарий от anonymous

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

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

cnupm
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от asaw

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от cnupm

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

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

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.