|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
ну я Место на стеке освободится если бы alloca стоял внутри {}. Инициализаторы выполняются в стек фрейме конструктора. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2021, 18:05 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
White Owl В стандарте С alloca - есть. В стандарте С++ std::alloca - нет. В C тоже нет, и в POSIX тоже )) Но это не отменяет того факта что на многих платформах эта фича существует. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2021, 18:11 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky White Owl В стандарте С alloca - есть. В стандарте С++ std::alloca - нет. В C тоже нет, и в POSIX тоже )) Но это не отменяет того факта что на многих платформах эта фича существует. man allocaCONFORMING TO This function is not in POSIX.1. There is evidence that the alloca() function appeared in 32V, PWB, PWB.2, 3BSD, and 4BSD. There is a man page for it in 4.3BSD. Linux uses the GNU version. Так что да, в стандарте нет, но в реальных библиотеках все-же есть. Во всяком случае во всех никсовых библиотеках есть. А мелкомягкие дают _alloca и _malloca. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2021, 19:02 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
rdb_dev ну я, разве в стандарте C/C++ есть функции alloca/std::alloca ? Нет, в стандарте языка нет такого. http://www.c-cpp.ru/content/alloca Другое дело что это в компиляторах есть и трактуется одинаково. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2021, 22:35 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
White Owl, нет в стандарте ANSI C никакой alloca(). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2021, 10:16 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
White Owl, "легально" такие вещи реализуются на стеке через placement new. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2021, 11:26 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
indigodye0, может быть собеседующий действительно имел в виду alloca + placement new? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
Но я бы не стал так делать, потому что alloca -- это хождение по тонкому льду :). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 02:27 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
Пётр Седов [/src]Но я бы не стал так делать, потому что alloca -- это хождение по тонкому льду :). Ага то есть Вы ка бы вывернули класс мехом на изнанку и положили все на стек А что тут опасного ? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2021, 11:43 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
Зачем все усложнять? )) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2021, 15:16 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
priti40 А что тут опасного ? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Компилятор Visual C++ 6, в Debug конфигурации всё было нормально. Но вот в Release конфигурации компилятор зачем-то inline-ил вызов функции another_func (хотя она была не такая уж и маленькая), и работало оно так, как будто код такой: Код: plaintext 1. 2. 3. 4. 5. 6.
В Win32 для stack-а главного thread-а по умолчанию резервируется диапазон в 1 мб виртуальных адресов. Вот весь этот мегабайт исчерпывался, и программа crash-илась со stack overflow. С тех пор я понял, что alloca -- это грабли, и перестал его использовать. Хотя современный Visual C++ может уже понимает, что не надо inline-ить вызов функции с alloca. В ATL есть старые макросы для преобразования строк, которые выделяют память через alloca. Потом вместо них сделали более надёжный механизм: http://msdn.microsoft.com/EN-US/library/87zae4a3(v=VS.120,d=hv.2).aspx ATL and MFC String Conversion Macros ... There are several important differences between the older string conversion macros and the new string conversion classes: Old ATL 3.0 Conversion Macros New ATL 7.0 Conversion Classes Allocates memory on the stack.Uses stack memory for small strings. Uses the heap if the stack is not large enough.The string is freed when the function is exited.The string is freed when the variable goes out of scope.Cannot be used in exception handlers.Can be used in exception handlers.Not suitable for use in loops. Memory use grows until the function is exited.Supports use in loops. Loop scope ensures that memory is freed on each iteration.Not good for large strings. Stack space is limited.No problems with large strings. Strings will be allocated on the heap.Usually require USES_CONVERSION to be defined.Never require USES_CONVERSION to be defined.Meaning of OLE depends on definition of OLE2ANSI.OLE is always equivalent to W.... ATL 3.0 String Conversion Macros ... The destination string is created using _alloca , except when the destination type is BSTR . Пункт про обработчики исключений сильно настораживает. Anatoly Moskovsky Код: plaintext 1. 2.
Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2021, 03:02 |
|
Аллокация в конструктора массива
|
|||
---|---|---|---|
#18+
Пётр Седов А тут не будет проблем с выравниванием (alignment)? Нет. Гарантируется правильное выравнивание. Как и для любых других аллокаторов. https://en.cppreference.com/w/cpp/memory/memory_resource/allocate Хотя конечно если буфер сразу выровнен, то не будет потерян первый невыровненный кусок. Но это всего лишь оптимизация, а не необходимость. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.11.2021, 12:14 |
|
|
start [/forum/topic.php?fid=57&msg=40109762&tid=2017160]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 278ms |
total: | 405ms |
0 / 0 |