Сообщение Re[4]: Почему в C# не любят кастомные операторы? от 20.01.2023 10:12
Изменено 26.01.2023 17:02 VladD2
Re[4]: Почему в C# не любят кастомные операторы?
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Baiker, Вы писали:
B>>>stringBuilder — это вообще позорное пятно библиотеки — наглядный пример безалаберности разрабов. Не умеете компилировать в быстрый код — вообще не беритесь за языки.
G>>А были какие-то вариант? Во времена .NET1 даже генериков не было, поэтому стрингбилдер и появился.
B>Не понял связи SB и дженериков.
Подавляющая часть использования стрингбилдера в прикладных программах — склейка массива строк в одну. Для этого есть string.Join и он даже чуть быстрее работает, чем цикл в билдере. Но до .NET 3.5 примерно приходилось писать циклы и перекладывать строки из какогонить datatable в массив руками. Linq эту задачу значительно оптимизировал, появился string.Join(IEnumerable<T>) и количество использований стрингбилдера упало до нормального уровня.
G>> Сейчас он не нужен от слова совсем.
B>ВОТ! Про что и речь. Ума содрать жабу и выдать за C# — хватило, а написать эффективный манипулятор строками — нет. Потому и позорное пятно. Да ещё и книжек с библиотеками понаписали, где юзается SB. Новичок читает и не понимает, за каким фигом для строк требуется ещё и отдельный "эффективный класс".
Нет, речь не про это. Стрингбилдер это эффективный низкоуровневый инструмент. Он всегда таким был. На некоторых сценариях он обгонял std:string из C++ еще во времена .NET 2.0
Стрингбилдер помогает когда надо генерировать текст из объектов — HTML, сериализация, кодогенерация итд. Но это в основном внутренний инструмент для разработчика фреймворка.
Для прикладной программы сейчас лучше использовать интерполяцию или string.join (ЧСХ оба внутри используют стрингбилдеры), а если надо много и быстро, то Memory<char> и ручное копирование если это подходит.
Единственное что плохо, что с самого начала .NET авторы книжек толкали идею что "строки плохо и медленно, стрингбилдер хорошо" и это тянется до сих пор. До смешного бывает: я вижу код, где вместо конкатенации трех строковых переменных люди городят стрингбилдеры.
B>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Baiker, Вы писали:
B>>>stringBuilder — это вообще позорное пятно библиотеки — наглядный пример безалаберности разрабов. Не умеете компилировать в быстрый код — вообще не беритесь за языки.
G>>А были какие-то вариант? Во времена .NET1 даже генериков не было, поэтому стрингбилдер и появился.
B>Не понял связи SB и дженериков.
Подавляющая часть использования стрингбилдера в прикладных программах — склейка массива строк в одну. Для этого есть string.Join и он даже чуть быстрее работает, чем цикл в билдере. Но до .NET 3.5 примерно приходилось писать циклы и перекладывать строки из какогонить datatable в массив руками. Linq эту задачу значительно оптимизировал, появился string.Join(IEnumerable<T>) и количество использований стрингбилдера упало до нормального уровня.
G>> Сейчас он не нужен от слова совсем.
B>ВОТ! Про что и речь. Ума содрать жабу и выдать за C# — хватило, а написать эффективный манипулятор строками — нет. Потому и позорное пятно. Да ещё и книжек с библиотеками понаписали, где юзается SB. Новичок читает и не понимает, за каким фигом для строк требуется ещё и отдельный "эффективный класс".
Нет, речь не про это. Стрингбилдер это эффективный низкоуровневый инструмент. Он всегда таким был. На некоторых сценариях он обгонял std:string из C++ еще во времена .NET 2.0
Стрингбилдер помогает когда надо генерировать текст из объектов — HTML, сериализация, кодогенерация итд. Но это в основном внутренний инструмент для разработчика фреймворка.
Для прикладной программы сейчас лучше использовать интерполяцию или string.join (ЧСХ оба внутри используют стрингбилдеры), а если надо много и быстро, то Memory<char> и ручное копирование если это подходит.
Единственное что плохо, что с самого начала .NET авторы книжек толкали идею что "строки плохо и медленно, стрингбилдер хорошо" и это тянется до сих пор. До смешного бывает: я вижу код, где вместо конкатенации трех строковых переменных люди городят стрингбилдеры.
Re[4]: Почему в C# не любят кастомные операторы?
Здравствуйте, Baiker, Вы писали:
B>Не понял связи SB и дженериков.
Подавляющая часть использования стрингбилдера в прикладных программах — склейка массива строк в одну. Для этого есть string.Join и он даже чуть быстрее работает, чем цикл в билдере. Но до .NET 3.5 примерно приходилось писать циклы и перекладывать строки из какогонить datatable в массив руками. Linq эту задачу значительно оптимизировал, появился string.Join(IEnumerable<T>) и количество использований стрингбилдера упало до нормального уровня.
B>ВОТ! Про что и речь. Ума содрать жабу и выдать за C# — хватило, а написать эффективный манипулятор строками — нет. Потому и позорное пятно. Да ещё и книжек с библиотеками понаписали, где юзается SB. Новичок читает и не понимает, за каким фигом для строк требуется ещё и отдельный "эффективный класс".
Нет, речь не про это. Стрингбилдер это эффективный низкоуровневый инструмент. Он всегда таким был. На некоторых сценариях он обгонял std:string из C++ еще во времена .NET 2.0
Стрингбилдер помогает когда надо генерировать текст из объектов — HTML, сериализация, кодогенерация итд. Но это в основном внутренний инструмент для разработчика фреймворка.
Для прикладной программы сейчас лучше использовать интерполяцию или string.join (ЧСХ оба внутри используют стрингбилдеры), а если надо много и быстро, то Memory<char> и ручное копирование если это подходит.
Единственное что плохо, что с самого начала .NET авторы книжек толкали идею что "строки плохо и медленно, стрингбилдер хорошо" и это тянется до сих пор. До смешного бывает: я вижу код, где вместо конкатенации трех строковых переменных люди городят стрингбилдеры.
B>Не понял связи SB и дженериков.
Подавляющая часть использования стрингбилдера в прикладных программах — склейка массива строк в одну. Для этого есть string.Join и он даже чуть быстрее работает, чем цикл в билдере. Но до .NET 3.5 примерно приходилось писать циклы и перекладывать строки из какогонить datatable в массив руками. Linq эту задачу значительно оптимизировал, появился string.Join(IEnumerable<T>) и количество использований стрингбилдера упало до нормального уровня.
B>ВОТ! Про что и речь. Ума содрать жабу и выдать за C# — хватило, а написать эффективный манипулятор строками — нет. Потому и позорное пятно. Да ещё и книжек с библиотеками понаписали, где юзается SB. Новичок читает и не понимает, за каким фигом для строк требуется ещё и отдельный "эффективный класс".
Нет, речь не про это. Стрингбилдер это эффективный низкоуровневый инструмент. Он всегда таким был. На некоторых сценариях он обгонял std:string из C++ еще во времена .NET 2.0
Стрингбилдер помогает когда надо генерировать текст из объектов — HTML, сериализация, кодогенерация итд. Но это в основном внутренний инструмент для разработчика фреймворка.
Для прикладной программы сейчас лучше использовать интерполяцию или string.join (ЧСХ оба внутри используют стрингбилдеры), а если надо много и быстро, то Memory<char> и ручное копирование если это подходит.
Единственное что плохо, что с самого начала .NET авторы книжек толкали идею что "строки плохо и медленно, стрингбилдер хорошо" и это тянется до сих пор. До смешного бывает: я вижу код, где вместо конкатенации трех строковых переменных люди городят стрингбилдеры.