Сообщение Re[7]: Delphi и велосипедирование от 30.06.2024 13:46
Изменено 30.06.2024 15:50 Sinclair
Re[7]: Delphi и велосипедирование
Здравствуйте, swame, Вы писали:
S>За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк:
Повторюсь: сортировать бывает нужно не только строки.
S>1. по алфавиту
S>2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9.
Вам повезло — попались непридирчивые заказчики. А как насчёт отсортировать строки по "похожести" на заданный образец (дистанция Левенштейна)?
Как насчёт case-sensitive vs case-insensitive? Как насчёт понизить приоритет whitespace, чтобы при сортировке "Иванов А.А." шёл рядом с "Иванов А. А." и с " Иванов А."?
Что будем делать с альтернативными представлениями Unicode? Ну, то есть вы же в курсе, что буква "ё" может быть как одним code point, так и двумя — и крайне желательно, чтобы оба варианта шли в выводе сортировки рядом друг с другом.
S>Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
S>Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
Давайте посмотрим на сигнатуру вашей библиотечной функции. Ну, чтобы понять, насколько она проста и неуродлива в использовании. Она же, наверное, подходит для всего — для TStringList, для array of string,
а также для любой массивоподобной коллекции произвольного типа (object там или class), у которого есть произвольное строковое свойство, по которому и будем сортировать, да?
S>Это не-из за того, что компилятор плохой, а потому что такой код в принципе требуют намного более сложных структур при компиляции,
S>это время компиляции и память.
S>код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
Стоимость памяти пренебрежимо мала по сравнению с зарплатой программистов. Так что пока компилятор пережёвывает такие структуры достаточно быстро, чтобы не нарушать цикл разработки, на потребление памяти можно смело забить.
Из строготипизированных языков с поддержкой таких штук я имел опыт с C#. Так вот — такой примитив его вообще не напрягает. Проект среднего размера собирается единицы секунд (и это на вполне себе средненькой машине разработчика, а не на выделенном сборочном сервере). Если Delphi делает это заметно медленнее (что было бы странно), то это как раз и порождает вопросы к языку, а не к подходу.
S>За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк:
Повторюсь: сортировать бывает нужно не только строки.
S>1. по алфавиту
S>2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9.
Вам повезло — попались непридирчивые заказчики. А как насчёт отсортировать строки по "похожести" на заданный образец (дистанция Левенштейна)?
Как насчёт case-sensitive vs case-insensitive? Как насчёт понизить приоритет whitespace, чтобы при сортировке "Иванов А.А." шёл рядом с "Иванов А. А." и с " Иванов А."?
Что будем делать с альтернативными представлениями Unicode? Ну, то есть вы же в курсе, что буква "ё" может быть как одним code point, так и двумя — и крайне желательно, чтобы оба варианта шли в выводе сортировки рядом друг с другом.
S>Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
S>Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
Давайте посмотрим на сигнатуру вашей библиотечной функции. Ну, чтобы понять, насколько она проста и неуродлива в использовании. Она же, наверное, подходит для всего — для TStringList, для array of string,
а также для любой массивоподобной коллекции произвольного типа (object там или class), у которого есть произвольное строковое свойство, по которому и будем сортировать, да?
S>Это не-из за того, что компилятор плохой, а потому что такой код в принципе требуют намного более сложных структур при компиляции,
S>это время компиляции и память.
S>код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
Стоимость памяти пренебрежимо мала по сравнению с зарплатой программистов. Так что пока компилятор пережёвывает такие структуры достаточно быстро, чтобы не нарушать цикл разработки, на потребление памяти можно смело забить.
Из строготипизированных языков с поддержкой таких штук я имел опыт с C#. Так вот — такой примитив его вообще не напрягает. Проект среднего размера собирается единицы секунд (и это на вполне себе средненькой машине разработчика, а не на выделенном сборочном сервере). Если Delphi делает это заметно медленнее (что было бы странно), то это как раз и порождает вопросы к языку, а не к подходу.
Re[7]: Delphi и велосипедирование
Здравствуйте, swame, Вы писали:
S>За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк:
Повторюсь: сортировать бывает нужно не только строки.
S>1. по алфавиту
S>2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9.
Вам повезло — попались непридирчивые заказчики. А как насчёт отсортировать строки по "похожести" на заданный образец (дистанция Левенштейна)?
Как насчёт case-sensitive vs case-insensitive? Как насчёт понизить приоритет whitespace, чтобы при сортировке "Иванов А.А." шёл рядом с "Иванов А. А." и с " Иванов А."?
Что будем делать с альтернативными представлениями Unicode? Ну, то есть вы же в курсе, что буква "ё" может быть как одним code point, так и двумя — и крайне желательно, чтобы оба варианта шли в выводе сортировки рядом друг с другом.
S>Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
S>Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
Давайте посмотрим на сигнатуру вашей библиотечной функции. Ну, чтобы понять, насколько она проста и неуродлива в использовании. Она же, наверное, подходит для всего — для TStringList, для array of string,
а также для любой массивоподобной коллекции элементов произвольного типа (object там или class), у которого есть произвольное строковое свойство, по которому и будем сортировать, да?
S>Это не-из за того, что компилятор плохой, а потому что такой код в принципе требуют намного более сложных структур при компиляции,
S>это время компиляции и память.
S>код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
Стоимость памяти пренебрежимо мала по сравнению с зарплатой программистов. Так что пока компилятор пережёвывает такие структуры достаточно быстро, чтобы не нарушать цикл разработки, на потребление памяти можно смело забить.
Из строготипизированных языков с поддержкой таких штук я имел опыт с C#. Так вот — такой примитив его вообще не напрягает. Проект среднего размера собирается единицы секунд (и это на вполне себе средненькой машине разработчика, а не на выделенном сборочном сервере). Если Delphi делает это заметно медленнее (что было бы странно), то это как раз и порождает вопросы к языку, а не к подходу.
S>За 40 лет программирования мне понадобилось ровно 2 вида сортировки строк:
Повторюсь: сортировать бывает нужно не только строки.
S>1. по алфавиту
S>2. по числовым, там где строки имеют одинаковое начало и сисловые части, типа 10 должно следовать после 9.
Вам повезло — попались непридирчивые заказчики. А как насчёт отсортировать строки по "похожести" на заданный образец (дистанция Левенштейна)?
Как насчёт case-sensitive vs case-insensitive? Как насчёт понизить приоритет whitespace, чтобы при сортировке "Иванов А.А." шёл рядом с "Иванов А. А." и с " Иванов А."?
Что будем делать с альтернативными представлениями Unicode? Ну, то есть вы же в курсе, что буква "ё" может быть как одним code point, так и двумя — и крайне желательно, чтобы оба варианта шли в выводе сортировки рядом друг с другом.
S>Второй вариант лежит у меня в виде единственной библиотечной функции, которая подключается 1 строчкой везде, где нужна.
S>Так что нытье про сложную и уродливую реализацию сортировки в Delphi не катит.
Давайте посмотрим на сигнатуру вашей библиотечной функции. Ну, чтобы понять, насколько она проста и неуродлива в использовании. Она же, наверное, подходит для всего — для TStringList, для array of string,
а также для любой массивоподобной коллекции элементов произвольного типа (object там или class), у которого есть произвольное строковое свойство, по которому и будем сортировать, да?
S>Это не-из за того, что компилятор плохой, а потому что такой код в принципе требуют намного более сложных структур при компиляции,
S>это время компиляции и память.
S>код который я привел генерирует 4-5 уровней вложенностей дженерики, и занимает на два порядка больше памяти в мап- файле по сравнению с обычным.
Стоимость памяти пренебрежимо мала по сравнению с зарплатой программистов. Так что пока компилятор пережёвывает такие структуры достаточно быстро, чтобы не нарушать цикл разработки, на потребление памяти можно смело забить.
Из строготипизированных языков с поддержкой таких штук я имел опыт с C#. Так вот — такой примитив его вообще не напрягает. Проект среднего размера собирается единицы секунд (и это на вполне себе средненькой машине разработчика, а не на выделенном сборочном сервере). Если Delphi делает это заметно медленнее (что было бы странно), то это как раз и порождает вопросы к языку, а не к подходу.