Большие объекты на стеке

СЛАУ предложили бы таки научится обращать матрицы

А оно там таки нужно? Полноценное в смысле, а не QR-разложение и обращение матрицы с ортонормированными столбцами. Я, конечно, понял, что именно ты хотел сказать, о пользе линейной алгебры.

Тебе производительность труда не нужно повышать?

От размера матрицы зависит;-) Скажем 5х5 - напрямую обращается нормально (на бумашке), но можно и тыком подобрать если коэффициенты несложные;-)

Тебе производительность труда не нужно повышать?

А существуют какие-то замеры и цифры, которые показывают рост производительности труда при замене С на С++? Или это типа и так всем понятно?

Я пробовал, мне не понравилось ☺

Этим не страдаю: если зарплатку повысят, буду больше работать. А сейчас и так у меня производительность слишком высокая.

А от замены С на С++ производительность скорей только упадет.

если зарплатку повысят, буду больше работать

Не будешь.

А от замены С на С++ производительность скорей только упадет.

Нет. Местами даже наоборот.

умные указатели излечат твою боязнь перед выделением памяти в куче

А что излечит от умных указателей?

тут даже умные указатели не нужны. std::vector и всех делов.

От трувея не нужно лечиться.

Это «трувей» только для несчастных плюсовиков, которые вынужденны мириться с этой лажей

С чем именно приходиться мириться? С четкой и простой концепцией управления ресурсами? А как надо-то? Мне RAII везде не хватает. Даже try новый в яве кажется костылем...

А для неплюсовиков какой трувей вместо RAII?

Если хочется и быстро, и удобно, и чтоб не переполнилось, в glibc есть obstacks - псевдостек, который можно грохнуть одним махом (главное не забыть это сделать).

Дергать malloc неудобно, нужно потом освобождать память во многих местах

Слабо выделить на стеке unique_ptr?

Дергать malloc неудобно, нужно потом освобождать память во многих местах

Region-based memory management, оно же memory pools(например, из apache portable runtime), не? Ну это если «освобождать во многих местах» означает «освобождать много объектов». Если же это значит «много точек выхода», тогда не поможет.

Дергать malloc неудобно, нужно потом освобождать память во многих местах

Слабо выделить на стеке unique_ptr?

ТС просто к тому «malloc неудобно» не добавил «и мучительно долго». Если понадобился временный буфер (объект) с временем жизни не дольше текущей функции, то стековая память просто-таки напрашивается..

странные люди, «fooClass foo(somearg)» это нормально, а «char bar[8192]» повод юзать xxx_ptr :-)

Все равно, что мальчику который решает СЛАУ предложили бы таки научится обращать матрицы, а он бы сказал «мне это ненужно»

И таки он был бы прав, потому что Метод Гаусса эффективнее.

Как вы относитесь к сабжу?

Резко отрицательно. Грубое решение такое: 1. внимательно посчитать максимальное количество памяти, которое расходуется каждым потоком, 2. выделить на старте потока это количество памяти, 3. передавать в функции указатели на память и смещение в этой памяти, соответственно их обрабатывать 4. по завершении потока освободить память. 5. обязательно покрыть тестами а) однопоточный вариант б) многопоточный. Тесты спасут отца русской демократии.

Использовал такую методу в проге на сишечке, причём вызовы были рекурсивные, так что основная сложность возникла при расчёте максимального количества памяти.

А вообще нужно использовать всякие умные указатели, если речь идёт о сферическом С++ в вакууме. Т.е. на эту тему есть целые главы во всяких умных книгах (внутренний голос подсказывает, что надо читать Коплиена на эту тему).

в многопоточной программе

Ну так увеличь себе стек до прогнозируемых величин, в чем проблема?

Освобождение после использования.

(Полу)Автоматическое в высокоуровневых языках, посредством «менеджеров контекста»(в питоне - with) и их аналогов - using, try-with-resources, семейство функций with-... и т.п.

Ручное в Си в виде лестницы с if'ами или goto на место освобождения ресурсов.

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

Недостатки - локальность использования, сложность при разделении ресурса между объектами, требование к наличию знаний о том, что объект нужно «закрыть»(что не слишком хорошо сказывается на обобщенном программировании, например).

Ну так недостатки перечеркивают достоинства. Не, плюсовый RAII очень годная концепция.

Но почему-то никому кроме плюсовиков она не нравится.

ТС просто к тому «malloc неудобно» не добавил «и мучительно долго»

Без контекста говорить про производительность - ламерство. Пока не сказано как часто функция вызывается, говорить не о чем. А сказано было только что есть риск переполнить стек. К этому наверняка стоит добавить забытую ТС, раз он задаёт такие вопросы, расширяемость. Ибо когда понадобится в 100 раз больше потоков и в 100 раз больше буффер, на unique_ptr всё так и так придётся переписывать.

странные люди, «fooClass foo(somearg)» это нормально, а «char bar[8192]» повод юзать xxx_ptr :-)

Ещё одно ламерство. Что за fooClass? Внутри взятого с потолка класса может быть как bar[8192] так и unique_ptr.

ТС просто к тому «malloc неудобно» не добавил «и мучительно долго».

Честно говоря, не помню, когда бы у меня malloc был узким местом по производительности.

Честно говоря, не помню, когда бы у меня malloc был узким местом по производительности.

бывает-бывает - malloc бывал «узким местом» даже по памяти :-)

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

Ну так вот и имеем, что RAII лучше...

$username

У вас ус отклеился.