Здравствуйте, Serginio1, Вы писали:
S>>Только вот .NET -- это не только и не столько про конкретный набор инструкций. Или тот же GC -- это уже не часть платформы .NET? S>Например компиляция в AOT использует С++ компилятор. Там же присутствует и GC. Где там платформа .NET?
S>Все это досужие переливания из пустого в порожнее без учета исторического контекста и достигнутых результатов.
А ну вот и исторический контекст появился! То есть язык изначально не был досконально продуман?
Ок. Я вот приводил пример с TS. Опять же IL в AOT переводят в С++, затем компилруют в натив с учетом GC.
Кто мешает сделать язык, как надстройка над C++, близкий к тому же C#
Но на C# значительно приятнее программировать!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Только вот .NET -- это не только и не столько про конкретный набор инструкций. Или тот же GC -- это уже не часть платформы .NET? S>>Например компиляция в AOT использует С++ компилятор. Там же присутствует и GC. Где там платформа .NET?
S>А "там" -- это хде?
В AOT или в том же Unity для IOS
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>>Только вот .NET -- это не только и не столько про конкретный набор инструкций. Или тот же GC -- это уже не часть платформы .NET? S>>>Например компиляция в AOT использует С++ компилятор. Там же присутствует и GC. Где там платформа .NET?
S>>А "там" -- это хде? S> В AOT
АОТ -- это всего лишь Ahead of Time. Т.е. один из способов получения кода для исполнения. Вы хотите сказать, что GC присутствует только во время AOT компиляции программы, а после компиляции GC уже нет?
S>АОТ -- это всего лишь Ahead of Time. Т.е. один из способов получения кода для исполнения. Вы хотите сказать, что GC присутствует только во время AOT компиляции программы, а после компиляции GC уже нет?
За GC отвечает отдельная DLL ка. Но в коде С++ присутствует код для сборки мусора. https://learn.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation
.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.
Это относится к UWP шному .NET Native. .Native AOT должен быть таким же.
D использует сборщик мусора для управления памятью, однако возможно и ручное управление с помощью перегрузки операторов new и delete, а также с помощью malloc и free, аналогично C. Сборщик мусора можно включать и выключать вручную, можно добавлять и удалять области памяти из его видимости, принудительно запускать частичный или полный процесс сборки. Существует подробное руководство, описывающее различные схемы управления памятью в D для тех случаев, когда стандартный сборщик мусора неприменим.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>АОТ -- это всего лишь Ahead of Time. Т.е. один из способов получения кода для исполнения. Вы хотите сказать, что GC присутствует только во время AOT компиляции программы, а после компиляции GC уже нет? S> За GC отвечает отдельная DLL ка. Но в коде С++ присутствует код для сборки мусора. S>https://learn.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation
Ну вот вам и ответ. Хотя, в вашей упоротости, вы можете сказать, что эта DLL-а к .NET-у не имеет отношения.
S>Вот D тоже исплользует сборку мусора. Но никакой среды у него нет.
Так ведь речь и не про D. К тому же количество платформ, на которые портирован D, не сказать, что большое.
Ну или покажите мне отличный от HelloWorld пример программы на C#, которая была бы написана не под .NET.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>АОТ -- это всего лишь Ahead of Time. Т.е. один из способов получения кода для исполнения. Вы хотите сказать, что GC присутствует только во время AOT компиляции программы, а после компиляции GC уже нет? S>> За GC отвечает отдельная DLL ка. Но в коде С++ присутствует код для сборки мусора. S>>https://learn.microsoft.com/ru-ru/windows/uwp/dotnet-native/net-native-and-compilation
S>Ну вот вам и ответ. Хотя, в вашей упоротости, вы можете сказать, что эта DLL-а к .NET-у не имеет отношения.
Это просто дллка как в D. Она отвечает за сборку мусора. S>>Вот D тоже исплользует сборку мусора. Но никакой среды у него нет.
S>Так ведь речь и не про D. К тому же количество платформ, на которые портирован D, не сказать, что большое.
Разговор про сборку мусора! S>Ну или покажите мне отличный от HelloWorld пример программы на C#, которая была бы написана не под .NET.
Еще раз .Native AOT не использует CLR. Это чисто нативная сборка. И mrt100_app.dll это нативная библиотека. Не в .Native AOT там все в одном файле
Там как раз и пример с HelloWorld. Можно использовать на компе без .Net и размер небольшой, по сравнению с CLR
В итоге скомпилированный файл exe можно запускать на 64-разрядных Windows даже там, где не установлен .NET.
Один из главных минусов компиляции в нативное приложение — это его размер, например, как видно на скриншоте при компиляции с .NET 8.0 Preview простое консольное приложение, которое выводит на консоль строку, занимает 1793 Кб. Но стоит отметить, что по сравнению с .NET 7.0 в .NET 8.0 размер нативного приложения значительно уменьшен, и команда разработчиков .NET продолжает работать над этим, поэтому в будущем размер приложения может ужаться значительно. Кроме того, можно применять различные оптимизации. Самая простейшая — использовать инвариантный режим для параметров глобализации, для чего надо добавить в файл проекта настройку
<InvariantGlobalization>true</InvariantGlobalization>
Так, только эта настройка позволила в моем случае уменьшить размер приложения с 1793 КБ до 1567 КБ
В дополнение к большему размеру стоит отметить и некоторые другие недостатки подобной модели публикации. Прежде всего не для всех типов проектов, библиотек и сред данная модель может быть доступна. Так, поддержка консольных приложений добавлена с самого начала — в .NET 7.0. А вот для ASP.NET Core эта модель доступна только начиная с .NET 8.0. Кроме того, поддержка MacOS также добавлена толькр в .NET 8.0 (для Windows и Linux поддержка имеет уже в .NET 7)
Здравствуйте, Serginio1, Вы писали:
S>>Ну вот вам и ответ. Хотя, в вашей упоротости, вы можете сказать, что эта DLL-а к .NET-у не имеет отношения. S> Это просто дллка как в D. Она отвечает за сборку мусора.
Вы не понимаете, что наличие такой DLL-ки и есть та самая песочница, которая вам обеспечена .NET-ом?
S>Еще раз .Native AOT не использует CLR.
Т.е. .NET Native -- это не .NET. Ну раз уж там нет CLR?
Здравствуйте, so5team, Вы писали:
S>>>Ну вот вам и ответ. Хотя, в вашей упоротости, вы можете сказать, что эта DLL-а к .NET-у не имеет отношения. S>> Это просто дллка как в D. Она отвечает за сборку мусора.
S>Вы не понимаете, что наличие такой DLL-ки и есть та самая песочница, которая вам обеспечена .NET-ом?
Наличие сборки мусора не делает D песочницей! S>>Еще раз .Native AOT не использует CLR.
S>Т.е. .NET Native -- это не .NET. Ну раз уж там нет CLR?
А, что по твоему есть песочница? То есть перевели в С++, скомпилировали, получили размер значительно меньше CLR, запускается без .Net
Это, что? Сборка мусора, это не CLR. Это аналог менеджера памяти, который и в C++ можно засунуть как в D
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, student__, Вы писали:
__>масса нововедений именно упрощают язык.
Это я согласен. Я больше про то, что пользователи языка стараются навертеть посильнее. Посмотрите, сколько на тут на форуме постов в стиле "я вставил шаблон в шаблон чтобы использовать шаблон пока использую шаблон — посмотрите что не так". Или "я эмулировал фичу, которой нет в языке". Вот именно что заставляет людей такое делать?
__>auto, range-based for loop, starship-operator, треды из коробки,
Это однозначно полезные фичи. Особенно что касается стандартной библиотеки.
__>это вы просто не видели кода стандартной библиотеки C++...
Видел, видел... и с отладчиком ходил. Правда, только в реализацию от MS. Не знаю, что там у gcc и других.
Здравствуйте, Serginio1, Вы писали:
S>>Вы не понимаете, что наличие такой DLL-ки и есть та самая песочница, которая вам обеспечена .NET-ом? S> Наличие сборки мусора не делает D песочницей!
Это вы от большого ума сперва говорите о песочнице, а потом...
S>>Т.е. .NET Native -- это не .NET. Ну раз уж там нет CLR? S>А, что по твоему есть песочница?
спрашиваете что это за песочница такая?
S>Это, что?
Здравствуйте, so5team, Вы писали:
S>>>Вы не понимаете, что наличие такой DLL-ки и есть та самая песочница, которая вам обеспечена .NET-ом? S>> Наличие сборки мусора не делает D песочницей!
S>Это вы от большого ума сперва говорите о песочнице, а потом...
Я такого не говорил! S>>>Т.е. .NET Native -- это не .NET. Ну раз уж там нет CLR? S>>А, что по твоему есть песочница?
S>спрашиваете что это за песочница такая?
S>>Это, что?
Я не знаю. Ты почему то её упомянул. S>Это то, о чем я говорил раньше
: "Тогда как для Java или C# есть песочница с некоторыми гарантиями от JVM/.NET".
S>Когда вы компилируете свой C# хоть под CLR, хоть под .NET Native, вы имеете некоторые гарантии от .NET. Одна из них -- это тот самый GC.
S>Но я понял, .NET Native у вас это не .NET. Все, узбагойтесь.
Когда ты скомпилируешь С++ ты получаешь некоторые гарантии так же ка и от сборщика мусора!
У вас там куча вариантов ссылок!
Но у .Net много вариантов использования CLR. В том числе и динамическая компиляция, рефлексия итд
Но вообще то речь шла об языках и их проектировании. От натива никуда не деться. В C# например нельзя наследовать структуры итд. То есть по максимуму использовать стек.
Нельзя как в том же D использовать не только сборку мусора, но и ручное управление памятью.
Но вот С++ могли бы многое взять из того же TS для упрощения написания кода и отладки.
Даже сначала в TS появились async/await который компилился в JS, а примерно года через 2 только в JS.
По мне так нужен такой язык над C++, который компилировался в C++, но использовал все парадигмы того же C#, и скрывал недостатки легаси и прочего.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, so5team, Вы писали:
S>Надо полагать именно поэтому .NET спустя два десятка лет своего безоговорочного доминирования представлен на значительно большем количестве платформ, чем C++. Или...?
Ну да, миллионы мух не могут ошибаться. Или...?
S>Завод по выпуску легковых автомобилей продуман лучше, чем горнообогатительный комбинат. S>Сравнение такого же качество.
Демагогия и попытка увести разговор в другое русло. Речь шла о вполне конкретном случае, вот его и сравнивай.
Здравствуйте, rameel, Вы писали:
S>>Надо полагать именно поэтому .NET спустя два десятка лет своего безоговорочного доминирования представлен на значительно большем количестве платформ, чем C++. Или...?
R>Ну да, миллионы мух не могут ошибаться. Или...?
А миллионы мух здесь это кто? Производители ОС или железа?
Скажем, Google для своей Фукции использует Си, C++, Rust и Dart, проигнорировав существование .NET. Можно ли считать, что это произошло потому что .NET разработчики .NET смотрели шире?
S>>Завод по выпуску легковых автомобилей продуман лучше, чем горнообогатительный комбинат. S>>Сравнение такого же качество.
R>Демагогия и попытка увести разговор в другое русло. Речь шла о вполне конкретном случае, вот его и сравнивай.
И какой же это случай, можно конкретнее?
Разговор был о том, что разработчики C# и Java имеют возможность закладываться на некоторые гарантии, которые обеспечиваются .NET-ом и JVM. В качестве примера были приведены размерности char и int. На что было сказано, что это просто потому, что C# лучше продуман.
Я здесь в упор сравнения конкретных случаев не вижу. А вот демагогию в виде "лучше продуман" вижу и не удивлен, т.к. евангелисты .NET на RSDN-е в мастерстве демагогии дадут фору кому угодно.
Здравствуйте, dmitry_npi, Вы писали:
_>Это я согласен. Я больше про то, что пользователи языка стараются навертеть посильнее. Посмотрите, сколько на тут на форуме постов в стиле "я вставил шаблон в шаблон чтобы использовать шаблон пока использую шаблон — посмотрите что не так". Или "я эмулировал фичу, которой нет в языке". Вот именно что заставляет людей такое делать?
Тогда почему ваша тема не называется "Упоротость некоторых С++-нишиков"?
Здравствуйте, so5team, Вы писали:
R>>Ну да, миллионы мух не могут ошибаться. Или...?
S>А миллионы мух здесь это кто?
Апелляция к большинству так себе аргумент.
S>Производители ОС или железа?
Производители железа используют C/C++, вовсе не потому, что он такой насквозь продуманный, просто альтернатив особо то и нет, как нет альтернатив javascript'у в браузере, вот и приходится ковырять тем, что есть.
S>Скажем, Google для своей Фукции использует Си, C++, Rust и Dart, проигнорировав существование .NET. Можно ли считать, что это произошло потому что .NET разработчики .NET смотрели шире?
Google много что делает странного, например, Go. И с каких пор гугл равно качество и правильно? И во-вторых, как это связано?
S>И какой же это случай, можно конкретнее?
Платформенно-зависимый тип безальтернативно.
S>Разговор был о том, что разработчики C# и Java имеют возможность закладываться на некоторые гарантии, которые обеспечиваются .NET-ом и JVM. В качестве примера были приведены размерности char и int. На что было сказано, что это просто потому, что C# лучше продуман.
Вот для чего примеры приведены, для того и сказано, чем C# лучше продуман в данном случае. Я не вижу здесь утверждения, что C# во всем лучше продуман, у него своих косяков хватает, и даже таких, что были заимствованы из C/C++, может и не напрямую, но все же.
S>т.к. евангелисты .NET на RSDN-е в мастерстве демагогии дадут фору кому угодно.
Какую бы фору не давали, адепты C/C++ все равно вне конкуренции)
Здравствуйте, rameel, Вы писали:
R>Апелляция к большинству так себе аргумент.
Это не ответ на вопрос. Так кого следует понимать под миллионом мух? Ведь платформы для ОС или для аппаратно-программных комплексов выбирает далеко не так много людей, если сравнивать, например, с разработкой pet-project-а в свободное время.
S>>Производители ОС или железа?
R>Производители железа используют C/C++, вовсе не потому, что он такой насквозь продуманный, просто альтернатив особо то и нет, как нет альтернатив javascript'у в браузере, вот и приходится ковырять тем, что есть.
Если у какого-то продукта есть преимущества, то этот продукт с течением времени вытесняет конкурентов. Это видно на примере того же JavaScript, который сначала должен был добавлять динамику для веб-страничек, а сейчас используется для разработки, в том числе и десктоп приложений.
Соответственно, если платформа .NET была хорошо продумана и ее разработчики смотрели куда шире, то где результаты? А если результатов нет, то может все не так однозначно?
В конце-концов программные продукты масштаба .NET создают не ради любви к искусству и не для того, чтобы показать что что-то в принципе возможно, а для достижения каких-то целей.
S>>Скажем, Google для своей Фукции использует Си, C++, Rust и Dart, проигнорировав существование .NET. Можно ли считать, что это произошло потому что .NET разработчики .NET смотрели шире?
R>Google много что делает странного, например, Go.
Go решил проблему, которая у них была.
И, как ни странно, Go пришелся ко двору еще много кому, т.к. другие сталкивались с похожими проблемами.
Можно стебаться над Go, но для своей ниши это оказался очень удачным инструментом. На удивление просто.
R>И с каких пор гугл равно качество и правильно?
Google просто как пример конторы, в которой далеко не самые глупые люди пошли на создание новой ОС. Но почему-то они не захотели повторять какой-нибудь Midori OS или Singularity.
R>И во-вторых, как это связано?
См. выше на счет того, что если у продукта есть преимущества, то эти преимущества будут эксплуатироваться.
S>>И какой же это случай, можно конкретнее?
R>Платформенно-зависимый тип безальтернативно.
OK. Т.е. нужно рассмотреть тот факт, что в C#/Java количество бит для типов вроде char и int зафиксировано и гарантировано как тот самый аспект, в котором язык (конкретно C#) продуман лучше, чем C++. Правильно я понял ваше пожелание?
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте, Went, Вы писали:
W>>Тогда почему ваша тема не называется "Упоротость некоторых С++-нишиков"?
_>Подозреваю, что-то в языке заставляет людей такое делать. Или культура использования С++ как-то поощряет такие костыли. (почему?)
Не заставляет, а позволяет. Если кто-то захотел повыделываться и написал что-то монструозное просто потому что С++ это позволяет — это не проблема языка. Если кто-то не может собрать мысли в кучку и пишет говнокод только потому что он компилируется — это не проблема языка. Если кто-то совсем не учится или не воспринимает советы и использует конструкции не по назначению — это тоже не проблема языка. Я сейчас вынужден отложить С++ и работаю над чужим проектом на C#. Так вот столько монструозного говнокода, использующего возможности языка не по назначению, я на С++ не видел за всю жизнь.
Здравствуйте, Alekzander, Вы писали:
A>>>Ага. Только вот Microsoft ещё в 90-х написала свою стандартную библиотеку (если совсем точно, то за год до степановской наркомании). S>>Ага. Только это не работало нигде больше. S>>Так что стандартной она не была просто о смысла слова "стандартный".
A>Аргумент: ошибки в комитетовском дизайне C++ (сравнительно с C#) надо простить, потому, что C++ появился намного раньше C#. A>Возражение: альтернативный майкрософтовский дизайн C++ тоже появился намного раньше C#, и даже раньше STL, который лёг в основу комитетовского дизайна, и там всё было хорошо и просто. A>Контрвозражение: э... э... щас чё-нить придумаем... а альтернативный майкрософтовский дизайн больше нигде не работал, вот!
А можно узнать, что это за альтернативный майкрософтовский дизайн?
