Re[24]: Регресс производительности при переходе с FW 3.5 SP1
От: 4058  
Дата: 18.05.20 10:53
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Конечно до уровня WPF им будет далеко.


Xamarin изначально ориентировался как кроссплатформенный GUI под мобильные устройства, а там по очевидным причинам потребности существенно ниже чем к настольному.

S> Просто .Net Framework развиваться не будет. Ну по твоим 3.5, я так понимаю тебе не особо то и нужно.

S>Лет на 10 хватит

На данный момент [расширенная] поддержка FW 3.5 SP1 официально заявлена до 10.10.2028
https://support.microsoft.com/en-us/lifecycle/search/548

Другое дело, что заставят подниматься намного раньше, например если какой-нибудь новый Windows Server не будет его поддерживать, или просто планы поменяются, да еще со всех сторон слушать, о том какой я не модный, если не могу например использовать "фишки" C# 4-8.

Тут еще важно понимать, что вкладывать в термин — развитие.
По факту мне как бывшему C++-нику в 1.0/1.1 сильно не хватало хоть какой-нибудь параметризации типов, в 2.0 я получил generic-и + анонимные делегаты, nullable, в 3.0 получил лямбды, var, и вполне интересный LINQ (но тут скорее про библиотеку, а не синтаксический сахар накрученный поверх библиотеки). Это было весьма органичное развитие полезностями как библиотек, так и самого языка.
На 4.0 особо ничего не приглядел, кроме пожалуй более удобных способов для работы с многопоточностью.

Поэтому стоит выделить, раньше развитие шло для решения вполне насущных задач, а потом оно по большей части пошло ради самого процесса.
Re[25]: Регресс производительности при переходе с FW 3.5 SP1
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.05.20 12:08
Оценка:
Здравствуйте, 4058, Вы писали:

4>Тут еще важно понимать, что вкладывать в термин — развитие.

4>По факту мне как бывшему C++-нику в 1.0/1.1 сильно не хватало хоть какой-нибудь параметризации типов, в 2.0 я получил generic-и + анонимные делегаты, nullable, в 3.0 получил лямбды, var, и вполне интересный LINQ (но тут скорее про библиотеку, а не синтаксический сахар накрученный поверх библиотеки). Это было весьма органичное развитие полезностями как библиотек, так и самого языка.
4>На 4.0 особо ничего не приглядел, кроме пожалуй более удобных способов для работы с многопоточностью.

4>Поэтому стоит выделить, раньше развитие шло для решения вполне насущных задач, а потом оно по большей части пошло ради самого процесса.


Ну одних async awaite достаточно и прочих шаблонов
https://docs.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
Использую Операции с чередованием и AsyncProducerConsumerCollection (асинхронная очередь)

Сейчас паттерн матчинг, Span<>, Ссылочные локальные переменные https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/keywords/ref

итд Язык стремительно развивается.

Мне тоже приходится на 3.5 программировать и чувствуешь себя сильно зажатым
и солнце б утром не вставало, когда бы не было меня
Re[3]: [R#] Merge sequential checks and compilation error
От: Mr.Delphist  
Дата: 18.05.20 15:48
Оценка:
Здравствуйте, 4058, Вы писали:

4>Из этого следует, что переход с Unicode 5.0 (FW 3.5) на 5.1 (FW 4.0) выдаёт регресс производительности для локалезависимых операций в 2.7 раза?


...или же делает это более верно идеологически. За что приходится платить производительностью.

Вообще, тема сравнения строк — это из серии мемчиков "когда мне было 4 года, моей сестре было 2, сейчас мне 44, а сколько моей сестре?". Т.е. очевидный ответ оказывается далеко не единственно возможным, и эти прочие варианты настолько зубодробительны, что вместо функции-однострочника появляется едва ли не отдельный SDK. Одни только эмоджики чего стоят, с их расширенными атрибутами.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.