Итаниум не на пустом месте начали делать, а из-за понимания тупиковости архитектуры х86. В итоге проект провалился из-за выбора неподходящей архитектуры, а сама интел надежно забетонировалась в тупике х86.
Что движет людьми которые тратят свое время на разработку глубоко вторичного не оригинального продукта? Ну я понимаю потратить время на что-то оригинальное, тем более что в интерфейсе всегда есть куда расти, но на ухудшенные копии то зачем?
Потребная "мощность" тормозной системы на автомобилях больше 1000 л.с, а для тяжелого электромобиля еще больше. И все это теперь пойдет не на колодки, а на трансмиссию. В мерседесе в предвкушении потирают руки, что теперь пользователям придется регулярно менять не копеечные колодки и диски, а шрузы и привода. Пылеулавливатель в суппорте мне как пользователю (и противнику загрязнения) нравится гораздо больше.
Лично я уже более 10 лет в С++ сериализую данные используя доморощенную рефлексию времени выполнения. На половинчатые решения которые работают только для самых простейших случаев я не полагаюсь.
А я пишу на с++ и совсем немного на шарпе, и ещё ни разу мне в с++ не потребовалась функциональность шарпа.
Думаю что как минимум вам не хватает интерполяции строк
Чтобы это работало нужно либо иметь либо полные исходники, либо полное представление программы в байт-коде. Просто какой-то расширенной информации о типах будет недостаточно. Если к примеру при генерации вызывается существующая функция программы, а в программе компилятор ее заинлайнил. Иными словами сначала придется сделать какой-то байт код, добавить JIT в стандартную блиотеку, сделать рефлексию времени выполнения как в шарпе, привести в порядок ООП в языке и т.п. Объем работы и изменений в языке здесь такой, что раньше второго пришествия комитет это не осилит.
Нормальный код делающий ту же задачу называется интерпретатор. По этому и возникает такой прирост производительности за счет компиляции на лету в нативный код и отсутствия интер-опа
Вам просто не надо занимать позицию интеллектуального превосходства заявляя, что на С++ задачи огого, а в шарпе люди только json из базы перекладывают. Я использую шарп и С++ и многие шарп-задачи делать на С++ не просто нецелесообразно, а просто физически нельзя т.к. в С++ не существует такой функциональности.
Мой совет всем С++ разработчикам поменьше "легко представлять" и побольше знакомится с реальностью.
Что касается анализа различных потоков на лету то здесь есть и другая сторона медали. Я когда впервые в шарпе сгенерировал класс на лету и оценил какой прирост производительности это дало, то сразу же осознал насколько нелепы претензии С++ на всю сферу высокой производительности (о чем так любят кричать адепты С++ с крыш домов). Высокая у вас будет только на статических задачах с фиксированными методами анализа. Там где методы определяет пользователь у С++ перед шарпом ноль шансов.
Не льстите себе. Без лоскутного одеяла возможностей С++ вполне можно обойтись. Когда же что-то делаешь в шарпе то часто себя ловишь на мысли, что в С++ это фактически не реализуемо.
Проблема в том что комитет не в состоянии поправить баги в языке обнаруженные еще более 10 лет назад.
И какие у это реальные области применения?
Очевидно же что все области где правила или логика определяются пользователем и при этом требуется высокая производительность.
Вы там ниже сами привели пример, отвечающий на этот вопрос (структуры->кортежи).
Т.е. нигде. Потому что задачи преобразования структуры в кортеж не существует.
Начните в своих шарпах и жавах со специализаций и родов выше * -> *, а там посмотрим.
Вы слишком переоцениваете ценность этих "концепций" и "парадигм" которые нагородили в современном С++. Я пишу на С++ и шарпе и еще ни разу в шарпе мне не потребовалась функциональность из С++.
Пропозал по этой проблеме (вложенных классов) был еще в 2013 году. С тех пор воз и ныне там.
Метапрограммирование в джаве и шарпе сделано на недостижимой для С++ высоте. Вы можете создавать классы на лету и генерировать байт код который JIT превратит в машинный. В С++ метапрограммирование ограничено временем компиляции, что делает его неприменимым во множестве сценариев. Вот сейчас лепят очередное ноу-хау - статическую рефлексию. А кому эта статическая рефлексия нужна? Опять возникнет миллион костылей для организации динамической рефлексии на базе статической. И когда говорят о метапрограммировании в С++ мне становится смешно. Посмотрите хотя бы на реализацию костыля из boost который преобразует структуру в кортеж. Под капотом у него сгенерированный скриптом код для ограниченного количества сценариев. В чем смысл этого метапрограммирования если оно постоянно упирается в нереализованные возможности и баги языка которые принципиально не исправляются?
Надо сравнивать не с АМД, а с Qualcomm.
Итаниум не на пустом месте начали делать, а из-за понимания тупиковости архитектуры х86. В итоге проект провалился из-за выбора неподходящей архитектуры, а сама интел надежно забетонировалась в тупике х86.
У интел был шанс выбрать вместо EPIC RISC в итаниуме. Кто там итаниум делал? Вот это и есть люди забившие последний гвоздь в крышку гроба.
от сенсора уже отказываются.
https://habr.com/ru/news/781534/
В чем смысл отказа от таких проверенных временем и удобных решений как подрулевые переключатели?
Терабайт информации понять гораздо проще чем содержимое глиняной таблички на сотню знаков.
Что движет людьми которые тратят свое время на разработку глубоко вторичного не оригинального продукта? Ну я понимаю потратить время на что-то оригинальное, тем более что в интерфейсе всегда есть куда расти, но на ухудшенные копии то зачем?
Потребная "мощность" тормозной системы на автомобилях больше 1000 л.с, а для тяжелого электромобиля еще больше. И все это теперь пойдет не на колодки, а на трансмиссию. В мерседесе в предвкушении потирают руки, что теперь пользователям придется регулярно менять не копеечные колодки и диски, а шрузы и привода. Пылеулавливатель в суппорте мне как пользователю (и противнику загрязнения) нравится гораздо больше.
Для ИП на УСН налог 6% с продажи криптовалюты?
Лично я уже более 10 лет в С++ сериализую данные используя доморощенную рефлексию времени выполнения. На половинчатые решения которые работают только для самых простейших случаев я не полагаюсь.
Думаю что как минимум вам не хватает интерполяции строк
Чтобы это работало нужно либо иметь либо полные исходники, либо полное представление программы в байт-коде. Просто какой-то расширенной информации о типах будет недостаточно. Если к примеру при генерации вызывается существующая функция программы, а в программе компилятор ее заинлайнил. Иными словами сначала придется сделать какой-то байт код, добавить JIT в стандартную блиотеку, сделать рефлексию времени выполнения как в шарпе, привести в порядок ООП в языке и т.п. Объем работы и изменений в языке здесь такой, что раньше второго пришествия комитет это не осилит.
Нормальный код делающий ту же задачу называется интерпретатор. По этому и возникает такой прирост производительности за счет компиляции на лету в нативный код и отсутствия интер-опа
А почему вы для C# выбираете какие-то тривиальные примеры? А для С++ какие-то потоки и dpi.
Если бы вы написали: "легко представить, что на С# вы используете Unity, а на С++ Unreal" это было бы равноценно.
Вот показываю пальцем:
Вам просто не надо занимать позицию интеллектуального превосходства заявляя, что на С++ задачи огого, а в шарпе люди только json из базы перекладывают. Я использую шарп и С++ и многие шарп-задачи делать на С++ не просто нецелесообразно, а просто физически нельзя т.к. в С++ не существует такой функциональности.
Мой совет всем С++ разработчикам поменьше "легко представлять" и побольше знакомится с реальностью.
Что касается анализа различных потоков на лету то здесь есть и другая сторона медали. Я когда впервые в шарпе сгенерировал класс на лету и оценил какой прирост производительности это дало, то сразу же осознал насколько нелепы претензии С++ на всю сферу высокой производительности (о чем так любят кричать адепты С++ с крыш домов). Высокая у вас будет только на статических задачах с фиксированными методами анализа. Там где методы определяет пользователь у С++ перед шарпом ноль шансов.
Не льстите себе. Без лоскутного одеяла возможностей С++ вполне можно обойтись. Когда же что-то делаешь в шарпе то часто себя ловишь на мысли, что в С++ это фактически не реализуемо.
Рефлексия нужна, она позволяет без костылей делать многие вещи.
Чего в С++ очевидно никогда не будет, а следовательно производительность шарпа и явы в таких сценариях будет недостижима.
Проблема в том что комитет не в состоянии поправить баги в языке обнаруженные еще более 10 лет назад.
Очевидно же что все области где правила или логика определяются пользователем и при этом требуется высокая производительность.
Т.е. нигде. Потому что задачи преобразования структуры в кортеж не существует.
Вы слишком переоцениваете ценность этих "концепций" и "парадигм" которые нагородили в современном С++. Я пишу на С++ и шарпе и еще ни разу в шарпе мне не потребовалась функциональность из С++.
Пропозал по этой проблеме (вложенных классов) был еще в 2013 году. С тех пор воз и ныне там.
Метапрограммирование в джаве и шарпе сделано на недостижимой для С++ высоте. Вы можете создавать классы на лету и генерировать байт код который JIT превратит в машинный. В С++ метапрограммирование ограничено временем компиляции, что делает его неприменимым во множестве сценариев. Вот сейчас лепят очередное ноу-хау - статическую рефлексию. А кому эта статическая рефлексия нужна? Опять возникнет миллион костылей для организации динамической рефлексии на базе статической. И когда говорят о метапрограммировании в С++ мне становится смешно. Посмотрите хотя бы на реализацию костыля из boost который преобразует структуру в кортеж. Под капотом у него сгенерированный скриптом код для ограниченного количества сценариев. В чем смысл этого метапрограммирования если оно постоянно упирается в нереализованные возможности и баги языка которые принципиально не исправляются?