Developing.ru

Любой целочисленный тип.

Такая вещь только с size_t прокатит? или можно с подобными типами?

size_t n;
std::cin>>n;
int a[n];

Это ужасное решение. Все современные компиляторы уже позволяют делать так:
[code]
size_t n;
std::cin>>n;
int a[n];
[/code]
Муру от Сиониста не читай. Это единственное правильное решение для подобного случая.

void actual_main(int *mas)
{
	/*
	some code
	*/
}

int main()
{
	int n;
	cin << n;
	switch(n)
	{
		case 1:
		{
			int mas[1];
			actual_main(mas);
			break;
		}
		case 2:
		{
			int mas[2];
			actual_main(mas);
			break;
		}
		/*
		more
		*/
		case N:
		{
			int mas[N];
			actual_main(mas);
			break;
		}
		default:
		{
			cout << "bad size";
		}
	}
	return 0;
}

[code]
void actual_main(int *mas)
{
/*
some code
*/
}

int main()
{
int n;
cin << n;
switch(n)
{
case 1:
{
int mas[1];
actual_main(mas);
break;
}
case 2:
{
int mas[2];
actual_main(mas);
break;
}
/*
more
*/
case N:
{
int mas[N];
actual_main(mas);
break;
}
default:
{
cout << "bad size";
}
}
return 0;
}
[/code]
знаю, что плохая идея, но я так делал иногда, пока не узнал о динамическом определении.

Тогда я не вижу смысла в создании темы.

[quote="Romeo"]И, кстати, так и не нашёл вопроса[/quote]А я его и не задавал.

А можно небольшую просьбу? Можно писать по сути? Я пока дочитал, чуть не вывихнул челюсть во время затяжных зеваний. И, кстати, так и не нашёл вопроса. В чём вопрос?

size_t n;
std::cin>>n;
int a[n];

int a[n];

size_t n;
std::cin>>n;
int a[n];

[b]Формально[/b] нет ни каких запретов на [code]size_t n;
std::cin>>n;
int a[n];[/code]: к тому моменту, когда исполнение доберётся до декларации [code]int a[n];[/code] n уже известно и можно увеличить стек на размер массива и потом учесть в адресах следующих локальных переменных. Но обратите внимание: стек увеличивается на неизвестную на этапе разработки величину, что не есть хорошо, так как не позволяет адекватно настроить максимальный размер стека. Рекурсия страдает тем же самым, но иногда просто нет другого выхода, кроме как использовать рекурсию. К тому же есть ведь ещё хвостовая рекурсия, она этим не страдает. Такому же массиву альтернатива есть всегда. На этапе разработки n не известно, а суммарный размер локальных переменных, хоть тест этого и не показывает, должен быть известен на этапе разработки, так как только так можно обеспечить предсказуемый расход стека, а он дефицитнее кучи. Опасность указателей - полумиф, опасны лишь те указатели, которые выдаются наружу. А внутри одного проекта программист уж точно знает, где у него какой указатель валяется и с чем его "едят". Даже если программистов много и один указатель декларировал, другой присвоил, третий передал внутри проекта, четвертый использует. Всё равно. Это такая же переменная, как какой нибудь инт. В интах ни кто не путается? Чем же указатели хуже? Не знаешь - не трогай, трогаешь - узнай, не можешь - не программируй. И ни каких утечек памяти из указателей не вытекает. Я программирую с весны 1995-го года и до сих пор [b]не смог[/b] получить утечку памяти. Видимо для этого как раз и нужны умные указатели, или странные то ли указатели то ли ссылки. В любую же функцию, или оператор массив в любом случае именно как указатель и передаётся. Не нравится, когда указатель валяется на самом виду? Ну инкапсулируйте. В чём проблема? Тогда автор класса будет полностью отвечать за все операции с указателем, количество кривых рук с допуском к указателю резко сократится. Вы же этого хотите? При [code]size_t n;
std::cin>>n;
int a[n];[/code] же это как раз не достигается, указатель будет лишь слегка прикрыт граблями. Причём, стеклянными.