Динамически выделяемые локальные массивы в c++

гнутым расширением, AFAIK

попробуй скаомпилить с -ansi и gcc тебе все объяснит.

> попробуй скаомпилить с -ansi и gcc тебе все объяснит.

Компилирует молча, вообще ничего не говорит. Причём в режиме любых стандартов.

Как заставить msvc это скомпилировать ?
Если это возможно ...

> Как заставить msvc это скомпилировать ?

Вот у меня вопрос как раз возник потому что msvs это не компилирует. То ли это расширение стандарта, то ли это msvs стандарты не полностью поддерживает...

C99 - является. Раньше, АФАИК, не являлось. С++ - не является.

n должна быть константой времени компиляции, конкретно твой пример фиксится так:

const int n=10; 
double a[n];

 

в C++ надо использовать std::vector, а не всякие пережитки С

> в C++ надо использовать std::vector, а не всякие пережитки С

...за исключением случаев, когда "пережитки" гораздо быстрее ;)

Бездумное использование std::vector может весьма негативное сказаться на производительности, т.к. скорость выделения памяти на стеке в разы быстрее.  

Это вы сами придумали или прочитали где? Хотя, не сомневаюсь, у вас такое может иметь место. А под стек память выделять не надо? Откуда же она берётся?

Иногда лучше жевать, чем говорить.

используй

vector < double > a(n)

В каком месте они "гораздо быстрее" ? тесты есть? vector этот тот же массив Си, только завернутый внутрь класса. Если так хочется с ним работать как с double *, то возьми адрес нулевого элемента.

> В каком месте они "гораздо быстрее" ?

Если моя память мне ни с кем не изменяет, при создании вектора производится вызов operator new (в случае использования дефолтного аллокатора). При создании массива auto производится арифметическая операция с указателем стека. Вот это и называется "гораздо быстрее".

> тесты есть?

Зачем? В любом случае, спрашивай OP.

> vector этот тот же массив Си, только завернутый внутрь класса.

Да ты что? Нет, правда? :)

> Если так хочется с ним работать как с double *, то возьми адрес нулевого элемента.

И зачем в таком случае использовать vector?

Еще раз: использовать вектор или auto-массив - зависит от обстоятельств.

Хм, а new работает также как malloc() или есть отличия?

new еще инициализирует переменные.

ну так и calloc() тоже инициализирует. дело не в этом - мне было интересно узнать отличие для того, чтобы понять насколько в new добавлено больше накладных расходов по сравнению с тем же malloc()/calloc().

P.S. собственно касательно отличия в скорости - выделение массива в стеке это просто изменения SP и если память для стека выделена то page fault'ов не будет (что очень быстро); в случае malloc()/calloc() я так понимаю добавляются дорогие jump'ы на ф-ции и идут syscall'ы в случае необходимости (двигают brk-адрес) в случае если в пуле недостаточно памяти ну и page-fault'ы тоже возможны тк cow используется. P.P.S. хм, вообще интересно где может быть критична скорость выделения/освобождения памяти - может с дизайном не всё в порядке?...

new вызывает конструкторы для классов (а те вызыватют конструкторы своих частей и т.д.) => jump-ов и просто действий может быть много.

Если не ошибаюсь аллокация обычно делается через анонимный mmap и расширяется как и степ при pf-ах. Правда там обычно захватывают больше одной страницы а потом хитро распределяют.

Т.е. в большинстве случаев imho при alloc-е нет pf-ов, есть просто вызов стандартной библиотеки в том-же процессе. И разница не катастрофична(нету лишних syscall/pf).

вот интересно стало как определяется падение производительности в процентном соотношении кол-во syscall'ов/кол-во page fault'ов?

мне почему то кажется что большое кол-во page fault'ов хуже чем большое кол-во сисколов (хотя понятно что сисколы косвенно бьют и по другим вешам - кэшу например)...

> вот интересно стало как определяется падение производительности в процентном соотношении кол-во syscall'ов/кол-во page fault'ов?

не знаю, я про это не говорил.

> мне почему то кажется что большое кол-во page fault'ов хуже чем большое кол-во сисколов (хотя понятно что сисколы косвенно бьют и по другим вешам - кэшу например)...

imho примерно одинаково, главное переключение в ядро есть и возможно обращение к диску. Тут уж не до кэша. =)

ну если не ошибаюсь page fault не всегда означает доступ к диску (может просто SIGSEGV) - так что не факт что 50/50

испоганивание кеша и reschedule при выходе из сискола тоже счастья не добавляют (хотя по сравнению с доступом к диску это сущая ерунда)

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

локальные массивы переменной длины - есть в С99, но являются гнутым расширением для С++

Premature optimization is source of all evil (c) DEK

> Premature optimization is source of all evil (c) DEK

Разве? А по-моему, он сказал "root" ;)

Точно.

Зачем оптимизировать то что bad by design?

может быть - писал по памяти, но смысл ИМХО передан верно.