Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, okon, Вы писали: O>>а Winform и WPF остаются Windows specific, их исключат из .NET5 и будут отдельные сборки через nuget подключаться ?
QL>
QL>With the .NET Core 3.0 release in September 2019 we think that all *new* .NET applications should be based on .NET Core. The primary application types from .NET Framework are supported, and where we did not port something over there is a recommended modern replacement. All future investment in .NET will be in .NET Core. This includes: Runtime, JIT, AOT, GC, BCL (Base Class Library), C#, VB.NET, F#, ASP.NET, Entity Framework, ML.NET, WinForms, WPF and Xamarin.
Ответа тут нет, пока только известно что WPF например сильно зависим от платформы и не портабелен.
.NET Core же предполагает портабельность.
.NET Core is an open-source, general-purpose development platform maintained by Microsoft and the .NET community on GitHub. It's cross-platform (supporting Windows, macOS, and Linux) and can be used to build device, cloud, and IoT applications.
Поэтому крайне не понятно что означает WPF в .NET Core — отказ от "It's cross-platform" или же кроссплатформенную реализацию.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, sergeya, Вы писали:
S>Но меня смущает не отсутсвие расчитанного размера, а двойная работа — если размера буфера не хватит, придется выполнять форматирование повторно с самого начала.
Вот смотри — для базовых типов размер буфера неизвестен заранее для чисел и енумов. В обоих случаях посчитать размер буфера сопроставимо по затратам с собственно форматированием.
С другой стороны, всегда можно сделать буфер с запасом, так чтобы его хватало либо с гарантией, либо в 99.99% случаев. Поэтому ничего страшного в повторном форматировании нет.
S>Поэтому рассчитанный размер мне тоже не очень нужен. Мне больше нравится дизайн System.Text.Decoder.Convert(), который позволяет продолжить конвертацию с предыдущей точки остановки.
Ключевое отличиче — в случае конвертера объемы могут быть очень большими, заранее непредсказуемого размера. А вот в случае с TryFormat это не так и смысла переусложнять API нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Но меня смущает не отсутсвие расчитанного размера, а двойная работа — если размера буфера не хватит, придется выполнять форматирование повторно с самого начала.
НС>Вот смотри — для базовых типов размер буфера неизвестен заранее для чисел и енумов. В обоих случаях посчитать размер буфера сопроставимо по затратам с собственно форматированием. НС>С другой стороны, всегда можно сделать буфер с запасом, так чтобы его хватало либо с гарантией, либо в 99.99% случаев. Поэтому ничего страшного в повторном форматировании нет.
Это если буфер для разовой операции. А если это буфер стрингбилдера, в который последовательно добавляются подстроки, буфер будет периодически исчерпываться.
S>>Поэтому рассчитанный размер мне тоже не очень нужен. Мне больше нравится дизайн System.Text.Decoder.Convert(), который позволяет продолжить конвертацию с предыдущей точки остановки.
НС>Ключевое отличиче — в случае конвертера объемы могут быть очень большими, заранее непредсказуемого размера.
Это вряд ли. Обычно конвертируют в цикле буферами конечной длины.
НС>А вот в случае с TryFormat это не так и смысла переусложнять API нет.
Что может быть проще decimal.FormatTo(stringBuilder)?
Здравствуйте, sergeya, Вы писали:
НС>>А вот в случае с TryFormat это не так и смысла переусложнять API нет.
S>Что может быть проще decimal.FormatTo(stringBuilder)?
StringBuilder внутри аллоцирует чанки. Непубличный ValueStringBuilder хотя бы делает ротацию через ArraPool<char>.Shared.
Форматирование же в Span<T> не налагает никаких требований по выбору стратегии роста, это примитив, на основании которого можно реализовывать более высокоуровневые API по записи в StringBuilder или TextWriter.
QL>With the .NET Core 3.0 release in September 2019 we think that all *new* .NET applications should be based on .NET Core. The primary application types from .NET Framework are supported, and where we did not port something over there is a recommended modern replacement. All future investment in .NET will be in .NET Core. This includes: Runtime, JIT, AOT, GC, BCL (Base Class Library), C#, VB.NET, F#, ASP.NET, Entity Framework, ML.NET, WinForms, WPF and Xamarin.
Здравствуйте, sergeya, Вы писали:
S>Это если буфер для разовой операции. А если это буфер стрингбилдера
У стрингбилдера свой алгоритм выделения буфера, не только под TryFormat. И никто не мешает этот алгоритм написать так, чтобы промахи на примитивных типах с размером буфера были редкими.
НС>>Ключевое отличиче — в случае конвертера объемы могут быть очень большими, заранее непредсказуемого размера. S>Это вряд ли.
Это факт.
S> Обычно конвертируют в цикле буферами конечной длины.
Вопрос только в размере буфера. Одно дело полсотни байт под числеку, и другое дело мегабайты под текст.
НС>>А вот в случае с TryFormat это не так и смысла переусложнять API нет. S>Что может быть проще decimal.FormatTo(stringBuilder)?
StringBuilder прибивает гвоздями к конкретной реализации со своими особенностями.
Здравствуйте, Qbit86, Вы писали:
Q>StringBuilder внутри аллоцирует чанки. Непубличный ValueStringBuilder хотя бы делает ротацию через ArraPool<char>.Shared. Q>Форматирование же в Span<T> не налагает никаких требований по выбору стратегии роста, это примитив, на основании которого можно реализовывать более высокоуровневые API по записи в StringBuilder или TextWriter.
Да, хороший аргумент, но на моих (субьективных) весах двойное вычисление перевешивает эти плюсы.
Кстати, можно было бы сделали бы какой нибудь IStringBuilder, с возможностью выбора аллоцирующей или ротирующей реализации.
Тогда в пессимистичном сценарии будет дополнительное выделение памяти против выделения + перевычисления в исходном варианте.
Народ давно уже просить сделать ValueStringBuilder публичным.
Ну да ладно, тут можно придумывать до бесконечности ))
Нет. Не только CoreFX. Майкрософтовец (Program Manager, .NET Team) пишет первым пунктом:
Produce a single .NET runtime...
И дальше он объясняет, дескать мы в microsoft не умеем AOT-оптимизацию с помощью LLVM. Без него нас и наш сбор телеметрии Apple не пустит (шутка). Украдем ка мы это у xamarin.
Может случиться как с гитхабом — сначала интегрировались чуть чуть, а для 2019й студии так и с потрохами купили
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У стрингбилдера свой алгоритм выделения буфера, не только под TryFormat. И никто не мешает этот алгоритм написать так, чтобы промахи на примитивных типах с размером буфера были редкими.
Голословное утверждение. Я бы поверил, если бы ты привел ссылку на алгоритм или научное исследование.
НС>>>Ключевое отличиче — в случае конвертера объемы могут быть очень большими, заранее непредсказуемого размера. S>>Это вряд ли. НС>Это факт. S>> Обычно конвертируют в цикле буферами конечной длины. НС>Вопрос только в размере буфера. Одно дело полсотни байт под числеку, и другое дело мегабайты под текст.
Я конечно не знаю, какие у вас там размеры буферов, но в исходниках asp.net mvc при конвертации используется буферы в 1024 или 4096 символа.
Это всего лишь на полпорядка больше полусотни символов и на три порядка меньше упомянутых магабайтов.
НС>>>А вот в случае с TryFormat это не так и смысла переусложнять API нет. S>>Что может быть проще decimal.FormatTo(stringBuilder)?
НС>StringBuilder прибивает гвоздями к конкретной реализации со своими особенностями.
Span тоже прибивает гвоздями.
Теперь классу, вызывающему чужой TryFormat надо знать детали реализации чужого класса, чтобы выделить буфер нужного размера.
Плюс не забыть реализовать фолбэк.
Здравствуйте, Sinclair, Вы писали:
Q>>https://github.com/dotnet/corefx/blob/master/src/Common/src/CoreLib/System/Text/StringBuilder.cs S>Спасибо, я как-то так и предполагал, но хотел убедиться. То есть предполагается ровно один паттерн: пробуем втиснуться в буфер, какой бы он ни был; если не сработало — фоллбэкаемся на обычный метод с выделением. S>Варианта "скорректировать размер буфера" у нас нету, т.к. TryFormat не даёт нам информации о том, сколько места надо.
Это что-то типа TrySort? Если программист допустил ошибку в более сложном алгоритме быстрой сортировки и он падает, тогда запускается алгоритм пузырьковой сортировки, в нем меньше вероятность бага?
Здравствуйте, Sinclair, Вы писали:
Q>>https://github.com/dotnet/corefx/blob/master/src/Common/src/CoreLib/System/Text/StringBuilder.cs S>Спасибо, я как-то так и предполагал, но хотел убедиться. То есть предполагается ровно один паттерн: пробуем втиснуться в буфер, какой бы он ни был; если не сработало — фоллбэкаемся на обычный метод с выделением. S>Варианта "скорректировать размер буфера" у нас нету, т.к. TryFormat не даёт нам информации о том, сколько места надо.
Здравствуйте, Silver_S, Вы писали:
S_S> Это что-то типа TrySort? Если программист допустил ошибку в более сложном алгоритме быстрой сортировки и он падает, тогда запускается алгоритм пузырьковой сортировки, в нем меньше вероятность бага?
Ну, кстати, подобное делают — сперва запускают квиксорт, и, если он не отработал за некоторое время, прерывают и запускают более стабильный алгоритм, типа мерж сорта.
Здравствуйте, sergeya, Вы писали:
S>Да, хороший аргумент, но на моих (субьективных) весах двойное вычисление перевешивает эти плюсы.
И? Предлагаешь обсудить твои внутренние весы?
S>Кстати, можно было бы сделали бы какой нибудь IStringBuilder, с возможностью выбора аллоцирующей или ротирующей реализации.
Ты в своих проектах тоже никогда не заморачиваешься сложностью полученного на ровном месте решения?
S>Тогда в пессимистичном сценарии будет дополнительное выделение памяти против выделения + перевычисления в исходном варианте.
А заодно двойная косвенность на вызове метода интерфейса вместо прямого вызова невиртуальных методов. Ну и боксинг, если про ValueStringBuilder.
S>Ну да ладно, тут можно придумывать до бесконечности ))
Здравствуйте, sergeya, Вы писали:
НС>>У стрингбилдера свой алгоритм выделения буфера, не только под TryFormat. И никто не мешает этот алгоритм написать так, чтобы промахи на примитивных типах с размером буфера были редкими. S>Голословное утверждение. Я бы поверил, если бы ты привел ссылку на алгоритм или научное исследование.
Не не не. Голословное, это когда ты настаиваешь на том что это обязательно будет проблемой.
НС>>Вопрос только в размере буфера. Одно дело полсотни байт под числеку, и другое дело мегабайты под текст. S>Я конечно не знаю, какие у вас там размеры буферов S>, но в исходниках asp.net mvc при конвертации используется буферы в 1024 или 4096 символа.
И? Я в том же asp.net видел буфера на 1-2М.
НС>>>>А вот в случае с TryFormat это не так и смысла переусложнять API нет. S>>>Что может быть проще decimal.FormatTo(stringBuilder)? НС>>StringBuilder прибивает гвоздями к конкретной реализации со своими особенностями. S>Span тоже прибивает гвоздями.
Нет. Это, фактически, кусок базовой платформы, очень низкоуровневое API, к нему и так все прибито гвоздями, без вариантов.
S>Теперь классу, вызывающему чужой TryFormat надо знать детали реализации чужого класса, чтобы выделить буфер нужного размера.
Зачем? Тебе не детали реализации нужны, а размер результата.
S>Плюс не забыть реализовать фолбэк.
Это нормально для низкоуровнего API. Не хочешь возиться с микрооптимизациями — используй обычный Format.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Да, хороший аргумент, но на моих (субьективных) весах двойное вычисление перевешивает эти плюсы.
НС>И? Предлагаешь обсудить твои внутренние весы?
Нет, предлагаю на этом остановиться. Потому что в отличии от тебя, предпочитаю в дискуссии опираться на конкретные факты и ссылки. А здесь у меня нет подкрепленного аргумента, кроме своего опыта, что я и подчеркнул.
