Comments 31
Админы, что за фигня? Почему снаружи виден не отредактированный текст, а когда входишь, он становится нормальным?
В оригинале:
В переводе:
Перевести what как какие в контексте статьи — это, конечно, верх мастерства. Я так понял после прочтения, вся статья — это какой-то кривой машинный перевод?
UPDATE. По ходу да, изначально я увидел сырую версию текста, до того, как вошел под своим аккаунтом. Был неправ
What? A program that turns human-readable scribbles into real machine code?
В переводе:
Какие? Программа, которая превращает читабельные каракули в настоящий машинный код?
Перевести what как какие в контексте статьи — это, конечно, верх мастерства. Я так понял после прочтения, вся статья — это какой-то кривой машинный перевод?
UPDATE. По ходу да, изначально я увидел сырую версию текста, до того, как вошел под своим аккаунтом. Был неправ
Похоже, это какая то бага нового редактора. Конечно, я беру сырой текст из Гугл переводчика и редактирую его. Но снаружи виден исходный текст — фигня какая то.
конечно, я беру сырой текст из Гугл переводчика и редактирую егои вам за это деньги платят?
Нет, не платят, а должны?
Мне кажется, как и автору оригинально поста, что у часть работы, которую можно переложить на плечи компьютера, следует перекладывать, просто потому, что намного проще редактировать уже готовый текст, нежели набирать свой. По моим оценкам, раза в 3-4 быстрее и почему я должен этой возможностью пренебречь?
Мне кажется, как и автору оригинально поста, что у часть работы, которую можно переложить на плечи компьютера, следует перекладывать, просто потому, что намного проще редактировать уже готовый текст, нежели набирать свой. По моим оценкам, раза в 3-4 быстрее и почему я должен этой возможностью пренебречь?
Новые технологии будут, но в другом направлении. Не упрощения а стандартизации программирования.
Программисты никуда не денутся, а c/c++ вымрет став лишь одним из вариантов синтаксиса поверх единого для всех языков ядра. Тонкой оптимизацией под конкретное железо займётся компилятор, а интрисинки вымрут окончательно.
Автор оригинала завязался на проприетарные и не переносимые решения MSVC/TBB и жалуется что код на с++ не переносим. Ну вот какое отношение с/с++ имеет к тому, что aligned_malloc не реализуем на винде? MS должны были сделать винду posix совместимой еще в 80-е. В общем, ссзб.
AI даже может по завершению работы написать мне напыщенную речь.rant здесь по смыслу ближе к «нытью» чем к «напыщенной речи» или «тираде»
Ну я не настолько продвинут в языке оригинала, чтобы менять термины, предложенные программой, написанной носителями языка, хотя, в данном конкретном случае, Вы скорее всего правы, мне почему то «нытье» не пришло в голову.
что aligned_malloc не реализуем на винде?А это по-вашему что?
это _aligned_malloc, который имеет совершенно другую семантику (несовместим с free/realloc)
Ничто не мешает для POSIX-ОС объявить aligned_realloc и aligned_free как синонимы для realloc, и free, и использовать именно эти синонимы при работе с выровненными данными, чтобы получался кроссплатформенный код.
Разработчики стандартной библиотеки VC++ могли бы сделать malloc и aligned_malloc совместимыми, но наверное их останавливает то, что тогда бы пришлось пожертвовать совместимостью с системным HeapAlloc, которая хоть и не заявлялась в документации, но какими-то разработчиками воспринималась как нечто очевидное, и какой-то софт на это наверняка полагается. Также катастрофически сломалась бы совместимость разных библиотек, использующих разные версии рантайма, где данные выделяются в одной библиотеке, а освобождаются в другой. Такой вариант использования тоже официально не поддерживается, но наверняка случается. Ну и Microsoft старается без острой надобности не ломать даже такие кривые случаи, когда код неправильный, и оно вроде как работает, но совсем по счастливому стечению обстоятельств.
Лучше бы, конечно, Microsoft добавила системный HeapAllocAligned, совместимый с HeapAlloc/HeapFree, и через лет 10 его можно было бы уже везде использовать без дополнительных танцев…
Разработчики стандартной библиотеки VC++ могли бы сделать malloc и aligned_malloc совместимыми, но наверное их останавливает то, что тогда бы пришлось пожертвовать совместимостью с системным HeapAlloc, которая хоть и не заявлялась в документации, но какими-то разработчиками воспринималась как нечто очевидное, и какой-то софт на это наверняка полагается. Также катастрофически сломалась бы совместимость разных библиотек, использующих разные версии рантайма, где данные выделяются в одной библиотеке, а освобождаются в другой. Такой вариант использования тоже официально не поддерживается, но наверняка случается. Ну и Microsoft старается без острой надобности не ломать даже такие кривые случаи, когда код неправильный, и оно вроде как работает, но совсем по счастливому стечению обстоятельств.
Лучше бы, конечно, Microsoft добавила системный HeapAllocAligned, совместимый с HeapAlloc/HeapFree, и через лет 10 его можно было бы уже везде использовать без дополнительных танцев…
А это по-вашему что?нестандартная функция сишного рантайма мс, не удовлетворяющая требованиям к aligned_malloc?
Ничто не мешает для POSIX-ОС объявить aligned_realloc и aligned_free как синонимы для realloc, и free, и использовать именно эти синонимы при работе с выровненными данными, чтобы получался кроссплатформенный код.мешает то, что _aligned_free не может освобождать память, выделенную через malloc.
мешает то, что _aligned_free не может освобождать память, выделенную через malloc.Это не мешает писать кроссплатформенный код. Выделил память через aligned_malloc/_aligned_malloc? Значит освобождай через algined_free (который под Windows будет синонимом _aligned_free, а под POSIX будет просто free).
еще раз: по требованиям стандарта, free может освобождать память выделенную как через aligned_malloc, так и через malloc. Никакая комбинация из malloc/free/_aligned_alloc/_aligned_free таким свойством не обладает.
В своём коде я действительно могу соблюдать пары _aligned_alloc/_aligned_free, однако если я допустим хочу перенести огромную кодобазу на винду, в общем случае я не смогу знать, какой из free в этой кодобазе надо заменить на _aligned_free. Это не проблема языка с++ что рантайм от майкрософт не способен выполнить такое требование. Более того, это следствие политики MS по намеренному усложнению переносимости кода между платформами.
В своём коде я действительно могу соблюдать пары _aligned_alloc/_aligned_free, однако если я допустим хочу перенести огромную кодобазу на винду, в общем случае я не смогу знать, какой из free в этой кодобазе надо заменить на _aligned_free. Это не проблема языка с++ что рантайм от майкрософт не способен выполнить такое требование. Более того, это следствие политики MS по намеренному усложнению переносимости кода между платформами.
Ну вот есть стандарт, а есть реальный мир. В этом реальном мире нет красивого решения для реализации aligned_malloc в стандартной библиотеке VC++ без недостатков. В стандарте позаботились о том, что char может быть 9 бит, но не позаботились о том, что освобождение выделенной через aligned_malloc памяти при помощи free может быть неприемлемым. Мир неидеален.
В большой программе, если её писали сразу строго под Linux, даже при портировании на MacOS или FreeBSD будет масса проблем. Мне вот недавно надо было при получении UDP-пакета заглянуть какой именно IP-адрес назначения был указан в пакете (чтобы определить был ли он broadcast). И у всех ОС для этого свои нестандартные расширения. Хотя казалось бы, обычные сокеты… В любой достаточно большой программе таких примеров будет масса.
А если заранее задаваться вопросами кроссплатформенности, то и проблема с выделением и освобождением выровненной памяти на всех ОС решается достаточно просто.
В большой программе, если её писали сразу строго под Linux, даже при портировании на MacOS или FreeBSD будет масса проблем. Мне вот недавно надо было при получении UDP-пакета заглянуть какой именно IP-адрес назначения был указан в пакете (чтобы определить был ли он broadcast). И у всех ОС для этого свои нестандартные расширения. Хотя казалось бы, обычные сокеты… В любой достаточно большой программе таких примеров будет масса.
А если заранее задаваться вопросами кроссплатформенности, то и проблема с выделением и освобождением выровненной памяти на всех ОС решается достаточно просто.
Ну вот есть стандарт, а есть реальный мирв этом конкретном случае другим ОС ничто не помешало соответстовать стандарту
В большой программе, если её писали сразу строго под Linux, даже при портировании на MacOS или FreeBSD будет масса проблемесли я написал программу «строго под linux», а потом её пришлось переносить и я огреб проблем, то я сам виноват. Проблема-то в том, что если я написал программу, соответствующую стандарту языка с++ и posix, она будет работать на всех платформах, кроме windows и всяких микрух.
А если заранее задаваться вопросами кроссплатформенности, то и проблема с выделением и освобождением выровненной памяти на всех ОС решается достаточно просто.в том, что на винде не работает aligned_malloc, виноват не программист, который этот метод заиспользовал. А вы сейчас victim blaming'ом занимаетесь.
в этом конкретном случае другим ОС ничто не помешало соответстовать стандартуЭти другие ОС не заботятся так о совместимости. Linux/FreeBSD просто целиком со всем ПО пересобирают с новым рантаймом C. MacOS раз в 5 лет дропает поддержку всего старого ПО.
Зато на Windows я могу прямо сейчас взять бинарник бородатого Firefox (Phoenix) 0.1, и он сразу запустится. А на Linux или MacOS у вас так не выйдет. Даже собрать из исходников наверняка окажется весьма непросто, придётся очень много и долго танцевать.
А то что стандарт написали так, что где-то без серьёзных недостатков его не реализовать в полной мере, то это явно недосмотр писателей стандарта. Стандарт C обычно учитывает самые невероятные варианты использования языка, а тут недосмотрели. Могли бы прописать, что вот есть aligned_realloc и aligned_free, которые будут всегда и везде работать с тем, что было выделено через aligned_malloc, а возможность использовать realloc и free в этом случае зависит от реализации. На мой взгляд это было бы гораздо более практичной вещью, нежели формальная поддержка 9 и более битных char и подобного, с чем можно столкнуться только в каких-то невероятно специфичных условиях.
нет, о совместимости как раз таки другие оси заботятся больше, т.к. там не принято как в винде тянуть за собой по по десятку бинарно несовместимых версий одних и тех же библиотек. А еще там не принято тянуть все недостающие библиотеки в установщике приложения.
А то что стандарт написали так, что где-то без серьёзных недостатков его не реализовать в полной мере, то это явно недосмотр писателей стандартакак вообще проектировать стандарты для ОС компании, которая намеренно отклоняется от стандартов чтобы сохранить монополию на рынке ОС за счет обеспечения непереносимости кода?
нет, о совместимости как раз таки другие оси заботятся большеИменно поэтому в этих ОС старый софт не работает. Логично.
А еще там не принято тянуть все недостающие библиотеки в установщике приложения.Именно поэтому и придумали snap и flatpak. Логично.
как вообще проектировать стандарты для ОС компании, которая намеренно отклоняется от стандартов чтобы сохранить монополию на рынке ОС за счет обеспечения непереносимости кода?Как вам там в 90-х?
Именно поэтому в этих ОС старый софт не работает. Логично.на винде знаете тоже не любой давности софт работает. И если на линуксе бородатый софт хоть с приседаниями но получится собрать, на винде многие так и сидят на XP потому что на более новых осях уже не запускается
Именно поэтому и придумали snap и flatpak. Логично.однако их использование не приветствуется.
Как вам там в 90-х?так ничего же не поменялось. Вместо того чтобы двигаться в направлении переносимости кода между windows и linux MS встроили WSL2 в винду, чтобы в ней можно было выполнять линуксовый код, но не наоборот.
на винде знаете тоже не любой давности софт работаетКорректно написанный софт для Windows NT 3.5 или 95 и новее, который не опирается сильно на какие-то недокументированные фичи — отлично работает. У меня огромное количество древнего ПО на компьютере (считайте хобби), в редких случаях были проблемы с запуском на современных версиях ОС, и все решились танцами, чаще всего тривиальными. Самое большое потрясение было при переходе на 64-разрядную версию системы: там нет поддержки 16-разрядных приложений. Да, у меня есть маленькая кучка и 16-разрядных приложений эпохи до Windows 95. Для них держу виртуалку.
Даже на уровне драйверов, где API гораздо менее стабилен, неплохой уровень совместимости сохраняется. У меня на работе наш драйвер поддерживал все ОС начиная от Windows XP и заканчивая самой последней Windows 10 (вот буквально один бинарник на все версии ОС). Несколько месяцев назад только XP и Vista дропнули. Сравните это с Linux, где драйвер должен быть собран под конкретную версию ядра.
однако их использование не приветствуется.Может быть в вашем мире и так, а в жизни я часто вижу такую картину: we strongly recommend that most users install Certbot through the snap.
Вместо того чтобы двигаться в направлении переносимости кода между windows и linux MS встроили WSL2 в винду, чтобы в ней можно было выполнять линуксовый код, но не наоборот.Вот именно, что они добавили ряд вещей в Windows, чтобы упростить написание кроссплатформенного кода под Windows и под Linux. Поддержку UTF-8 в консоль завезли (вместо UTF-16, с которым крайне сложно в Linux), поддержку обычных esc-последовательностей, поддержку unix-сокетов, и т.д. Компилятор свой родной привели в гораздо более соответствующий стандартам вид, вместе с Visual Studio предлагают поставить и Clang для кроссплатформенной разработки. Даже .NET нынче самой Microsoft официально поддерживается и развивается под все популярные платформы.
Корректно написанный софт для Windows NT 3.5 или 95 и новее, который не опирается сильно на какие-то недокументированные фичи — отлично работаетнюанс в том, что в большинстве проектов где-нибудь что-нибудь да написано криво, где-нибудь спрятано использование недокументированных фич, где-нибудь завязка на железо… Это проявляется и в линуксе конечно же.
Вот именно, что они добавили ряд вещей в Windows, чтобы упростить написание кроссплатформенного кода под Windows и под Linux.еще раз. Они сделали возможным запуск linux приложений под виндой, но не наоборот. Вы не видите в этом монопольной практики или не хотите видеть?
Поддержку UTF-8 в консоль завезли (вместо UTF-16, с которым крайне сложно в Linux)это не «в linux крайне сложно с UTF-16», а «какого-то лешего в винде вместо адекватного UTF-8 склеенный соплями веер 16-битных кодировок, которые для вызовов ядра конвертируются в UTF-32».
Компилятор свой родной привели в гораздо более соответствующий стандартам вид, вместе с Visual Studio предлагают поставить и Clang для кроссплатформенной разработки.будь я с++-разработчиком в MS я бы тоже взвыл окажись порт стороннего компилятора под винду лучше нативного по всем фронтам.
нюанс в том, что в большинстве проектов где-нибудь что-нибудь да написано криво, где-нибудь спрятано использование недокументированных фичНо почему я не вижу этого в «большинстве проектов»? Большинство — это хотя бы больше 50%. В моей практике 90% старого ПО работает отлично без танцев, 99% с минимальными танцами, и остальное решается скальпелем.
Они сделали возможным запуск linux приложений под виндой, но не наоборот.Windows как бы ОС этой компании, они её и развивают. Логично же. Линус Торвальдс, когда развивает Linux, не обязан попутно развивать FreeBSD, MacOS, или Windows. Не Canonical добавила поддержку Linux в Windows, а сама Microsoft. Это же логично, что каждый развивает свой продукт. Странно ожидать чего-то другого.
Вы не видите в этом монопольной практики или не хотите видеть?Вы совсем недавно придиралсь к Microsoft что они не позволяют писать кроссплатформенный код, создавая всякие нестандартные расширения. Но когда выяснилось, что они сильно облегчили написание кроссплатформенного кода, вы тут же внезапно повысили требования до того, что хотите, чтобы Microsoft портировала Windows на Linux. Вы вообще в своём уме? Разработчики Linux/FreeBSD/MacOS не могут договориться между собой, чтобы упростить написание совместимого кода сразу под все эти ОС, которые во многом похожи. А тут совершенно непохожая Windows. Это были бы сотни миллионов долларов, выпущенные на ветер совершенно с непонятной целью, так как у такого решения очевидно совместимость будет на порядок хуже, чем у родной ОС.
это не «в linux крайне сложно с UTF-16», а «какого-то лешего в винде вместо адекватного UTF-8 склеенный соплями веер 16-битных кодировок, которые для вызовов ядра конвертируются в UTF-32».Вы явно не в теме. Бесплатный экскурс в историю. Ядро Windows NT использует UTF-16 с самого начала и до сих пор. Когда проектировалась и разрабатывалась Windows NT (начиная с 1989), UTF-8 ещё не существовало в природе (он появился только в 1992). На тот момент UTF-16 было самым прогрессивным видением будущего, казалось что в будущем все на него перейдут, и достаточно долго это отношение к нему сохранялось, даже после появления UTF-8. Тогда он попал в Java, JavaScript, C# (и чуть не попал в PHP, планировалось в невышедшем PHP 6). Авторы UTF-8 ставили целью совместимость с ASCII как раз для того, чтобы было проще старый код адаптировать на новый лад. Но к тому времени Microsoft уже успела пойти по более сложному пути с введением UTF-16, и добавлением слоя совместимости со старыми ANSI-приложениями. Годы спустя многим стало понятно, что UTF-16 был ошибкой, и лучше было следовать по пути совместимости с ASCII, то есть UTF-8, но уже слишком поздно это менять.
Linux в этом плане повезло, так как когда понадобился Unicode, UTF-8 уже был придуман, и не пришлось так запариваться. Ну а Microsoft поплатилась за то, что одна из первых взялась поддержку Unicode. Они по сути проделали гораздо больше работы (всё пришлось писать с нуля, все API пришлось продублировать), при этом создав скорее проблему, так как весь мир в итоге так и не перешёл на UTF-16, и продолжает пользоваться в основном ASCII-совместимыми кодировками.
Но когда выяснилось, что они сильно облегчили написание кроссплатформенного кода, вы тут же внезапно повысили требования до того, что хотите, чтобы Microsoft портировала Windows на Linuxнет, я хочу, чтобы windows поддерживала posix, имела адекватную system-wide UTF-8 и всё в таком духе. Чтобы совместимость была на уровне сорцов, а не в виде костыля, который позволит MS утилизировать наработки других ОС
Годы спустя стало многим понятно, что UTF-16 был ошибкой, и лучше было следовать по пути совместимости с ASCII, то есть UTF-8, но уже слишком поздно это менять.чет эплу годы не мешают что-то там менять
имела адекватную system-wide UTF-8Ну в Windows 10 приложения уже несколько лет могут использовать UTF-8 в системных вызовах. Эта возможность конечно же должна явно активироваться манифестом приложения, так как иначе сломались бы все существующие ANSI-приложения. Но это упрощает написание новых кроссплатформенных приложений, так как в принципе возможно.
я хочу, чтобы windows поддерживала posixСовместимость на уровне сорсов у POSIX-совместимых ОС так себе. Я вам приводил пример выше. Таких различий полно. А Windows совсем другая ОС, её API уровня пользователя проектировался для совместимости с исходным кодом под Win16, а не POSIX. Подсистема POSIX там тоже была, но не прижилась.
чет эплу годы не мешают что-то там менятьВозьмём Age of Empires II под мак (2001 года выпуска). Есть ли шанс запустить? Давайте подумаем. Сколько раз там сломали совместимость? Даже если не считать поломки совместимости на уровне API, можно ещё вспомнить переход с PowerPC на Intel x86-32, затем на Intel x86-64, а теперь вот на ARM. PowerPC не поддерживается уже забыли сколько лет, от поддержки Intel x86-32 отказались относительно недавно, через пару лет откажутся и от Intel x86-64. На фоне этого то что совместимость API в процессе часто ломалась как-то не очень уже и заметно. У Age of Empires II под мак просто нет шансов.
Apple ничего не мешает, так как их политика «никакой совместимости, никакого старого ПО». А Microsoft прикладывает очень много усилий в обеспечение совместимости. Хотя кажется, что они пробуют найти путь, как бы снять с себя эту непростую ношу. Windows RT провалилась, на очереди Windows 10X.
Хотя… Вроде же как NSString хранится в UTF-16? Я в последний раз писал под макось/айос много лет назад, но кажется, что было так. Сомневаюсь, что это переделали. Слишком много возни, хотя с их периодическим полным отказом от старого ПО они и могли бы такое провернуть.
Подсистема POSIX там тоже была, но не прижилась.не было её там, они формально реализовали пару требований posix 1.0 для получения какого-то крупного госзаказа, а дальше дело не пошло.
Хотя кажется, что они пробуют найти путь, как бы снять с себя эту непростую ношу. Windows RT провалилась, на очереди Windows 10X.еще посмотрим как у ARM получится конкурировать с x86 и как у microsoft получится с адаптацией него. Будет грустно если легаси останется последним конкурентным преимуществом винды
Я вообще вам много могу рассказать о возможных причинах несовместимости, так как я реверсил и исправлял подобные проблемы (хобби), и во всех случаях оказывалось, что был виноват крайне кривой код.
Например, рендерер DX6 для Need For Speed III начинал падать после установки более свежей версии драйвера на видеокарту (или при переходе на новую версию ОС, где сразу идёт новый драйвер). Пользователи ругали Nvidia и Microsoft. А оказалось, что игра хранила информацию о поддерживаемых драйвером форматов текстур в фиксированном массиве, при заполнении которого не проверялся выход за пределы массива. Когда поддерживаемых форматов текстур стало больше 13, игра стала падать.
Или игра измеряет частоту процессора, количество оперативной памяти, и видеопамяти, и в зависимости от этого определяет, насколько у пользователя мощный компьютер, и насколько высокую детализацию в игре надо использовать. Так вот, все три этих параметра — int32. Как только частоты процессоров перевалили за 2 гигагерца, а количество видеопамяти и оперативной памяти перевалило за 2 гигабайта, начались проблемы. Need For Speed 5 выбирает самый низкий уровень детализации для машин (выглядит отвратительно и не настраивается, нужен патч), Need For Speed III выбирает по умолчанию самые низкие настройки для всего (но это можно починить из настроек) и отказывается показывать кабину машины при виде «из машины» (но это настройками не починить, нужен патч) и т.д.
Например, рендерер DX6 для Need For Speed III начинал падать после установки более свежей версии драйвера на видеокарту (или при переходе на новую версию ОС, где сразу идёт новый драйвер). Пользователи ругали Nvidia и Microsoft. А оказалось, что игра хранила информацию о поддерживаемых драйвером форматов текстур в фиксированном массиве, при заполнении которого не проверялся выход за пределы массива. Когда поддерживаемых форматов текстур стало больше 13, игра стала падать.
Или игра измеряет частоту процессора, количество оперативной памяти, и видеопамяти, и в зависимости от этого определяет, насколько у пользователя мощный компьютер, и насколько высокую детализацию в игре надо использовать. Так вот, все три этих параметра — int32. Как только частоты процессоров перевалили за 2 гигагерца, а количество видеопамяти и оперативной памяти перевалило за 2 гигабайта, начались проблемы. Need For Speed 5 выбирает самый низкий уровень детализации для машин (выглядит отвратительно и не настраивается, нужен патч), Need For Speed III выбирает по умолчанию самые низкие настройки для всего (но это можно починить из настроек) и отказывается показывать кабину машины при виде «из машины» (но это настройками не починить, нужен патч) и т.д.
На C/C++ написаны такие огромные и важные системы, что в ближайшие лет 100 он точно никуда не денется. Никто не станет переписывать тот же Blink на каком-то другом языке. Слишком дорого. Проще потихонечку причёсывать сам C/C++.
Мне кажется, что C++ «игру переносимости» не то что не проиграл — он в ней просто не пытался участвовать, да и нужды особой нет :-) Автор преувеличивает масштаб проблемы.
Если нужна переносимость, есть другие варианты: java, а с недавних пор .net core. Бизнес-разработку обслуживают прекрасно.
Можно писать на условно переносимом стандартном C++ (перекомпилировать-то всё равно придётся), но тогда преимущества по сравнению с упомянутыми языками не так уж велики.
Если же требуется выжать по максимуму, то да, вступаем на территорию конкретного железа. Что странного, что на ARM не работают интеловские интринсики?
Ниша, где нужны одновременно максимальная производительности и полная переносимость кажется мне очень узкой.
Если нужна переносимость, есть другие варианты: java, а с недавних пор .net core. Бизнес-разработку обслуживают прекрасно.
Можно писать на условно переносимом стандартном C++ (перекомпилировать-то всё равно придётся), но тогда преимущества по сравнению с упомянутыми языками не так уж велики.
Если же требуется выжать по максимуму, то да, вступаем на территорию конкретного железа. Что странного, что на ARM не работают интеловские интринсики?
Ниша, где нужны одновременно максимальная производительности и полная переносимость кажется мне очень узкой.
мне кажется вы не совсем правильно понимаете переносимость. Грубо говоря, не будь с++ код переносимым, написать на нём кроссплатформенную jvm чтобы обеспечить переносимость java было бы примерно невозможно. По сути, задача — добиться чтобы один код работал на разных платформах, не обязательно чтобы это был один и тот же бинарь. И желательно добиться этого без лишних накладных расходов, по крайней мере в случае с++.
Если же требуется выжать по максимуму, то да, вступаем на территорию конкретного железавы игнорируете пласт задач, для которых спускаться до ассемблера обычно не имеет смысла, но производительность тем не менее важна. Задачи обработки текста, например, вполне себе реализуемы в рамках переносимого с++.
Sign up to leave a comment.
Что случится раньше: умрет С++ или вымрут С++ программисты?