Динамические массивы

[QUOTE=VinShurikk]Плиз! Помогите.
Недавно начал разбираться с VС++ раньше писал на Delphi.
Как можно в С не очень сложно создавать динамические массивы?
Как мне освобождать из памяти конкретно этот элемент дин. массива?
Задача состоит в чем:
есть один дин. массив.(главный) В каждом элементе есть несколько параметров типа int и другой дин. массив(вложенный) координат х и у.
Мне нужно удалять и добавлять отдельно координаты и весь элемент главного массива.

Перечитал кучу инфы про распределение памяти, и.т.д.
Нашел несколько примеров создания одномерного дин. массива.
Мучался конкретно. но ничего хорошего не намучал.

Помогите плиз.
Может хоть инфы какой-то подкиньте. желательно, конечно на русском, но на англицком тоже сойдет.

Буду благодарен.[/QUOTE]
Можно воспользоваться STL, например классом vector или еще чем подобным. В MFC и в ATL полно подобных классов CArray, CList и т.д. Вообщем готовых решений дофига

Спасибо.
Буду разбираться.
Как использовать CList? или СArray? Пишет undeclared identifier.
Но при написании CList < подсказывает че писать. Тобишь он должен работать, а компилятор не узнает его... Может какуюто библиотеку подключить?

Потому что CList, CArray - это шаблоны. Требует их инстанцировать, т.е. указать конкретный тип элементов коллекций. Например так:

Вообще смотри MSDN. Там все написано.

Я уже понял, че надо. Я просто подключил
#include "afxtempl.h"
И все пашет. Но все равно спасибо.

Подключайте #include <vector>, вот образец динамического массива.
Именно массива, а не списка.;)

[QUOTE=el scorpio]Если требуется добавлять/удалять объекты в середине массива - то это уже не массив, а список :)

[/QUOTE]
ГМ...Динамический массив, с произвольным доступом, это vector и deque. А двусвязный список это list. Он, точно, дает лучшее время на paste / delete в произ. месте, но все остальное - хуже, намного, например, не поддерж. произвольный доступ. Единственно, что не обнуляются итераторы при операциях и транзакции безопасные.

Исключительно собственного образования ради :D , писал контейнеры для массивов и списков.
Список делал так: создавал массив указателей. Обращение к элементу списка реализовывалось простым алгоритмом: индексация адреса -> обращение по адресу. При вставке/удалении просто производился сдвиг части массива указателей, что соответственно, быстреее сдвига самих объектов, при размере объекта > 4 байта.
Сами объекты оставались на своих местах. Только при вставке/удалении элементов для них, соответственно, вызывались операторы new и delete.

Писать подобные реализации для себя, возможно, интересно и конечно, полезно для понимания внутреннего устройства контейнеров. Но после того как вы поняли их устройство, ИМХО намного полезнее углублять знание готовых реализаций различных элементов STL, чем писать свои, тем более что написать что-то свое с такой же функциональностью и продуманностью - это ДОЛГО:)

А я не спешу :D.

Рад за Вас:) Желаю Вам когда нибудь написать свою реализацию STL, такую, которая удовлетворит всех:) Но до того момента как ее увижу, буду считать такие попытки пустой тратой времени:D

[QUOTE=Zorkus]Рад за Вас:) Желаю Вам когда нибудь написать свою реализацию STL, такую, которая удовлетворит всех:) Но до того момента как ее увижу, буду считать такие попытки пустой тратой времени:D[/QUOTE]
Напротив, пытаться угодить всем - пустая трата времени. Создавать свою реализацию STL - тоже пустая трата времени. А вот создать оптимальный для своих целей контейнер с подстраеваемыми параметрами - не пустая трата времени, так как может сэкономить время выполнения и ресурсы.

[QUOTE=Svyatozar]Напротив, пытаться угодить всем - пустая трата времени. Создавать свою реализацию STL - тоже пустая трата времени. [/QUOTE]
Я так смотрю, шутка не удалась;)
[QUOTE=Svyatozar] А вот создать оптимальный для своих целей контейнер с подстраеваемыми параметрами - не пустая трата времени, так как может сэкономить время выполнения и ресурсы[/QUOTE]
Хм..не мог бы ты показать пример того, как тебе не хватает возможностей STL и Boost, причем настолько, что проще написать свой контейнер, чем использовать существующие решение?? Вспомни, что STL был написан с целью максимального абстрагирования от конкретной задачи.

[QUOTE=Zorkus]Хм..не мог бы ты показать пример того, как тебе не хватает возможностей STL и Boost, причем настолько, что проще написать свой контейнер, чем использовать существующие решение?? Вспомни, что STL был написан с целью максимального абстрагирования от конкретной задачи.[/QUOTE]
Не хватает. Мне нужен полный контроль распределения памяти и количества вызываемых функций для оптимизации в "узких местах" базы данных. Функции проверки должны быть внутри цикла сортировки: вызов функции для каждой проверки недопустим. Для меня эффективность важнее какой-то там сомнительной "абстрагируемости", именно поэтому я пишу на С++.

[QUOTE=Svyatozar]Мне нужен полный контроль распределения памяти [/QUOTE]
Так можно написать свой аллокатор к контейнеру.

[QUOTE=Svyatozar]Для меня эффективность важнее какой-то там сомнительной "абстрагируемости", именно поэтому я пишу на С++. [/QUOTE]
А STL разве на бейсике?:eek: Вот незадача, 3 года пишу, и не знал:(
Потом, она была написана как раз с расчетом на быстродействие, поэтому, например, в ней нету обработки внутренней многих ошибок.
И можно узнать подробнее, как потребляется такое дикое кол-во ресурсов, что за БД -то?

[QUOTE=Zorkus]Потом, она была написана как раз с расчетом на быстродействие, поэтому, например, в ней нету обработки внутренней многих ошибок.[/QUOTE]
Тише едешь, дальше [от AV] будешь (мудрость опытного программиста :D )
А мне нужна была обработка ошибок, да не просто обработка, а ещё и генерация своих сообщений, различающихся для каждого объекта.

[QUOTE=Zorkus]Так можно написать свой аллокатор к контейнеру.[/QUOTE]Это не совсем то что я имею ввиду когда говорю "полный контроль распределением памяти"... Обилие множества жестких интерфейсов создает дополнительные ограничения в оптимизации.


[QUOTE=Zorkus]А STL разве на бейсике?:eek: Вот незадача, 3 года пишу, и не знал:([/QUOTE]Вообще не понял что ты хотел этим сказать.


[QUOTE=Zorkus]Потом, она была написана как раз с расчетом на быстродействие, поэтому, например, в ней нету обработки внутренней многих ошибок.
И можно узнать подробнее, как потребляется такое дикое кол-во ресурсов, что за БД -то?[/QUOTE]Мы тут о разных вещах говорим. Что ты называешь быстродействием? Я исхожу из того что для каждой задачи есть некий оптимальный алгоритм А, и безконечное множество других решений Д. Нет такого универсального алгоритма который оптимален для всех задач! О чем и речь, собственно.

[QUOTE=Svyatozar]Это не совсем то что я имею ввиду когда говорю "полный контроль распределением памяти"... Обилие множества жестких интерфейсов создает дополнительные ограничения в оптимизации.
[/QUOTE]
Какая оптимизация имеется в виду?
На чем строиться твоя уверенность, что именно STL ограничивает тебя в этой оптимизации?

[QUOTE=Green]Какая оптимизация имеется в виду?[/QUOTE]Оптимальный алгоритм дает тот же результат что и любой другой, но при этом использует минимум ресурсов системы.
[QUOTE=Green]На чем строиться твоя уверенность, что именно STL ограничивает тебя в этой оптимизации?[/QUOTE]Я уже устал повторять. Читай тему...

[QUOTE=Svyatozar]Оптимальный алгоритм дает тот же результат что и любой другой, но при этом использует минимум ресурсов системы.
[/QUOTE]
Оптимальный алгоритм или реализация?
Оптимальность по какому критерию?
Оптимальный при каких условиях?

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

[QUOTE=Svyatozar]
Я уже устал повторять. Читай тему...[/QUOTE]
Перечитал, конкретных примеров и выкладок не нашел.
Такое впечатление, что ты просто "не умеешь их готовить", т.е. пользоваться.

[QUOTE=Green]Оптимальный алгоритм или реализация?
Оптимальность по какому критерию?
Оптимальный при каких условиях?
[/QUOTE]Я же сказал, оптимальный алгоритм. И даже дал определение понятия. Что тебе еще надо?
[QUOTE=Green]Странно, когда дело доходит до оптимальности, многие начинают мешать всё в одну кучу. Не бывает чистой, абстрактной оптимальности. Оптимальность зависит от многих факторов.[/QUOTE]
Я ничего не мешаю в кучу, напротив, четко указываю что когда речь идет об алгоритме, оптимальность сводится к минимальному использованию ресурсов системы с максимальной выдачей результатов. Ресурсы есть разные, и факторов много, кто же спорит?
[QUOTE=Green]То что оптимально для одних критериев, совершенно не оптимально при других. То, что оптимально при одних условиях (входных данных) может быть неоптимальным или даже нерабочим при других. Ты же пытаешься развить тему "обобщенной оптимальности", что чистое профанство.[/QUOTE]
Да с чего ты решил что я что-то обобщаю? Ты явно что-то вбил себе в голову!

[QUOTE=Green]Перечитал, конкретных примеров и выкладок не нашел.
Такое впечатление, что ты просто "не умеешь их готовить", т.е. пользоваться.[/QUOTE]Ты хоть и перечитал, а ничего не понял.

[QUOTE=Svyatozar]Я же сказал, оптимальный алгоритм. И даже дал определение понятия. Что тебе еще надо?
[/QUOTE]
Определение не верное, как я уже говорил. Отсюда и неверное понимание того, что (методы, приемы) помогает оптимизировать, а что - нет.
Кроме того, контейнеры - это реализация алгоритма, а не сам алгоритм.

[QUOTE=Svyatozar]Я ничего не мешаю в кучу, напротив, четко указываю что когда речь идет об алгоритме, оптимальность сводится к минимальному использованию ресурсов системы с максимальной выдачей результатов. [/QUOTE]
Оптимальному по какому критерию?
Что значит "максимальная выдача результатов"?

[QUOTE=Green]Определение не верное, как я уже говорил. Отсюда и неверное понимание того, что (методы, приемы) помогает оптимизировать, а что - нет.[/QUOTE]ну это твое личное мнение...
[QUOTE=Green]Кроме того, контейнеры - это реализация алгоритма, а не сам алгоритм.[/QUOTE]Ну это вообще какая-то туманная фраза. Например, разве STL не использует алгоритм определенный сортировки? А ведь алгоритмов сортировок много разных в зависимости от известных данных...


[QUOTE=Green]Оптимальному по какому критерию?
Что значит "максимальная выдача результатов"?[/QUOTE]
Фраза "Максимальная выдача результатов" сама по себе ничего не значит. А фраза "минимальное использование ресурсов системы с максимальной выдачей результатов" предпологает некий эффективный и компактный способ получения и хранения/выдачи результатов.

Критерии оптимизации - минимальное использование ресурсов системы. Два основных ресурсы системы - циклы процессора и размер "быстрой памяти" т.е. ОЗУ.

Оптимальный код требует минимум ресурсов для решения данной задачи. При этом баланс процессор/ОЗУ - не всегда тривиален и во многих случаях требует аналитического рассчета еще в стадии проектировании программы.

Не хватает примеров? Вектор. Что такое вектор? Это статический массив, при переполнении которого запрашивается удвоенное количество памяти, и весь массив переносится на новое место. Каждый вызов new - это обращение к операционной системе, каждое "передвижение" памяти - это нагрузка на процессор и задержки связанные с огромным количеством обращений к памяти при больших размеров массива.

То есть, по сути вектор может занимать вплоть до двукратного количества памяти. Много ли людей знают этот факт? Это надо учитывать при использовании больших векторов... Эти знания могут понадобиться для решения таких вопросов как "а нельзя ли реализовать это при помощи статического массива?". Чем действительно вредно STL для новичков, так это тем что они часто не знают как это все реализовано, и какие затраты ресурсов связаны с использованием каждого контейнера STL.

[QUOTE=Svyatozar] Я исхожу из того что для каждой задачи есть некий оптимальный алгоритм А, и безконечное множество других решений Д. Нет такого универсального алгоритма который оптимален для всех задач!
[/QUOTE]
Естественно, наилучшее бысродействие / прочее использование ресурсов / и.т.д. будет тогда, когда код пишется целиком вручную и ТОЛЬКО для решения этой задачи, без намека на последующее использование. Но кому практически бывает нужно такое?
Понятно, что к примеру, наличие огромного числа членов в классе string - это на минимум 50% пустая трата ресурсов, но зато остальное полезно, и его не надо писать с нуля. Все существующие библиотеки в той или иной степени тратят ресурсы впустую, потому что крайне редко встречаются приложения, использующие ВЕСЬ ее API. Вот мне и интересно, что за задача. Оптимального алгоритма нет, но практически, редко оптимальность алгоритма может настолько превалировать над оптималностью кодинга. Потому мне было бы интересно познакомиться с твоим примером:)

[QUOTE=Svyatozar]
Это статический массив, при переполнении которого запрашивается удвоенное количество памяти, и весь массив переносится на новое место. [/QUOTE]
Во первых, не в 2, а в полтора, по крайней мере в той что в VS входит.. Хотя это может зависеть от реализации конкретной версии.

[QUOTE=Svyatozar]
Чем действительно вредно STL для новичков, так это тем что они часто не знают как это все реализовано, и какие затраты ресурсов связаны с использованием каждого контейнера STL.[/QUOTE]
Угу:D А уж как вредно Qt или MFC.. Страх просто. Сидишь, рисуешь виджеты, лэйауты одним росчерком создаешь...и никаких километров кода..Жуть, правда?:D
А если серьезно, то для новичков она не только вредна, но и довольно сложна для понимания. Трудно все таки работать непонятно с чем. Но ты то специалист;) Тебе должно быть легко и полезно.
И еще про критерии оптимальности, сюда и интерфейс входит. Как бы ни был написан движок, но когда кнопки размером 3 х 4 пикселя, много не наработаешь.

[QUOTE=Svyatozar]
[QUOTE=Green]
Кроме того, контейнеры - это реализация алгоритма, а не сам алгоритм.
[/QUOTE]
Ну это вообще какая-то туманная фраза. Например, разве STL не использует алгоритм определенный сортировки? А ведь алгоритмов сортировок много разных в зависимости от известных данных...
[/QUOTE]
Что тут туманного?
Ты не видишь разницы между алгоритмом и его реализацией?
В некотором алгоритме мы должны держать набор каких либо значений, причем как, в каком хранилище, в массиве или стаднартном контейнере - это уже не относится к алгоритму, это реализация.
Поэтому применяя то или иное хранилище ты оптимизируешь не алгоритм, а всего лишь его реализацию.

[QUOTE=Svyatozar]
Фраза "Максимальная выдача результатов" сама по себе ничего не значит. А фраза "минимальное использование ресурсов системы с максимальной выдачей результатов" предпологает некий эффективный и компактный способ получения и хранения/выдачи результатов.
[/QUOTE]
Эта фраза так же сама по себе ничего не значит. Я уже говорил: обобщенной оптимизации не существует, оптимизация неразрывно связана с критерием оптимизации. Обобщенного критерия так же не существует, т.к. он всегда уникален для конкретной задачи.
Пример: приведи мне вариант оптимального автомобиля.

[QUOTE=Svyatozar]
Критерии оптимизации - минимальное использование ресурсов системы. Два основных ресурсы системы - циклы процессора и размер "быстрой памяти" т.е. ОЗУ.
[/QUOTE]
Для какой именно задачи это критерии оптимизации?
Для всех задач? Обобщенный критерий оптимизации?

[QUOTE=Svyatozar]
Оптимальный код требует минимум ресурсов для решения данной задачи. При этом баланс процессор/ОЗУ - не всегда тривиален и во многих случаях требует аналитического рассчета еще в стадии проектировании программы.
[/QUOTE]
Код какой задачи? Для каких условий?

[QUOTE=Svyatozar]
Не хватает примеров? Вектор. Что такое вектор? Это статический массив,
[/QUOTE]
Вектор - это контейнер.
Вектор нужен там, где ему место для конкретной задачи. И там, где ему место другому контейнеру не совсем "уютно".

[QUOTE=Svyatozar]
при переполнении которого запрашивается удвоенное количество памяти, и весь массив переносится на новое место.
[/QUOTE]
Ты будешь удивлен, но это так же лишь обобщенный вариант.

[QUOTE=Svyatozar]
Чем действительно вредно STL для новичков, так это тем что они часто не знают как это все реализовано, и какие затраты ресурсов связаны с использованием каждого контейнера STL.[/QUOTE]
Раз не знают, значит и не надо им этого знать до поры до времени.
Ты знаешь, как устроен мобильный телефон?
Тебе мешает незнание его внутренностей, пользоваться им?
Ты знаешь с какими побочными затратами связано функционирование мобильника? Задние лепестки и т.п.
Да... незнание того, как реализован и функционирует мобильник - это реальный вред для новичков-абонентов. Незнание ядерной физики - реальный вред для потребителей электро-энергии.
Ты хорошо разбираешься в компиляторах, синтаксических анализаторах, написал сам хотя бы один компилятор или интерпретатор С++?
Это сильно мешает тебе программировать?

[QUOTE=Green]
Ты хорошо разбираешься в компиляторах, синтаксических анализаторах, написал сам хотя бы один компилятор или интерпретатор С++?
[/QUOTE]
Это ты про gcc?

Раз уж речь зашла об оптимизации - она бывает очень даже разной
1. Оптимизация исходного кода - запись выполнения действий в одну-две строки; читабельность текста; защита от случайных ошибок.
2. Оптимизация размера машинного кода - выделение общих последовательностей команд в отдельные функции с их вызовом.
3. Оптимизация использования мощности процессора.
4. Оптимизация использования объёма оперативной памяти.
5. Оптимизация дисковых операций - файлового ввода/вывода.
6. Оптимизация сетевого траффика, загруженность отдельных участков линии передачи данных.
И это далеко не полный список, причём оптимизирование по одному пункту неизбежно приводит к повышенным требованиям по нескольким другим пунктам.
А "абсолютной" оптимизации не существует, бывает только программа, неоптимальная по всем пунктам одновременно :D

[QUOTE=Green]Что тут туманного?
Ты не видишь разницы между алгоритмом и его реализацией?
В некотором алгоритме мы должны держать набор каких либо значений, причем как, в каком хранилище, в массиве или стаднартном контейнере - это уже не относится к алгоритму, это реализация.
Поэтому применяя то или иное хранилище ты оптимизируешь не алгоритм, а всего лишь его реализацию.[/QUOTE]Повторяю вопрос: "разве STL не использует определенный алгоритм сортировки?"


[QUOTE=Green]Эта фраза так же сама по себе ничего не значит. Я уже говорил: обобщенной оптимизации не существует, оптимизация неразрывно связана с критерием оптимизации. Обобщенного критерия так же не существует, т.к. он всегда уникален для конкретной задачи.
Пример: приведи мне вариант оптимального автомобиля.[/QUOTE]Ты читаешь тему? Читай еще раз что я писал в теме: Мы тут о разных вещах говорим. Что ты называешь быстродействием? "Я исхожу из того что для каждой задачи есть некий оптимальный алгоритм А, и безконечное множество других решений Д. Нет такого универсального алгоритма который оптимален для всех задач! О чем и речь, собственно."

[QUOTE=Green]Для какой именно задачи это критерии оптимизации?
Для всех задач? Обобщенный критерий оптимизации?[/QUOTE]для любой задачи оптимальный алгоритм - это тот который потребляет минимум ресурсов. Не зависимо от типа машины будь то формула-1 или карьерный грузовик или даже мотоцикл, основной ресурс - это количество потребляемого топлива на километр. Так же и в программировании основной ресурс - циклы процессора. Не зависимо от задачи. Ресурсы системы не зависят от типа задачи: либо у тебя етсь четыре гигабайта ОЗУ либа их у тебя нету.


[QUOTE=Green]Вектор - это контейнер.[/QUOTE]
Вектор - это направленный отрезок.

[QUOTE=Green]Вектор нужен там, где ему место для конкретной задачи. И там, где ему место другому контейнеру не совсем "уютно".[/QUOTE]
уж кто бы говорил об обобщениях!

[QUOTE=Green]Ты будешь удивлен, но это так же лишь обобщенный вариант.


Раз не знают, значит и не надо им этого знать до поры до времени.
Ты знаешь, как устроен мобильный телефон?
Тебе мешает незнание его внутренностей, пользоваться им?[/QUOTE]
конечно! Сейчас в мобильниках столько наворотов, без документации врядли разберешься. Какой там пользоваться - включить не сможешь! А если ты не знаешь свойства ультракоротких радиоволн, тебе трудно будет звонить в туннеле... Пару раз попробуешь - глядишь разберешься.

[QUOTE=Green]Ты знаешь с какими побочными затратами связано функционирование мобильника? Задние лепестки и т.п.
Да... незнание того, как реализован и функционирует мобильник - это реальный вред для новичков-абонентов.[/QUOTE]Мобильный телефон вообще вреден для здоровья.

[QUOTE=Green]Незнание ядерной физики - реальный вред для потребителей электро-энергии.
Ты хорошо разбираешься в компиляторах, синтаксических анализаторах, написал сам хотя бы один компилятор или интерпретатор С++?
Это сильно мешает тебе программировать?[/QUOTE]Между прочим устройство компилятора C я изучал по книге Холуба Compiler Design in C, и всем рекомендую. А про интерпретатор С++ я никогда еще не слышал, извиняй.

[QUOTE=el scorpio]Раз уж речь зашла об оптимизации - она бывает очень даже разной
1. Оптимизация исходного кода - запись выполнения действий в одну-две строки; читабельность текста; защита от случайных ошибок.
2. Оптимизация размера машинного кода - выделение общих последовательностей команд в отдельные функции с их вызовом.
3. Оптимизация использования мощности процессора.
4. Оптимизация использования объёма оперативной памяти.
5. Оптимизация дисковых операций - файлового ввода/вывода.
6. Оптимизация сетевого траффика, загруженность отдельных участков линии передачи данных.
И это далеко не полный список, причём оптимизирование по одному пункту неизбежно приводит к повышенным требованиям по нескольким другим пунктам.
А "абсолютной" оптимизации не существует, бывает только программа, неоптимальная по всем пунктам одновременно :D[/QUOTE]Вообще-то речь идет об оптимальных алгоритмах, и они как раз-таки оптимизируются по ресурсам системы. Читай Дональда Кнута!

Вот простой пример: любой продукт имеет так называемое соотношение цена/качество. Вот так же и алгоритм. Оптимальный алгоритм - это тот алгоритм который дает качественный результат, потребляя минимум ресурсов системы. Ресурсы могут быть самые разнообразные и они конечно зависят от задачи! Разве я с этим спорил?

[QUOTE=el scorpio]Раз уж речь зашла об оптимизации - она бывает очень даже разной
[/QUOTE]
Да, конечно, рад что хоть в этом мы сошлись:) . Именно поэтому я и просил конкретные примеры реализации, чтобы можно было судить не голословно.
[QUOTE=svyatozar]
Повторяю вопрос: "разве STL не использует определенный алгоритм сортировки?"
[/QUOTE]
Нет. Там их несколько, оптимальных при разных условиях.
Sort , stable_sort , это общие, отличающиеся используемым алгоритмом, в первом - qsort, во втором - какой-то стабильный алгоритм, точно честно говоря не помню, по-моему, пирамидальная сортировка. Плюс есть сортировки в Контейнерах, оптимизированные соответственно под конкретный тип контейнера, + несколько других сортировок в самом #include <algorithm>, не говоря про boost.
[QUOTE=svyatozar]
для любой задачи оптимальный алгоритм - это тот который потребляет минимум ресурсов. Не зависимо от типа машины будь то формула-1 или карьерный грузовик или даже мотоцикл, основной ресурс - это количество потребляемого топлива на километр. Так же и в программировании основной ресурс - циклы процессорам
[/QUOTE]
Ты действительно считаешь, что для болида расход топлива - главное??? Нда...
Насчет того что это основной ресурс - тоже неверно, только что было сказано, что важность ресурсов уникальна.
[QUOTE=svyatozar]
"Я исхожу из того что для каждой задачи есть некий оптимальный алгоритм А, и безконечное множество других решений Д. Нет такого универсального алгоритма который оптимален для всех задач! О чем и речь, собственно."
[/QUOTE]
На самом деле, на практике, раз уж решили отвлечься от абстрагируемости, существует множество оптимальных решений А и множество менее оптимальных решений Д, причем это я считаю для какого то конкретного критерия оптимизации. Для некоторых задач грань между этими множествами провести КРАЙНЕ трудно, поверь.

[quote=Svyatozar]
для любой задачи оптимальный алгоритм - это тот который потребляет минимум ресурсов.
[/quote]
несогласен. в некоторых ситуациях скоростью можно пожертвовать ради надежности, например. а иногда - наоборот.
[quote=Svyatozar]
конечно! Сейчас в мобильниках столько наворотов, без документации врядли разберешься. Какой там пользоваться - включить не сможешь! А если ты не знаешь свойства ультракоротких радиоволн, тебе трудно будет звонить в туннеле... Пару раз попробуешь - глядишь разберешься.
[/quote]
среднестатистический обладатель мобилы использует ее чисто как звонилку. если нужны еще какие то функции - это есть в мануале.
невозможность позвонить в туннеле - не познакомит его с основами радиосвязи. он просто приобретет "условный рефлекс", что в туннеле не звонит.
приблизительно так используют некоторые программисты различные высокоабстрактные фреймворки, контейнеры и иже с ними. это не плохо и не хорошо. это есть
[quote=Svyatozar]
Мобильный телефон вообще вреден для здоровья.
[/quote]
:)

Мне прям нечего сказать... :)
Ребята и так уже много рассказали, что нет обобщенного критерия оптимальности, за который ты хочешь выдать нам "ресурсы системы".

[QUOTE=squirL]несогласен. в некоторых ситуациях скоростью можно пожертвовать ради надежности, например. а иногда - наоборот.[/QUOTE]Можно поспорить что надежность - критерий оптимизации алгоритма. Скорее это условие задачи.

[QUOTE=squirL]среднестатистический обладатель мобилы использует ее чисто как звонилку. если нужны еще какие то функции - это есть в мануале.
невозможность позвонить в туннеле - не познакомит его с основами радиосвязи. он просто приобретет "условный рефлекс", что в туннеле не звонит.
приблизительно так используют некоторые программисты различные высокоабстрактные фреймворки, контейнеры и иже с ними. это не плохо и не хорошо. это есть

:)[/QUOTE]на то он и пользователь чтобы трепом своим засорять радиоволновый эфир. С него и спросу - ноль...

[quote=Svyatozar]Можно поспорить что надежность - критерий оптимизации алгоритма. Скорее это условие задачи.
[/quote]
это уже жонглирование терминами, более уместное на юридическом форуме :)
[quote=Svyatozar]
на то он и пользователь. С него и ответственности - ноль.[/quote]
а программист тоже пользователь. ему не зачем вникать в работу компа до уровня течения электронов, чтобы склепать программу на каком нибудь Tcl/Tk или Ruby :) я специально взял эти языки в качестве примеров. С-шники (и С и С++ в данном случае беру) у нас пока еще образованы традиционно. с ассемблером, архитектурой ПК и всеми прибамбасами. а вот пользователи описаных "ЯП для непрограммистов" могут использовать сколь угодно высокоуровневые абстракции не вникая в детали. и это хорошо.
а насчет ответственности 0 - это ты зря. если бизнесмен пропустил важный вызов из-за того что поперся в метро с мобилой или не получил письмо, потому что не умеет на смартфоне POP3 клиент юзать - это его проблемы. так что ответсвенность у пользователя в отношениях с инструментом есть всегда :)

[QUOTE=Svyatozar]Можно поспорить что надежность - критерий оптимизации алгоритма. Скорее это условие задачи.
[/QUOTE]
Условие и критерий - понятия взаимосвязанные.
Но надежность в данном случае - это критерий.

Оффтоп: шутка в тему.

Надеюсь, этот пост никого не подвигнет собирать по схемам с инета компы...

Ещё раз об "оптимальности".
Все знают такие термины как "толстый клиент" и "тонкий клиент".
1. "Толстый клиент" большую часть вычислений выполняет сам, вследствие этого имеется офигенный траффик по локальной сети, зато сам сервер занят только операциями ввода/вывода.
2. "Тонкий клиент" озадачен только реализацией пользовательского интерфейса. Вследствие этого, клиенты могут быть реализованы на компьютерах минимальной конфигурации, и работать на низкоскоростном соединении. Зато производительность сервера должна быть ОГРОМНОЙ.
И как ни странно, обе конфигурации являются оптимальными, исходя из условий работы :D

[QUOTE=el scorpio]
И как ни странно, обе конфигурации являются оптимальными, исходя из условий работы :D[/QUOTE]
Что тут странного? Ведь все сошлись на том, что параметры оптимизации - для каждой задачи уникальны.:)
А хороший пример! В точку разрешает спор.

[QUOTE=squirL]это уже жонглирование терминами, более уместное на юридическом форуме :)
[/QUOTE]Вовсе нет: оптимизация применима лишь к готовому алгоритму, отвечающему всем параметрам задачи, включая требования к надежности: бакапы, контрольные суммы и проч. На ответственных предприятиях есть различные степени проверки качества.

А "Оптимизация алгоритма по критерию надежности" - это вроде того чем занимается фирма Мелкософт с 1995 года... Кстати, понятие "критерия сложности" тоже не применимо на мой взгляд к алгоритму. Алгоритм отличается один от другого количеством итераций (действий), требуемыми ресурсами и сложностью реализации.

Возвращаясь к теме ветки, "Динамические массивы". Строго говоря, векторы STL не более динамичны чем массивы Cи. И те кто пользуются STL должны всегда это помнить.