OberonCore

Ага, если бы vector<int> в STL тоже делался с "всего-то одним лишним уровнем косвенности", то его популярность бы сильно поубавилась...
Дело в том, что для динамических объектов дженерики как раз не сильно нужны - там можно себе позволить задействовать ОО-полиморфизм и т.п. Хочется дженериков для построения библиотеки базовых алгоритмов, работающих с любыми типами, начиная с атомарных - и без оверхеда. С оверхедом я вам и без дженериков напишу общий алгоритм - через метапрограммирование можно работать как угодно и с чем угодно...

Я и сам напишу, и с мета, без мета. Потому их и не использую. Но хочется иногда себе жизнь чуть чуть упростить, для самых примитивов, чтоб меньше писанины, но только для них! никих STL!

Правда в жизни так не бывает: есть инструмент - будут пользоваться.

Ну да

Вон в ББ нет стандартной алгоритмической-контейнерной библиотеки - и ничего, вполне себе все нормально. Когда надо, пишется с полпинка и не особенно напрягает. Но я понимаю, что это нормально для меня - системщика! А при продвижении ББ в написание типового бизнес-ПО стандартной прикладной библиотеки ох как нехватать будет народу... Особенно разбалованному народу...

Как связаны системное программирование и необходимость каждый раз писать связный список или бинарный поиск?

У "системщика", обычно, контейнеры бывают весьма специфические. Их в любом случае придётся каждый раз писать самому. Например, позавчера мне понадобилась некая особая смесь хэштаблицы со списком, а использовать вместо неё два стандартных контейнера: хештаблицу и список в силу "системности" задачи было бы неоправданным оверхедом по памяти и производительности. У "прикладника" такой оверхед - нормальное явление.

А в процентном соотношении какова доля специфических контейнеров и обычных? И уж конечно системщики никогда не пишут "обычный" поиск, каждый раз специфический?



А что за системная задача такая, в двух словах можно описать?

Написание этого самого "особого поиска" - 10 секунд времени и 3 строчки кода...

Кстати, в качестве стандартного контейнера можно использовать массив переменной длины - SetLength начиная с Service Pack 4 я ввел. Можно и алгоритмы обобщенные написать для массивов - есть возможность описать процедуру, принимающуюю указатель на любой массив с любым базовым типом (как SetLength). Лично я этим практически не пользуюсь, но интересно - кто-то SetLength пользует? Если пользует, давайте помозгуем о небольшой библиотечке алгоритмов...

Все мои контейнеры специфичные. Однако, иногда, конечно, внутри них используются стандартные generic контейнеры. Я пишу ядро дотнетной части VoIP системы ( http://www.mera.ru/products/siprise.html ) и всё тут должно работать быстро и есть очень мало памяти. Там на сайте указаны технические характеристики ~ 5000 абонентов, на самом деле мне уже тут удалось оптимизировать ядро на столько что можно обслуживать абонентов на порядок больше (40'000). В перспективе, хотелось бы обслуживать до 2-3 миллионов абонентов (это уже конечно с использованием целого кластера персональных компьютеров).

Понятно. Значит все-таки стандартные контейнеры и алгоритмы нужны и для системного программирования, просто их нельзя реализовать в удобном для использования виде.

Почему тогда .NET? Небезопасность C/C++ нивелирует меньшие требования к памяти?

Оверхед вроде был бы и небольшой - но когда вместо точной реализации будет использоваться "приближенно подходящая" из библиотеки - и так в тысячах мест системы... И мизерный в отдельном случае оверхед множится на эту тысячу мест. Вот и стартует Дельфа и Студия больше минуты на новых процессорах, а Блэкбокс и на 486-м летает до сих пор...

По чисто экономическим соображениям. Разработка на дотнете существенно быстрее, дешевле и предоставляет куда большие возможности в плане алгоритмической сложности чем на C++ (на С++ замучаешься отлаживать, потеряешь кучу времени, да и реальным специалистам по С++ нужно кучу денег платить). У нас система комбинированная. Фиксированная часть отвечающая за переключение и конвертацию медиа-потоков написана на C++. Масштабируемая часть отвечающая за бизнес логику работы системы - на дотнете. В параллельном нашему проекте вместо дотнета для тех же самых целей что и мы используют Питон, он им больше нравится. Но там бизнес логика не такая серьёзная и масштабируемая как у нас.

Вообще пользуем, удобная штука.

А повторно используемый набор алгоритмов не пробовали выделять?

И эта бизнес логика должна работать очень быстро и есть мало памяти?

Без дженериков в этом смысла особого нет. Потому что в случае часто используемых неспециализированных алгоритмов скопипастить будет проще, чем "повторно использовать".

Ну, это уже мечта...

Идея в том, что есть некий фрэймворк (ядро) в среде которого запускаются "сервисы" бизнес логики. Вот это вот ядро должно работать очень быстро и есть мало памяти.

Я имею в виду алгоритмы на массивах. КП в реализации Блэкбокса позволяет писать процедуру, принимающую любой указатель - например, на массив любого базового типа (SYSTEM.PTR) и выяснять, что это за массив и из скольки элементов какого типа он состоит.

Массив элементов базовых типов - это очень сильное ограничение. На практике обычно используются динамические последовательности из элементов пользовательского типа.

Да особо нет, кроме матричных преобразований для 3d-графики, и какие-то геометрические вычисления.
Но сейчас вытанцовывается некая обобщённая конструкция пользовательского интерфейса к БД — кстати, как раз там и динамический массивчик с SetLength используем.



Я шаблонов накушался в Clarione, на всю оставшуюся жизнь — как-то и без них прекрасно живётся.