Здравствуйте, lpd, Вы писали:
_>>Не избыточна. Вот смотри пример. Сейчас при разработке на C++ приложения под Андроид приходится пихать в дистрибутив (apk) от 2 (самые распространённые) до 6 (теоретический максимум в данный момент, охватывающий точно всё) версий приложения, под разные процессорные архитектуры. Если бы вместо этого мы компилировали приложение в llvm, а потом при инсталляции приложения на устройство перекомпилировали в машинные коды процессора данного устройства (кстати, в современном Андроиде именно так и происходит с Java кодом), то можно было бы класть только одну версию приложения в дистрибутив, что гораздо удобнее и экономнее. Причём это всё было бы без малейших потерь в производительности. lpd>Конкретно для Android необходимость поддержки разных процессоров, на мой взгляд, сомнительна.
Ну почему же. Планшеты на x86 вполне распространены. А в Китае и на MIPS попадаются, хотя это уже действительно экзотика.
lpd>Более значительным преимуществом является безопасность кода по сравнению с C, однако эту проблему можно решить и без байткода.
Эээ что? Как вообще пересекается безопасность и байт-код? Ты вообще о чём? )
lpd>Сейчас же Java и C# популярны в основном из-за наличия более проработанных фреймворков и средств сборки по сравнению с C++, а не из-за принципиальных преимуществ, которые дает байткод.
Главную и единственную причину популярности Java и C# я указал ещё в первом своём сообщение в данной теме. И потом ещё повторял пару раз. Более того, тут ещё несколько человек высказали эту же мысль. Но ты похоже полностью проигнорировал это всё.
Ну и если тебе всё же не интересно читать, а ты хочешь сам додумываться до правильных ответов, то могу дать один простой совет по данному вопросу. Попробуй взглянуть на ситуацию не глазами программиста, а глазами владельца бизнеса (которому надо решить конкретную задачу минимальным вложением денег).
lpd>Хотя идея перенести часть процесса компиляции в рантайм или на этап инсталляции интересна. Однако портабельность сужает круг задача, которые код может решить.
Все проблемы портабельности обычно связаны с ОС и т.п., а не с архитектурой процессора. )))
lpd>А портабельность как раз больше нужна в embedded системах.
Ээээ что? )
lpd>Вообщем, субъективно я бы предпочел, чтобы программа была представлена ввиде привычных машинных инструкций, а не скармливалась JVM-монстру. Но допускаю, что у других людей мнение может быть отличное.
Вообще то байт-код Java — это как раз машинные инструкции, только не для процессора x86. Более того, такие процессоры даже существовали в железе.
И llvm — это так же вполне себе машинные инструкции. Вот посмотри например эту https://habrahabr.ru/post/277717/ статью — неплохое введение в данную область.
Здравствуйте, pilgrim_, Вы писали:
_>>Там у тебя или явно полиморфный объект (ссылка или указатель) или явно нет (обычная переменная и именно их большинство в нормальном коде). Так что в последнем случае компилятор может абсолютно гарантированно подставлять нужный вызов. _>Тут тоже интересная тема, чем отличается для компилятора A a; a.f.();, от A* a; a->f(); , что сlang ,что gcc генерят в последнем случае косвенный вызов.
В последнем случае вообще UB.
А вот такой вызов A* a = new A; a->f() — вполне инлайнится, и даже вот такой auto x = std::make_shared<A>(); x->f();
_>>В отличие от C#, где любой объект может быть инициализирован экземпляром другого класса где-то выше по коду. И как по твоему решает это проблему компилятор C#? ) _>Никак, т.е влоб — полиморфно, так же ка и в C++
Если объявление вида A x;, то вызов x.virtual_method() без проблем инлайнится, даже если находится где-то очень "далеко"
Здравствуйте, Qbit86, Вы писали:
_>>Угу, интересно как много программистов на .net думают аналогично (подозреваю что все эти .NET Core и т.п. до сих пор выглядят странной экзотикой для большинства). Q>Не так уж много программистов на C++ подозревают, что есть какие-то там циферки после плюсов: C++11, C++14, C++17. Все эти && и move-семантика выглядят странной экзотикой для большинства.
Безусловно. Но не забывай в чём единственное преимущество Java/C# над C++. Или ты хочешь его похоронить? )))
_>>Но не в этом суть. Ты лучше скажи, что мне взять, чтобы написать десктопное приложение на .net работающее и под виндой и под линухом. Или снова будем звать на помощь C/C++ библиотеки? Q>Гуйнёй я не занимаюсь, подробно не скажу. Последний раз, когда делал интерфейс утилитки для выкладки в Google Play Store, использовал Unity. Работало одинаково на Windows и Android.
GUI на игровом движке? Это сильно.))) В принципе тогда можно было сразу назвать OpenGL и это действительно был бы реально кроссплатформенный ответ. )))
_>>Т.е. ты хочешь сказать, что в мире C# отношение к WPF приблизительно такое же, как в мире C++ к MFC? Я правильно понял твою мысль? Q>А почему ты задаёшь столько вопросов? Тебе нравится вести в такой манере дискуссии? У тебя все экзаменуемые или что? Проще говоря: ты вообще что за **й, чтоб кого-то так снисходительно экзаменовать? скобка-скобка-скобка
О, я смотрю у тебя уже пошёл переход на личность... Так всегда случается, когда заканчиваются технически аргументы по теме дискуссии. )))
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>Тут тоже интересная тема, чем отличается для компилятора A a; a.f.();, от A* a; a->f(); , что сlang ,что gcc генерят в последнем случае косвенный вызов.
EP>В последнем случае вообще UB.
Я создание объекта для краткости просто опустил
EP>А вот такой вызов A* a = new A; a->f() — вполне инлайнится, и даже вот такой auto x = std::make_shared<A>(); x->f();
Ну хз, мне тоже показалось странным, может опять дело дело в в опциях оптимизации? — https://godbolt.org/g/evs92d
_>>>В отличие от C#, где любой объект может быть инициализирован экземпляром другого класса где-то выше по коду. И как по твоему решает это проблему компилятор C#? ) _>>Никак, т.е влоб — полиморфно, так же ка и в C++
EP>Если объявление вида A x;, то вызов x.virtual_method() без проблем инлайнится, даже если находится где-то очень "далеко"
Это понятно, речь об аналоге коде который привел alex_public: _>>A a; _>>if(х) a=new B(); _>>else a=new C(); _>>a.f(); _>>
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>Более значительным преимуществом является безопасность кода по сравнению с C, однако эту проблему можно решить и без байткода.
_>Эээ что? Как вообще пересекается безопасность и байт-код? Ты вообще о чём? )
В Java/C# не может быть ошибки переполнения буфера, которая встречается в коде на C.
_>Ну и если тебе всё же не интересно читать, а ты хочешь сам додумываться до правильных ответов, то могу дать один простой совет по данному вопросу. Попробуй взглянуть на ситуацию не глазами программиста, а глазами владельца бизнеса (которому надо решить конкретную задачу минимальным вложением денег).
Вот причины меньших затрат бизнеса при использовании C# я и анализирую. И думаю, что дело не только круге знаний программистов.
lpd>>Хотя идея перенести часть процесса компиляции в рантайм или на этап инсталляции интересна. Однако портабельность сужает круг задача, которые код может решить.
_>Все проблемы портабельности обычно связаны с ОС и т.п., а не с архитектурой процессора. )))
lpd>>А портабельность как раз больше нужна в embedded системах.
_>Ээээ что? )
Я имею ввиду портабельность не банально между Windows и Linux, а возможность скомпилировать какую-то библиотеку для embedded системы(например, сжатие, обработку или распознавание видео). C++ код, как известно, по большей части процессоро-независим.
Итого: причинами популярности C#/Java ты называешь портабельность и большую сложность C++. К этому списку я бы добавил наличие проработанных фреймворков веб-приложений. Единственное принципиальное преимущество байт-кода в этом списке — только переносимость между разными ОС. Однако C++ код тоже может быть переносимым при перекомпиляции. У нас по сути всего 2 ОС, поэтому отсутствие перекомпиляции — не столь большое преимущество. Возникает вопрос(единственный существенный в данном случае), стоит ли ради этого вносить промежуточный уровень байткода между бинарником и исполнением программы? Именно к этому вопросу, как я считаю, выбор между C#/Java и C++ и сводится.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Serginio1, Вы писали:
_>>Ну ты же сам понимаешь, что это реально не решит проблему. S> Это уменьшает нагрузку на GC. В том числе может сразу применять финализаторы исинга.
Ещё раз повторяю: улучшит быстродействие — да, догонит C++ — нет.
_>>Кстати, а вот тут было бы интересно посмотреть поподробнее. А то я про это слышал, но конкретные технические подробности не изучал. Что значит сведена к минимуму? S>https://msdn.microsoft.com/ru-ru/library/dn600640(v=vs.110).aspx S>
S>Среда выполнения .NET Native не включает JIT-компилятор. В результате все необходимые машинные коды должны быть созданы заранее. Используется набор эвристических правил, чтобы определить, какой код должен создаваться, но они не могут охватывать все возможные сценарии метапрограммирования. Таким образом, необходимо предоставить подсказки для этих сценариев метапрограммирования с помощью директив среды выполнения. Если необходимые метаданные или код реализации недоступны во время выполнения, приложение вызывает исключение MissingMetadataException, MissingRuntimeArtifactException или MissingInteropDataException. Существуют два средства устранения неполадок, создающие соответствующую запись для файла директив среды выполнения, который устраняет исключение.
Пока ничего не понял из этой цитаты. Ты вот лучше поясни мне на конкретных примерах (если уже сам разобрался). Вот скажем сейчас для работы обычной рефлексии в .net необходимо резервирование дополнительной памяти (что не только приводит к перерасходу памяти приложением, но и к замедлению его работы) для метаинформации. Причём это происходит даже если вообще не пользоваться самой рефлексией. Так вот как обстоят дела с этим в .NET Native? Есть оно или нет? Или где-то есть, а где-то нет?
Да, и отдельно интересно как этим коррелируют библиотеки ориентированные на использование рефлексии (а таких же полно). Просто кидают это самое исключение? )
_>>P.S. Сборка вебкита под виндой — это весьма увлекательный квест. ))) Я помнится его когда-то проходил (причём ещё хотел всё сделать именно в своём окружение) и впечатления до сих пор яркие. ))) S> Вот и мне плохо. При этом, что я С++ знаю постольку поскольку.
Угу, и сразу взялся за то, от чего шарахаются даже матёрые C++'ки. Смело. )
Здравствуйте, pilgrim_, Вы писали:
_>>Конечно. Но нюанс в том, что подобный код не скомпилируется в C++. _>Ну типа я в курсе , добавим для C++ к A звездочку, я так понял что ты предостаивл типа псевдокод похожтй на C#/java
Нет, это был C#. )
_>>Там у тебя или явно полиморфный объект (ссылка или указатель) или явно нет (обычная переменная и именно их большинство в нормальном коде). Так что в последнем случае компилятор может абсолютно гарантированно подставлять нужный вызов. _>Тут тоже интересная тема, чем отличается для компилятора A a; a.f.();, от A* a; a->f(); , что сlang ,что gcc генерят в последнем случае косвенный вызов.
Это У тебя там что-то не то в тесте. Всё нормально преобразуется и инлайнится. )
_>>В отличие от C#, где любой объект может быть инициализирован экземпляром другого класса где-то выше по коду. И как по твоему решает это проблему компилятор C#? ) _>Никак, т.е влоб — полиморфно, так же ка и в C++
Я тоже так думаю. Только откуда тогда возьмутся оптимизации в C#, про которые ты говорил?
Re[44]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
A>>Честно говоря, я не очень понимаю, зачем среднестатистическому шутеру C++. В них нагрузка больше на графику, чем на игровую логику. Тут скорее С++ нужен не для шутеров, а просто для движков. _>Я вот тоже не очень понимаю зачем в автомобилях нужен металл. Он же ведь используется всего лишь для рамы, двигателя, передачи и т.п. А для кресел то нужна в основном кожа!
A>>Рендер, физика, анимация на C++, а игровая логика в зависимости от требований проекта на C++, C#, Lua, Python, что там ещё есть... _>А вот тут совершенно справедливая мысль. Правда как-то странно коррелирующая с предыдущим же предложением. )))
Объясняю: двигатель (1шт) невозможно переиспользовать, у движка же это основное предназначение. Любые аналогии всегда хромают, я давно перестал их использовать.
A>>Если у тебя специфический проект, типа Total War, Factorio, какой-нибудь открытый мир невообразимых размеров вроде Just Cause 3, то ты его пишешь с нуля на С++ именно под этот проект. Если проект менее амбициозный, берёшь существующий движок и, независимо от жанра, пишешь логику на том, на чём этот движок предлагает. Причём в скорость скорее упрутся игры с тяжёлой симуляцией, типа Cities Skylines, чем шутеры.
_>Разница таких проектов и всякой слабой ерунды, использующей движки типа Unity, совсем в другом. Просто их не устраивают возможности обычных простеньких движков, доступных на рынке и им приходится разрабатывать свой, под конкретные нужды своего мира.
Согласен. Тут принципиально отметить, что таких проектов, где свой специфический движок необходим, в год выходит условно десять, а всех остальных десять тысяч. Если хочешь пописать на С++ не для развлечения, а так чтобы это имело смысл, нужен специфический проект, которых мало, или надо идти к разработчикам движков, которых ещё меньше.
Конечно, не все проекты из оставшихся условных десяти тысяч используют сторонние движки, многие пишут свой. Зачем только, я понять не могу. Имхо, или предубеждение, или нежелание учить что-то новое, или синдром «not invented here» — только такие варианты приходят в голову.
Cities Skylines на C# в Unity симулирует здоровенный город; неужели Forest Village на самопальном движке и Lua не хватило бы того же Unity для симуляции деревни?
Здравствуйте, lpd, Вы писали:
_>>Эээ что? Как вообще пересекается безопасность и байт-код? Ты вообще о чём? ) lpd>В Java/C# не может быть ошибки переполнения буфера, которая встречается в коде на C.
И какое это имеет отношение к байт-коду?
_>>Ну и если тебе всё же не интересно читать, а ты хочешь сам додумываться до правильных ответов, то могу дать один простой совет по данному вопросу. Попробуй взглянуть на ситуацию не глазами программиста, а глазами владельца бизнеса (которому надо решить конкретную задачу минимальным вложением денег).
lpd>Вот причины меньших затрат бизнеса при использовании C# я и анализирую. И думаю, что дело не только круге знаний программистов.
Угу, и по этому основной сферой обитания Java и C# является корпоративное ПО в не IT компаниях (где IT отдел является всего лишь одной из внутренних служб, а не основой бизнеса). Ну просто совпадение такое. )))
lpd>Итого: причинами популярности C#/Java ты называешь портабельность и большую сложность C++.
Про портабельность я ничего не говорил. Ты всё время путаешь. Если я высказываю аргументы о пользе применения в определённых ситуациях технологий байт-кода, то это не значит что я отношу это к преимуществам Java/C#. Более того, как я тебе уже не раз показал, у C++ имеется в наличие абсолютно такой же инструмент (разве что нет предустановленной запускалки llvm кода на винде), причём с гораздо большей эффективностью.
lpd>К этому списку я бы добавил наличие проработанных фреймворков веб-приложений. Единственное принципиальное преимущество байт-кода в этом списке — только переносимость между разными ОС.
Бррр, ты похоже снова не в курсе базовых принципов. Байт-код даёт переносимость между разными процессорными архитектурами. А переносимость между разными ОС даёт наличие стандартных библиотек, собранных под данную платформу. Именно это и реализует wine под линухом. Или вот новая реализация подсистемы линуха в windows10.
lpd>У нас по сути всего 2 ОС, поэтому отсутствие перекомпиляции — не столь большое преимущество.
Что за 2 ОС?
lpd>Возникает вопрос(единственный существенный в данном случае), стоит ли ради этого вносить промежуточный уровень байткода между бинарником и исполнением программы? Именно к этому вопросу, как я считаю, выбор между C#/Java и C++ и сводится.
И такой вывод после такой долгой и информативной дискуссии? Мда, печально наблюдать, как все твои усилия ушли в никуда... (
S>>Среда выполнения .NET Native не включает JIT-компилятор. В результате все необходимые машинные коды должны быть созданы заранее. Используется набор эвристических правил, чтобы определить, какой код должен создаваться, но они не могут охватывать все возможные сценарии метапрограммирования. Таким образом, необходимо предоставить подсказки для этих сценариев метапрограммирования с помощью директив среды выполнения. Если необходимые метаданные или код реализации недоступны во время выполнения, приложение вызывает исключение MissingMetadataException, MissingRuntimeArtifactException или MissingInteropDataException. Существуют два средства устранения неполадок, создающие соответствующую запись для файла директив среды выполнения, который устраняет исключение.
_>Пока ничего не понял из этой цитаты. Ты вот лучше поясни мне на конкретных примерах (если уже сам разобрался). Вот скажем сейчас для работы обычной рефлексии в .net необходимо резервирование дополнительной памяти (что не только приводит к перерасходу памяти приложением, но и к замедлению его работы) для метаинформации. Причём это происходит даже если вообще не пользоваться самой рефлексией. Так вот как обстоят дела с этим в .NET Native? Есть оно или нет? Или где-то есть, а где-то нет?
В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
_>Да, и отдельно интересно как этим коррелируют библиотеки ориентированные на использование рефлексии (а таких же полно). Просто кидают это самое исключение? )
Да.
_>>>P.S. Сборка вебкита под виндой — это весьма увлекательный квест. ))) Я помнится его когда-то проходил (причём ещё хотел всё сделать именно в своём окружение) и впечатления до сих пор яркие. ))) S>> Вот и мне плохо. При этом, что я С++ знаю постольку поскольку.
_>Угу, и сразу взялся за то, от чего шарахаются даже матёрые C++'ки. Смело. )
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>К этому списку я бы добавил наличие проработанных фреймворков веб-приложений. Единственное принципиальное преимущество байт-кода в этом списке — только переносимость между разными ОС.
_>Бррр, ты похоже снова не в курсе базовых принципов. Байт-код даёт переносимость между разными процессорными архитектурами. А переносимость между разными ОС даёт наличие стандартных библиотек, собранных под данную платформу. Именно это и реализует wine под линухом. Или вот новая реализация подсистемы линуха в windows10.
От ОС зависит также формат бинарного файла и системные вызовы, если не требовать прослоек. Кроме того, я говорю о том, что практически используется сейчас на десктопе:
lpd>>У нас по сути всего 2 ОС, поэтому отсутствие перекомпиляции — не столь большое преимущество.
_>Что за 2 ОС?
Имею ввиду Windows и Linux. Еще в некоторой степени MacOS. Переносимость Java сейчас используется именно для запуска на этих ОС, а не для запуска приложений на Arm или других процессорах, которые на десктопе редки.
lpd>>Возникает вопрос(единственный существенный в данном случае), стоит ли ради этого вносить промежуточный уровень байткода между бинарником и исполнением программы? Именно к этому вопросу, как я считаю, выбор между C#/Java и C++ и сводится.
_>И такой вывод после такой долгой и информативной дискуссии? Мда, печально наблюдать, как все твои усилия ушли в никуда... (
Я говорю не об отличиях между современными Java/C# и C++, а между возможными языками с байткодом и без — т.е. о принципиальных отличиях. Наверное, мне следовало это лучше выделить в моем сообщении. Все остальные преимущества могут быть ликвидированы развитием C++ или созданием другого языка без байткода.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
S> В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Всё равно не понятно пока. В .Net Native будет работать например автоматическая сериализация класса (оно же сейчас через рефлексию работает) или нет? Если да, то как (будет хранение метаданных рядом с объектом или нет)?
_>>Угу, и сразу взялся за то, от чего шарахаются даже матёрые C++'ки. Смело. ) S> Ну как бы жалко, что пропадает Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux S> 1С как то этим не заинтересовалась, хотя там огромные проблемы с тем же офисом 1С, Linux, Excel, Word, OpenXML,ADO и Net Core S> Но подумалось раз для декстопов .Net Core нет GUI, то можно использовать классы .Net из JavaScript и обратно.
Предлагаю тебе всё же начать работать с CEF. Он уже собранный под винду и при этом все нужные внутренности полностью доступны через удобное C++ API. В том числе и вызовы между нативным и JS кодом.
Здравствуйте, lpd, Вы писали:
_>>Бррр, ты похоже снова не в курсе базовых принципов. Байт-код даёт переносимость между разными процессорными архитектурами. А переносимость между разными ОС даёт наличие стандартных библиотек, собранных под данную платформу. Именно это и реализует wine под линухом. Или вот новая реализация подсистемы линуха в windows10. lpd>От ОС зависит также формат бинарного файла и системные вызовы, если не требовать прослоек. Кроме того, я говорю о том, что практически используется сейчас на десктопе:
Вот системные вызовы — это и есть набор библиотек. ) Ну а формат файла — это вообще ерунда. Кстати, тот же пример MS (засунувший в exe байт-код .net'a) это прекрасно демонстрирует.
_>>Что за 2 ОС? lpd>Имею ввиду Windows и Linux. Еще в некоторой степени MacOS. Переносимость Java сейчас используется именно для запуска на этих ОС, а не для запуска приложений на Arm или других процессорах, которые на десктопе редки.
Ааа, ну если ты говоришь только про декстоп (сейчас уже не самое главное направление развития), то там возможно и две... Причём это скорее Windows и OSX. А Линух тут вообще на уровне стат.погрешности — инструмент гиков.
lpd>Я говорю не об отличиях между современными Java/C# и C++, а между возможными языками с байткодом и без — т.е. о принципиальных отличиях. Наверное, мне следовало это лучше выделить в моем сообщении. Все остальные преимущества могут быть ликвидированы развитием C++ или созданием другого языка без байткода.
Ещё раз повторяю — нет такого принципиального отличия. ))) И у C++ есть байт-код (только используется не так широко). И у .Net есть компиляция в машинные коды (как раз сейчас развивают данное направление). Ключевые отличие в других местах, а это так, ерунда.
Re[30]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, itslave, Вы писали:
EP>>Не проходи мимо, загляни в форум .NET, пройдись например по первым десяти темам и посчитай в скольких из них "не нужна производительность, даже забесплатно" I>Заглянул I>Image: 22c5525c2f.png I>Какой из них про перфоманс?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>Я говорю не об отличиях между современными Java/C# и C++, а между возможными языками с байткодом и без — т.е. о принципиальных отличиях. Наверное, мне следовало это лучше выделить в моем сообщении. Все остальные преимущества могут быть ликвидированы развитием C++ или созданием другого языка без байткода.
_>Ещё раз повторяю — нет такого принципиального отличия. ))) И у C++ есть байт-код (только используется не так широко). И у .Net есть компиляция в машинные коды (как раз сейчас развивают данное направление). Ключевые отличие в других местах, а это так, ерунда.
Раньше наличие/отсутствие байткода было существенным отличием между этими языками. Мне все-таки повсеместное использование байткода вместо машинных инструкций не нравится. Однако, мне ясно то, под каким углом ты на это смотришь, и твоя точка зрения. Именно чтобы понять причину популярности C#/Java(и байткода) я и вел обсуждение.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
EP>>Встречается часто, и вносят значительный вклад, но для типичных корпоративных "операционных дней" и "всё в базу упирается" это действительно не критично. I>Да если бы оперднями все ограничивалось I>Зайди на любой веб сайт — там тоже "все в базу и хттп упирается". \
Это всё такой же опердень — база и формочки, только на другой технологической платформе. Задачи крайне типовые — CMS, форумы/соц.сети, склады, онлайн-магазины, да прочий документооборот — отсюда и появляются типовые инструменты класса LightSwitch, SharePoint, типовые CMS, 1С, Access и прочий CRUD.
Причём здесь если смотреть на объёмы и прочие проценты, вполне может оказаться что лидером является какой-нибудь PHP, и прочие Ruby с JS'ами
I>А если нужен то проще сделать длл-ку дял критического куска и прикрутить ее к управляемому решению
Так так и поступают, только в качестве клея частенько берут выразительные и гибкие языки типа Python'а
S>> В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
S>> Поэтому для рефлексии в .Net Native Нужно указать какие сборки будут использоваться для рефлексии S>>https://msdn.microsoft.com/ru-ru/library/dn600639(v=vs.110).aspx
_>Всё равно не понятно пока. В .Net Native будет работать например автоматическая сериализация класса (оно же сейчас через рефлексию работает) или нет? Если да, то как (будет хранение метаданных рядом с объектом или нет)?
Да но только по тем которые будут указаны и будут включены в сборку и по ним будет информация. Сериализация и метаданные
Если ваше приложение сериализует и десериализует объекты, может потребоваться добавить записи в файл директив среды выполнения (. rd.xml) файл, чтобы гарантировать наличие необходимых метаданных во время выполнения. Существует две категории сериализаторов, и каждый требует различной обработки в файла директив среды выполнения:
• Сериализиторы сторонних поставщиков на основе отражения. Они требуют изменений в файле директив среды выполнения и рассматриваются в следующем разделе.
• Сериализиторы без отражения содержатся в библиотеке классов платформы .NET Framework. Они могут потребовать внесения изменений в файл директив среды выполнения и обсуждаются в разделе Сериализаторы Microsoft.
_>>>Угу, и сразу взялся за то, от чего шарахаются даже матёрые C++'ки. Смело. ) S>> Ну как бы жалко, что пропадает Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux S>> 1С как то этим не заинтересовалась, хотя там огромные проблемы с тем же офисом 1С, Linux, Excel, Word, OpenXML,ADO и Net Core S>> Но подумалось раз для декстопов .Net Core нет GUI, то можно использовать классы .Net из JavaScript и обратно.
_>Предлагаю тебе всё же начать работать с CEF. Он уже собранный под винду и при этом все нужные внутренности полностью доступны через удобное C++ API. В том числе и вызовы между нативным и JS кодом.
А можно поподробнее. Я в этом лузер. Буду премного благодарен.
и солнце б утром не вставало, когда бы не было меня
_>Всё равно не понятно пока. В .Net Native будет работать например автоматическая сериализация класса (оно же сейчас через рефлексию работает) или нет? Если да, то как (будет хранение метаданных рядом с объектом или нет)?
Если вызвать конструктор этих классов сериализации и использовать ключевое слово C# typeof за пределами выражения, предоставленного для параметра Typeконструктора, как в следующем коде, компилятор .NET Native не может разрешить тип:
Type t = typeof(DataSet);
XmlSerializer ser = new XmlSerializer(t);
В этом случае необходимо указать тип в файле директив среды выполнения, добавив следующую запись:
<Type Name="DataSet" Browse="Required Public" />
Аналогичным образом, если вызвать конструктор XmlSerializer.XmlSerializer(Type, Type[]) и предоставить массив дополнительных объектов Type для сериализации, как показано в следующем коде, компилятору .NET Native не удается разрешить эти типы.
XmlSerializer xSerializer = new XmlSerializer(typeof(Teacher),
new Type[] { typeof(Student),
typeof(Course),
typeof(Location) });
Необходимо добавить следующие записи для каждого типа в файл директив среды выполнения:
<Type Name="t" Browse="Required Public" />
Информацию о синтаксисе, используемом в примере, см. в разделе Элемент <Type> (машинный код .NET).
То есть не покатит как раньше. Нужна полная информация по типам.
Кроме того .NET Native не позволяет выполнить отражение через закрытые члены библиотеки классов платформы .NET Framework. Например, вызов свойства TypeInfo.DeclaredFields для извлечения полей типа библиотеки классов платформы .NET Framework возвращает только открытые или защищенные поля.
Здравствуйте, Serginio1, Вы писали:
_>>Предлагаю тебе всё же начать работать с CEF. Он уже собранный под винду и при этом все нужные внутренности полностью доступны через удобное C++ API. В том числе и вызовы между нативным и JS кодом. S> А можно поподробнее. Я в этом лузер. Буду премного благодарен.
Скачиваешь здесь http://opensource.spotify.com/cefbuilds/index.html нужный тебе вариант. Там главное набор dll (там внутри как раз тот самый уже собранный ужас, который ты пытался собрать сам — их надо положить в дистрибутив твоего приложения), плюс lib и h файлы, которые подключаешь к своему проекту. И дальше используешь довольно удобное API (там есть два варианта: C и C++; если использовать более удобный C++, то надо ещё отдельно подключить в проект его) для работы с теперь встроенным в твоём приложение полноценным браузером. Подробности использования надо конечно смотреть в документации http://magpcss.org/ceforum/apidocs3/, а введение можно глянуть тут https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage. Но в самом начале проще всего открыть их "Sample Application" — это по сути полноценный браузер, написанный в несколько строк с помощью этой библиотеки. )
