OberonCore

Если мне неизменяют мои слабые познания С++, внутреннее представление std::vector<...> - массив, а не список, от сюда и результат.

Дык про массивы и шла речь:

Ну опять же, как я Вам уже отмечал, никто Вас не вынуждает ограничиваться только списками...
82 МБ в памяти. Тип Int на самом деле, похоже хранится как указатель на значение в куче, поэтому массив занимает не 40 МБт, а 80...

ну, ёлки палки, список, который [] -- встроен в язык. им удобней всего пользоваться. Причем я уверен что по сути списком оно не обязано быть ни разу. Покурю доки, попробую обосновать.

Что-то я недопонял -- Ваш список не содержит в себе значения, а только ссылку на следующий элемент -- почему на него тратится столько же памяти, как и на мой?

Речь, вероятно, о том, что при огромных массивах всё равно будут промахи в кеше и переключения контекстов всяких в ОС...

Аа! Это видимо потому же почему и в плюсах -- стандартный аллокатор аллоцирует минимум 8 байт под элемент. Т.о. у нас получается место зарезервировано для себя и ещё для вон того парня, которого на самом деле нет.

Возможно в BB используется ещё более крупный кусок по умолчанию. Mожно поэкспериментировать

А толку? Это же ж не влияет на размер массива. А про быстродействие тут никто и не говорил. Только про размер. Про память.

Кстати, а попробуйте забить оный список случайными числами. Посмотрим, сумеет ли он это оптимизировать/пожать.

В основном то речь шла о списках, элементы которых отностительно небольшие.
Служебная информация в этом случае составляет большой процент.
С большими массивами такого быть не должно.
Посмотрел на результат распределения 10 млн. integer в D7. Ни каких сюрпризов.
Поискал в сети, похоже, что служебная информация занимает 4 байта, плюс, блоки выравниваются на границу 4 байта.
Ни каких увеличений в разы.
Скорее уж это не магия С++ или D7, а особенности BB.

Да я и не собираюсь так уж экстраполировать. Но всё равно, ситуация показательная:
1. Пример ТРИВИАЛЬНЫЙ.
2. Первое, интуитивное его решение на MAINSTREAM компиляторе не слабо засветившегося ФП языка, выдаёт ошибку.
3. Для ликвидации ошибки требуется глубокие знания языка и модификация решения в МЕНЕЕ простую форму.

Вывод: это острый камушек в огород ФП.
А на "кривую рожу" императива "пенять" не надо, ибо известно, что импратив - зло, но придёт светлое царствие ФП, простое и безпроблемное

Как интересно... Программа собранная jhc банально зацикливается при попытке вывести last. Причем похоже вне зависимости от размеров списка.

Ну есть и более простая форма, и вообще нужно изучать стандартную библиотеку -- со стандартной функицией length никаких проблем нет!

Как так? даже для списка из нескольких элементов?

Даже для списка из двух элементов заданых явно. Т.е. [1,2]
Для списка из одного элемента проблем нет
Видать что-то они там совсем жестко наоптимизировали. Надыть будет багрепорт накатать.

Сейчас попробую UHC собрать и потестить на этих задачках.

Гм. Что-то не собирается UHC...
Завтра накатаю жалобу разработчикам

Ужасно, ужасно всё это. Я вот попробовал на интерпретаторе YHC -- 100 тыс элементов проканало, на миллионе интерпретатор упал -- памяти, говорит, не хватает, нужно 32 кБт, а доступно только 30. И это на двух гигах ОЗУ...

Получается, что программист должен
1) обязательно знать про указанную особенность компилятора
2) знать про хвостовую рекурсию и форсирование вычислений
3) знать стандартную библиотеку
4) в случае аналогичного, но сложного примера "увидеть" потенциальную проблему.

Очень, очень просто!
Как не сделать ошибку? Просто нужно всё знать и понимать и не делать ошибок!

Прокол это, локальный, но прокол. И это надо признать.

Я-то думал, и правда так. Проверил. Алексей, что-то Вы путаете.