динам. память в ц++

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

2 - да. это memory leak.

3 - освобождается

Наверное, наивный вопрос, но, чисто теоретически - какой смысл оставлять память зарезервированной, если указателем на неё уже не воспользоваться? Или на уровне компилятора это нетривиальная задача?

> Или на уровне компилятора это нетривиальная задача?

на уровне рантайма это решается с помощью garbage collection

на уровне компиляции это нестандартная задача, потому что вызов любой фунции f(указатель) требует анализа этой функции на предмет того что она не запоминает где-нибудь этот указатель (или указатель+смещение)

>float *bar = new float [runtime_N];

пиши так

std::vector<float> bar(runtime_N);

и память сама освободиться в конце функции

Да, мне понравилась STL, даже без мусорщика очень удобно. Но в моём случае её к сожалению нельзя использовать.

>Да, мне понравилась STL, даже без мусорщика очень удобно. Но в моём >случае её к сожалению нельзя использовать.

написать аналог std::vector дело пары минут, если брать только индиксацию, конструктор и деструктор.

>написать аналог std::vector дело пары минут

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

>Наверное, наивный вопрос, но, чисто теоретически - какой смысл оставлять память зарезервированной, если указателем на неё уже не воспользоваться? Или на уровне компилятора это нетривиальная задача?

На уровне компилятора она алгоритмически не решается. Точнее нельзя, например, алгоритмически узнать есть ли в программе утечка или нет. Можно взять какой либо ЯП c GC, но там тоже некоторое подобие утечек бывает (если забыть занулить указатель на не нужную по смыслу программы память).

>и не хочется отвлекаться на постороннее, есть другие приоритеты.

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



> дело пары минут

Ну неужели что-нибудь типа этого трудно написать:
#include <cstdlib>
#include <cstdio>

template<typename T>
class MyVector {
public:
	explicit MyVector(size_t s): size_(s) {
		data_ = new T[size_];
	}
	T& operator[](size_t i) {
		return data_[i];
	}
	size_t size() const { return size_; }
	~MyVector() {
		delete []data_;
	}
private:
	T *data_;
	size_t size_;
};

int main()
{
	MyVector<float> v(10);
	for (size_t i = 0; i < v.size(); ++i) {
		v[i] = i;
		printf("%f ", v[i]);
	}
	printf("\n");
	return EXIT_SUCCESS;
}

Утечки памяти можно отлавливать - valgrind, electric fence и прочая. Другое дело, что это делается на этапе отладки, т.к. велики накладные расходы.

<offtop>
MyVector<float> v(10);
delete[] &(v[0]);

я люблю С++ :)
</offtop>

А где конструктор копии, оператор присваивания, приведение к указателю, константный оператор [], виртуальный деструктор и тыды и тыпы.

Не говоря уже про возможность указания размера массива в качестве параметра шаблона.

Вобщем это дело либо далеко не пары минут, либо получается вот такой вот мутант, ломающийся от каждого пука.

>...виртуальный деструктор...

зачем в классе-значении виртуальный деструктор о_О?...

>Не говоря уже про возможность указания размера массива в качестве параметра шаблона.

Это уже не vector.

>delete[] &(v[0]);

Кто ж тебе после такого доктор? Инкапсуляцию нарушаем-с... А вообще (ИМХО) доступ по индексу для не-POD типов - ересь...

> зачем в классе-значении виртуальный деструктор о_О?...

Откуда следует, что это класс-значение?

> Это уже не vector.

Это оптимизированная версия RO вектора.

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

>Ну неужели что-нибудь типа этого трудно написать:

Так все равно придется освобождать память (уничтожать вектор), разве нет? Поправьте меня, если не так - я просто не знаю, как работают деструкторы. И потом не реализована ни одна функция. Твой класс существует только для того, чтобы существовать.

> Вобщем это дело либо далеко не пары минут, либо получается вот такой вот мутант, ломающийся от каждого пука.

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

> Так все равно придется освобождать память (уничтожать вектор), разве нет? Поправьте меня, если не так - я просто не знаю, как работают деструкторы

Деструктор вызывается при выходе из блока, в котором определен объект.

> И потом не реализована ни одна функция.

Там определен operator[]

>Откуда следует, что это класс-значение?

А что это по-вашему? Интерфейс?... Или класс, открыто наследующий интерфейс?... Или он предназначен для открытого наследования?...

>Это оптимизированная версия RO вектора.

%)... При чём тут r/o?... Вы наверно имели в виду "вектор фиксированной (статической) длинны"? Так это, как я писал выше, не вектор, а array (см. например boost.array)...

>По остальным вопросам, судя по всему, возражение нет.

Продолжим...

>приведение к указателю

Это не есть хорошо. Может привести к неочевидным последствиям (см. книгу Дьюхерста "Скользкие места C++"). Если уж так нужно получить указатель, пользуйтесь адресом первого элемента, или, в крайнем случае, добавьте ещё один метод в интерфейс.

а smart pointers можно ? тогда std::auto_ptr<>...

>а smart pointers можно ? тогда std::auto_ptr<>...

А как у него с хранением динамических массивов (иметься в виду разница delete и delete[])?...