OberonCore

Нет, на Delphi. Задача вычислительная, скорость нужна, а с С, С++ не дружу я.
По отношению к Оберону, пока я только сочувствующий.

Спасибо за ответ. Я спросил, потому что есть мнение (и в частности, мой личный опыт), что на Обероне риск допустить мелкую ошибку или опечатку стремится к нулю. И отладчик для поиска таких вещей как бы и не нужен становится. Ну и когда продерусь через компилятор и трапы, то это значит, что программа будет работать правильно и стабильно.

Может быть, всего-навсего было ещё не время. Момент не настал.

Вспомнил случай. Захотел сделать проект для плис - быстрое преобразование Фурье с плавающей запятой. Промучался пару недель в свободное пока написал блоки с плавающей запятой. Потом писал автомат управления. Вся система вместе синтезировалась на Celeron1,7ghz за 40 минут. Так что конечно отлаживалось все по отдельности). Зато очень интересно работать с нуля.
Но должен признаться в C++Builder-е пользуюсь методом проб просто потому что объем стандартных вещей настолько велик, что знаешь только те компоненты которые часто используешь. И чтобы понять как работает та или иная вещь просто вынуждено так делаешь.

Именно поэтому набор стандартных средств должен быть небольшим, но таким, чтобы с его помощью можно было довольно быстро собрать необходимое.

Ага! См. диссер Франца и SDE!!!

Но не настолько небольшим, чтобы программист должен был писать стандартную сортировку или стек.
Это уже перебор.

Кстати, я сейчас при переводе DieHard на ББ ощущаю себя как в смирительной рубашке. Того нет, этого нет, для этого нужно придумать способ...
Я, конечно, все преодолею.
И потом напишу свои впечатления.
Постараюсь написать в виде достоинств и недостатков.

Не, лично для меня перебор - это когда тривиальный список надо с нуля колбасить

Согласен!
Ни одного стандартного динамического контейнера - это перебор с минимизацией.

При чем здесь минимизация?? Чего минимизация?

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

Делать библиотеку для простого списка???

Простой список каждый раз изобретать???

Не изобретать каждый раз, а записывать каждый раз. Как a+b, IF...THEN ...ELSE ...END и т.п.

У нас разные понятия о простоте и наглядности записи Для меня принципиально иметь единую форму одной и той же простой вещи:

A не кучу вариаций на тему:

У нас разные понятия понятия о приложимости, так сказать, простоты. Для Вас важно иметь более простую (=короткую) запись. Для меня важно использовать более простой (=надёжный) инструмент. А реализации списков читаются/пишутся (после определённого ур. привыкания) как a+b. Без какого-либо напряжения мозга.

Стандартные контейнеры - это, конечно, вещь нужная... когда нет хорошей базы данных. А может, не ковыряться с этими полуфабрикатами (к которым я бы отнес даже массивы), а просто встроить в систему программирования компактную СУБД? И, кстати, воспользоваться замечательными построителями функций и построителями запросов а-ля MS Access.

(Не надо только мне рассказывать, что есть такой замечательный язык SQL - между ним и Обероном стоит Китайская стена стена, которую стоило бы разрушить.)

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



Ну напишите сходу вставку в двусвязный список... На a + b ну никак не будет похоже. Хотя, наверное, после 10 раза можно и на автомате... А потом долго искать багу Как при таком подходе можно упоминать "надежность" - не понимаю

Если оставить в стороне спорный вопрос встраивания в язык.. (тут ведь можно и не библиотеку, а просто генеративное решение надстроить, не трогая язык)..

То тут хороший пример - Cache (MUMPS). Простой, как два пальца, но такой же универсальный (с точки зрения информационных систем, конечно) движок данных под языком - многомерные разрежённые кубы, индексируемые ключами... Швейцарцы в Композите, между прочим, пошли в этом же направлении. Выкинули указатели, но дали такие вот массивчики.

Ещё вроде SQLite неплох, как встраиваемая СУБД. 300 Кб ДЛЛ, и всё внутри - то, что надо.

При таком подходе надёжность зависит только от меня. Просто беру и пишу какой мне надо список: односвязный/двусвязный; с заголовком/без; циклический/не циклический.

При Вашем (берём конкретно Си++ и шаблоны) она дополнительно зависит от
1) Реализации компилятора очень сложного языка, который постоянно развивается.
2) Реализации библиотеки шаблонов. Не смотря на всю простоту списков, реализованы они в STL совсем не просто. Т.к.
а) Учитываются особенности поддержки стандарта и различных фич компиляторами. Библиотека кросскомпиляторная, если так можно сказать
б) Заложены (закладываются) по макс. оптимизации на все случаи жизни.
в) В Си++ нет сборки мусора

А что, действительно в ББ фреймворке нет никаких стандартных стеков или контейнеров? Где-нибудь в Containers, Views или Stores? Составные документы это же тоже контейнеры?