Это вы куда-то не туда смотрели. Всё, на что может упасть глаз в кедах, например, настраиваемо под любой вкус. Если он есть, конечно ;) А вот в маке хрен что настроишь, даже картинку в фон консоли не воткнёшь. Тёмная тема только недавно появилась.
По производительности в нейросетях этот джетсон нано примерно как разогнанный kendrite K210 за $8 (460 gmulps). И распознование лиц там тоже работает. И с wifi вариант есть. www.youtube.com/watch?v=TaoEwmwEAE8
Системе Android уже десять лет, текущий UI морально устарел. Старый UI достаточно сложно поддерживать. Например, класс View имеет 29 188 строк кода, включая комментарии, AppCompat-версия обросла множеством хаков для разных версий Android. Посмотрев на эту картину, разработчики Google решили сделать UI-фреймворк, который будет поставляться вместе с приложением и станет полностью отвязанным от Android. Рабочее название фреймворка — Jetpack Compose.
30 тыщ строк для пустой View, которая сама по себе ещё полуфабрикат и нуждается в расширении. А кто-то здесь всё ещё верует, что ООП облегчает разработку UI.
Да шо вы меня учите — я вас не просил. Я для себя джаву давно выбросил на помойку, как и всё ООП, зачем я буду страдать всей это фигнёй.
Да у нас будут большие проблемы при работе с индексами… но как часто вы их используете-то?
У меня не будет — вы же это предложили, а не я. По сравнению с процедурным вариантом что то, что это посасывает. В случае с джавой сначал нужно получить из списка исходный объект, потом создать новый, потом скопировать его поля (memcpy в джаву не завезли, лол, придётся ручками каждое поле, которое должно остаться неизменным, переписывать), и только потом вставить. Нет уж, сами занимайтесь этим мазохизмом. Когда на древнем С это просто как
Можно, но всё равно оверхэд и лишняя писанина останутся. И нужна ссылка на список, ссылки на саму структуру недостаточно.
А если кроме Paint() есть ещё AI(), который отвечает за поведение? Есть вражеский солдат, есть свой, а ещё он может быть повержен в бегство, оглушён, отравлен или ранен(будет искать место, где отсидеться можно), получается для каждой комбинации внешнего вида и поведения свой класс? Или же приходим к тому же switch, от которого хотели уйти.
Принципиально — указатель на функцию я могу на лету заменить, превратив один игровой объект в другой с минимальными усилиями. Был Solider — добежал до ВПП — стал Copter. Или не добежал, стал deadSolider или zombieSolider. А ООП класс придётся уничтожать и создавать на этом месте новый. Если они лежат, например, в ArrayList — сначала уничтожаем, сдвигается N элементов списка, потом вставляем, опять N сдвигов, тратим время своё и CPU, и создаём мусор для GC.
По удобству — писанины меньше и всё на виду. Если мне нужно скажем PowerBonus отрисовать, не нужно открывать и править все 10 классов, если они в отдельных файлах, как в джаве.
Насчёт GUI тоже сомнительно, что ООП полезно. Давно уже никто почти гуй руками в коде не верстает, всё в xml или других подобных файлах разметки. А потом ищут элементы медленными костылями навроде TextView number = findViewById(R.id.something), потом библиотеками обмазывают, чтобы скрыть это всё подальше от глаз. Хотя можно было бы использовать те же структуры, которые без лишних прослоек напрямую линкуются с кодом.
Можно динамически поменять paintSolider() на paintAngrySolider(), можно несколько разных paint<...>() передать сразу в 1 объект.
Другое дело, что все эти вариации paint<...>() скорее всего будут очень похожи, и писать для каждого класса свой — лишняя работа, и вообще данные должны решать, как выглядит объект на экране, а не код.
Я знаю, как работает стек. Думал поисследовать тему автоматического управления без оверхэда, запилить для начала статический анализатор, который бы выдавал предупреждения о неосвобождении памяти для ограниченного числа случаев, потом потихоньку допиливать до покрытия 100% возможных случаев. Удивительно, что никому кроме меня тут это не нужно. Ну да ладно.
Вы так пишете, как будто стек совсем не используете. Я его привёл в пример как самый простой вариант автоматического управления памятью, естестественно, он не покрывает всех случаев, иначе и говорить не о чём было бы. Я о том, чтобы компилятор сам выполнял за программистом работу по освобождению памяти, а не только смещал указатель на стек после выхода из локальной области видимости. Пока что такое реализовано только с помощью умных указателей или GC, насколько я знаю, а это оверхед.
Так оно оверхэд вносит, про который и речь.
Хотя если выделять объекты на стеке, то в С/С++ они удаляются автоматически, без вызова free() / delete() или GC. Но указатель на них нельзя передать за пределы области видимости, в которой они были созданы. Вот если бы компилятор чуть умнее был, и сохранял бы объект при передаче указателя, и сам бы удалял объект, после того, как указатель больше нигде не используется, не нужен был бы GC.
Есть ещё 3D моделирование через написание кода — по мне, так проще и быстрее всего для простых моделей. В OpenScad например. На завод с такими навыками не возьмут, но по-быстрому что-то для 3д принтера набросать — самое то.
В медицине же воксельные модели распространены, томограф сразу готовую модель выдаёт, затем врач может смотреть срезы в любом месте, что невозможно в любом другом случае.
А если кроме Paint() есть ещё AI(), который отвечает за поведение? Есть вражеский солдат, есть свой, а ещё он может быть повержен в бегство, оглушён, отравлен или ранен(будет искать место, где отсидеться можно), получается для каждой комбинации внешнего вида и поведения свой класс? Или же приходим к тому же switch, от которого хотели уйти.
По удобству — писанины меньше и всё на виду. Если мне нужно скажем PowerBonus отрисовать, не нужно открывать и править все 10 классов, если они в отдельных файлах, как в джаве.
А можно так:
Можно динамически поменять paintSolider() на paintAngrySolider(), можно несколько разных paint<...>() передать сразу в 1 объект.
Другое дело, что все эти вариации paint<...>() скорее всего будут очень похожи, и писать для каждого класса свой — лишняя работа, и вообще данные должны решать, как выглядит объект на экране, а не код.
Хотя если выделять объекты на стеке, то в С/С++ они удаляются автоматически, без вызова free() / delete() или GC. Но указатель на них нельзя передать за пределы области видимости, в которой они были созданы. Вот если бы компилятор чуть умнее был, и сохранял бы объект при передаче указателя, и сам бы удалял объект, после того, как указатель больше нигде не используется, не нужен был бы GC.
В медицине же воксельные модели распространены, томограф сразу готовую модель выдаёт, затем врач может смотреть срезы в любом месте, что невозможно в любом другом случае.