Понимаете, гонка моделей — это как гонка процессоров в 90-е. Все следили: Intel или AMD, сколько мегагерц. А потом оказалось, что важнее — какой софт вы на этом запускаете, какую экосистему вокруг построили.
Я не знаю, что это за "эксперт", но он выдал кучу совершенно кривых аналогий и о том, что происходило с процессорами в 90-х и почему поменялось отношение к ним сейчас, похоже, он тоже не сильно понимает.
В моем городе этой выставки точно не было, но буклет я однажды нашел на мусорке, подобрал и часами потом рассматривал. Картинку графического редактора на маке с неандертальцем помню до сих пор.
Абраш и Кармак нашли себе приключения, когда нарвались на этот баг во время разработки Quake. Были подозрения, что это какой-то глюк разрабатываемого движка и его очень долго и упорно дебажили.
тогда у тебя вариативность в compile time значит в console.h описываешь интерфейс класса дальше идут реализации console_x86.cpp, console_ARM.cpp и так далее полиморфизм тут вообще не нужен
если собираетесь использовать std, то брали бы сразу unique_ptr (с кастомным делитером)
начинать лучше с вводной статьи, где расскажите что вы вообще собираетесь делать, какая архитектура и по каким конкретным шагам вы собираетесь ее реализовывать
На американском рынке компанией руководили грамотные люди, они понимали, сколь бесценны игры по голливудским франшизам, спортивные игры с лицензией и так далее. Игры, которые Nintendo не сделает своими силами в Японии. И ситуация была win-win. Больше разных игр -- больше привлекательность консоли для игроков. А еще сверху N зарабатывает деньги буквально на каждом выпущенном картридже.
Поэтому оценка "году так к 1990-ому или даже позже" несколько пессимистична. Плюс лето 89-го это уже появление Sega Genesis на рынке Штатов, тут уже все понимали, что эксклюзивы это хорошо, но без 3rd party далеко не уедешь.
Ок, и все равно мне кажется, что более корректная формулировка звучит так: "На ранних этапах жизненного пути Famicon, до появления схемы лицензирования, Nintendo не жаловала сторонних разработчиков на своей платформе"
Я не знаю, что это за "эксперт", но он выдал кучу совершенно кривых аналогий и о том, что происходило с процессорами в 90-х и почему поменялось отношение к ним сейчас, похоже, он тоже не сильно понимает.
В моем городе этой выставки точно не было, но буклет я однажды нашел на мусорке, подобрал и часами потом рассматривал. Картинку графического редактора на маке с неандертальцем помню до сих пор.
про ОГРОМНУЮ разницу каждой новой модели я слышу с конца 22-го года.
а прогресс в области фундаментальных проблем LLM двигается черепашьими шагами. при сожжённых сотнях миллиардов долларов.
собственно Rust в штатном режиме и есть такой инструмент
в следующем году пузырь лопнет и все эти продавцы воздуха будут жить в параллельном мире -- под забором
а может вы просто не умеете программировать и ИИ за вас делает то, что нормальные люди пишут на автомате, даже не задумываясь?
равно обратный опыт. лучше найти оригинальный топик на stackoverflow и подогнать его под себя, чем выгребать случайные приколы в сгенерированном коде.
писать код почти всегда легче, чем разбираться с чужим
или у вас такие синьоры или у вас какие-то модели из 2045 года
а чего только 2x? может 5x? на порядок?
только когда дело доходит до реальных исследований на реальных задачах, оказывается, что производительность не растет, а падает
ну, если сайт на три кнопки это 90% рынка и если эту работу можно считать сильно интеллектуальной...
Абраш и Кармак нашли себе приключения, когда нарвались на этот баг во время разработки Quake. Были подозрения, что это какой-то глюк разрабатываемого движка и его очень долго и упорно дебажили.
ничего более смешного в жизни не читал
ChatGPT в такого рода запросах косячит с вероятностью больше 50%
тогда у тебя вариативность в compile time
значит в console.h описываешь интерфейс класса
дальше идут реализации console_x86.cpp, console_ARM.cpp и так далее
полиморфизм тут вообще не нужен
та вариантов может быть миллион, вопрос, какая задача решается
а нужно ли вообще тут абстрагирование от типа?
можно задать тип консоли через шаблон
если собираетесь использовать std, то брали бы сразу unique_ptr (с кастомным делитером)
начинать лучше с вводной статьи, где расскажите что вы вообще собираетесь делать, какая архитектура и по каким конкретным шагам вы собираетесь ее реализовывать
перемудрили на ровном месте
зачем, если с таким кодом смена типа, который реализует IConsole, все равно требует переписывание нескольких мест в том же классе?
общая идея runtime полиморфизма в том, чтобы не перекомпилируя существующий код, заставить его работать с любым набором совместимых типов
На американском рынке компанией руководили грамотные люди, они понимали, сколь бесценны игры по голливудским франшизам, спортивные игры с лицензией и так далее. Игры, которые Nintendo не сделает своими силами в Японии.
И ситуация была win-win. Больше разных игр -- больше привлекательность консоли для игроков. А еще сверху N зарабатывает деньги буквально на каждом выпущенном картридже.
Вот пример спортивный игры с дорогой лицензией, выпущенной сторонней компанией (EA). Релиз в США -- лето 89-го года.
https://en.wikipedia.org/wiki/Jordan_vs._Bird%3A_One_on_One
Поэтому оценка "году так к 1990-ому или даже позже" несколько пессимистична.
Плюс лето 89-го это уже появление Sega Genesis на рынке Штатов, тут уже все понимали, что эксклюзивы это хорошо, но без 3rd party далеко не уедешь.
Ок, и все равно мне кажется, что более корректная формулировка звучит так: "На ранних этапах жизненного пути Famicon, до появления схемы лицензирования, Nintendo не жаловала сторонних разработчиков на своей платформе"
может не будем путать "стиль" и кучу грубейших фактических ошибок? так сказать наконец-то назовем писю "пенисом" и начнем лечить сифилис (с)
потому что это статья уровня "стремительным домкратом"
на техническом ресурсы пипл с удовольствием хавает дилетанские статьи и даже создает культ вокруг их авторов