Войти
ПрограммированиеФорумГрафика

Modern C++ stack allocation (2 стр)

Страницы: 1 2 3 4 Следующая »
#15
22:48, 30 апр. 2016

Suslik
> а с чего бы он должен это делать-то?
Потому что может.
Sergio
> Тогда, должен быть симметричный delete, который удаляет на стеке.
Ах да, строчку пропустил.
А delete конекретно на стеке не существует. Есть RSP=RBP для программного и аналогичная операция для велосипедного. Это одна из его ключевых особенностей - освобождение памяти происходит одним присваиванием.

#16
23:01, 30 апр. 2016

Delfigamer
> Потому что может.
Как?

#17
14:49, 1 мая 2016

-Eugene-
По тому же принципу, как шланг их склеивает и выкидывает.

#18
22:31, 1 мая 2016

А что автор в стартовом вопросе увидел небезопасного?

#19
22:41, 1 мая 2016

pavelkolodin
> А что автор в стартовом вопросе увидел небезопасного?
это как бы не я один увидел. погугли "why variable length arrays are bad". в двух словах — ты можешь порушить стек и даже не узнать об этом. однако, я настаиваю на том, что в некоторых случаях такой инструмент всё равно необходим.

#20
0:55, 2 мая 2016

Suslik
> однако, я настаиваю на том, что в некоторых случаях такой инструмент всё равно
> необходим.
Мм... А зачем?

#21
2:45, 2 мая 2016

Barabus
за хлебом. существуют случаи, когда память хотелось бы уметь выделять и освобождать динамически быстро. например, для многих алгоритмов на матрицах нужно использовать промежуточные матрицы, которые надо как-то выделять и где-то хранить. если матрицы имеют средний размер, то выделять их на куче — слишком затратно, а хранить на стеке по максимальному размеру — нерационально. уже говорил, что ODE использует для этого костыли вроде alloca, задефайненные для каждого компилятора, в то время как аллокация на стеке — это операция, которая не может быть реализована через обычную функцию by design, её можно по-нормальному реализовать только на уровне синтаксиса языка.

#22
3:05, 2 мая 2016

Suslik
> это операция, которая не может быть реализована через обычную функцию by
> design, её можно по-нормальному реализовать только на уровне синтаксиса языка
Ээ... На уровне синтаксиса?
Но ведь alloca - это и есть обычная функция, только compiler-specific.

#23
3:05, 2 мая 2016

http://man7.org/linux/man-pages/man3/alloca.3.html

void *alloca(size_t size);

Работает и на MSVC, и на GCC/Clang. Юзать, например, так:

LGL3->glGetProgramiv( ObjectID, GL_INFO_LOG_LENGTH, &MaxLength );

if ( MaxLength )
{
  char* Log = ( char* )alloca( MaxLength );
  LGL3->glGetProgramInfoLog( ObjectID, MaxLength, &Length, Log );
  InfoLog = LString( Log );
}
#24
12:06, 2 мая 2016

Suslik
> а хранить на стеке по максимальному размеру — нерационально.
Это единственный надежный способ выделить место в стеке, разве нет? alloca не гарантирует, что это место непременно найдется.

К слову, эксперименты показали, что ручные операции по выделению выровненной памяти и код интрисиками максимум вдвое превышали по скорости то, что генерирует компилятор (от MS) с максимальной оптимизацией для кода с обычными циклами и мат.операторами.

Так что оно имеет смысл тогда, когда надо перемножить о-очень много векторов/матриц за раз. А тут GPGPU лучше справится, как ни крути.

> её можно по-нормальному реализовать только на уровне синтаксиса языка.
А если целевая архитектура не предусматривает стека, как такового?

Да и синтаксис на скорость не особо влияет :) Другое дело — оптимизирующий компилятор.

#25
12:51, 2 мая 2016

Barabus
> А если целевая архитектура не предусматривает стека, как такового?
Ну такие архитектуры в данном случае вряд ли являются целевыми.

#26
13:22, 2 мая 2016

Sbtrn. Devil
> Ну такие архитектуры в данном случае вряд ли являются целевыми.
Не, я о том, что высокоуровневый язык by design должен быть платформонезавизимым настолько, насколько это возможно.

Даже стек, как таковой — для C++ условность и лишь следствие того, что C разрабатывался под x86, а C++ этот термин унаследовал.

Если же на платформе стека нет, как такового, нет никаких препятствий скомпилировать программу на C++ и под нее. А вместо стека, скажем, для передачи аргументов функциям, могут использоваться регистры, которых на некоторых платформах в достатке.

По факту стек — это всего лишь метод адресации и несколько связанных с ним машинных инструкций, не более того. И синтаксис языка не обязан знать, что такая штука, как стек, в принципе существует. Это задача для компилятора.

#27
14:08, 2 мая 2016

Barabus
Ну и что? Пусть сделают, как intptr_t - где есть, там есть, а где нет - стало быть, нет.

#28
14:37, 2 мая 2016

Barabus
> А вместо стека, скажем, для передачи аргументов функциям, могут использоваться
> регистры, которых на некоторых платформах в достатке.
С рекурсией проблемы будут. Все равно придётся софтовый стек делать, либо плевать на стандарт и запрещать рекурсию.

#29
14:53, 2 мая 2016

kipar
> С рекурсией проблемы будут.
У рекурсии и со стеком проблемы есть.

ОК. Пусть не регистры, а выделенная область памяти. Всегда можно что-то придумать для обхода ограничений.

Delfigamer
> Ну и что? Пусть сделают, как intptr_t - где есть, там есть, а где нет - стало
> быть, нет.
Дык есть alloca/malloca. Можно, конечно добавить и специальные формы new, но зачем? Платформозависимые вещи логичнее выносить в библиотеку.

sizeof(int) — это скорее исключение. Просто в языке с доступной прямой адресацией разрядность адреса должна определяться явно.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.