LINUX.ORG.RU

История изменений

Исправление Moisha_Liberman, (текущая версия) :

Для текущей задачи я прикинул что к чему и выкрутился через std::vector.

Знаете как потенциально может выглядеть реализация alloca() для семейства Intel?

Всего-навсего:

sub esp, <desired_size_in_bytes>

Причина проста – у нас в процессоре есть регистр, отвечающий за стек. С ним и работаем. Вычитаем из его текущего значения нужный нам размер (в байтах). Правда, тут всё не так просто как оно кажется. Тут есть ряд подводных камней, начиная от того, что можно таким кодом снести все gcc-оптимизации (например, global register allocation) и кончая тем, что если уж так жёстко начинаем рукоблудить в коде, то надо не забывать о том, что мы тут не одни и надо тогда такой код добавлять во все свои ф-ии. И отслеживать состояние флагов процессора, того же флага знака (SF), потому как если мы внезапно получили отрицательное число, то… то лучше ненадо таких решений. Пусть лучше этим занимается внутренняя реализация gcc.

К чему это я всё? А это такой… лёгкий намёк, если угодно. Смотрите – у Вас std::vector… Может, имеет смысл поискать более экономичные реализации? Я ни в коем разе не настаиваю, просто слегка намекаю. ;)

Исходная версия Moisha_Liberman, :

Хотите насмешу до колик? =)))

Для текущей задачи я прикинул что к чему и выкрутился через std::vector.

Знаете как потенциально может выглядеть реализация alloca() для семейства Intel?

Всего-навсего:

sub esp, <desired_size_in_bytes>

Причина проста – у нас в процессоре есть регистр, отвечающий за стек. С ним и работаем. Правда, тут всё не так просто как оно кажется. Тут есть ряд подводных камней, начиная от того, что можно таким кодом снести все gcc-оптимизации (например, global register allocation) и кончая тем, что если уж так жёстко начинаем рукоблудить в коде, то надо не забывать о том, что мы тут не одни и надо тогда такой код добавлять во все свои ф-ии. Пусть лучше этим занимается внутренняя реализация gcc.

К чему это я всё? А это такой… лёгкий намёк, если угодно. Смотрите – у Вас std::vector… Может, имеет смысл поискать более экономичные реализации? Я ни в коем разе не настаиваю, просто слегка намекаю. ;)