#include "Stroika/Foundation/StroikaPreComp.h"
#include "Stroika/Foundation/Memory/InlineBuffer.h"

Namespaces
namespace	Stroika::Foundation

Typedefs
template<typename T = byte, size_t BUF_SIZE = Support::StackBuffer::DefaultInlineSize<T> ()>
using	Stroika::Foundation::Memory::StackBuffer = InlineBuffer< T, BUF_SIZE >
	Store variable sized (BUF_SIZE elements) array on the stack (.

Variables
constexpr size_t	Stroika::Foundation::Memory::Support::StackBuffer::kSizeIfLargerStackGuardCalled = qStroika_Foundation_Common_Platform_Windows ? (sizeof (int) == 4 ? 4 : 8) * 1024 : 16 * 1024

constexpr size_t	Stroika::Foundation::Memory::Support::StackBuffer::kTargetInlineByteBufferSize = qStroika_Foundation_Common_Platform_Windows ? 2 * 1024 : 4 * 1024

Detailed Description

Note: Code-Status: Beta

Definition in file StackBuffer.h.

Typedef Documentation

◆ StackBuffer

template<typename T = byte, size_t BUF_SIZE = Support::StackBuffer::DefaultInlineSize<T> ()>

using Stroika::Foundation::Memory::StackBuffer = typedef InlineBuffer<T, BUF_SIZE>

Store variable sized (BUF_SIZE elements) array on the stack (.

See also: also InlineBuffer<T,BUF_SIZE>), and on heap if it grows if needed

Typically, StackBuffer<> combines the performance of using a stack buffer (inline array on stack) to store arrays with the safety and flexability of using the free store (malloc).

Note: StackBuffer<T,N> and InlineBuffer<T,N> are the SAME TYPE; StackBuffer is an alias - so the choice is about INTENT and about the default size, and is enforced by convention rather than by the compiler:

o StackBuffer says "this buffer lives in a stack frame": a scratch buffer local to one function - marshalling, chunking a range before handing it off, accumulating a small result. THIS IS THE ONE TO USE for that, which is the common case. o InlineBuffer is the general-purpose form, and is what you want when the buffer is a DATA MEMBER of an object that may itself live on the heap - a context StackBuffer is not intended for.

The default sizes follow from that intent, and are the one concrete difference: StackBuffer's default inline element count targets Support::StackBuffer::kTargetInlineByteBufferSize (deliberately only 2K on Windows, see the note there) to keep the frame below the size where _chkstk gets called - those calls litter profiles of every function along the path, including ones that never touch the buffer. InlineBuffer defaults to a flat 4K, which is fine for a heap-resident member, where that concern does not apply.

Summary: stack frame -> StackBuffer. Data member -> InlineBuffer.

Note: Historical Note: InlineBuffer and StackBuffer used to be more different, but they did exactly the same thing. The only difference was the IDEA that StackBuffer might someday be re-implemented using alloca. I dont think thats plausible any longer, but something akin to it might be possible, so maintain the API difference for now.

Definition at line 80 of file StackBuffer.h.

Variable Documentation

◆ kSizeIfLargerStackGuardCalled

constexpr size_t Stroika::Foundation::Memory::Support::StackBuffer::kSizeIfLargerStackGuardCalled = qStroika_Foundation_Common_Platform_Windows ? (sizeof (int) == 4 ? 4 : 8) * 1024 : 16 * 1024

constexpr

On Windows, there is _chkstk which shows up in alot of profiles. Perhaps something similar for UNIX? Or just kernel does this automatically? Anyhow - target number we try - for performance reasons - to avoid more than this much in a stack frame.

https://www.codeguru.com/visual-studio/adventures-with-_chkstk/

Definition at line 27 of file StackBuffer.h.

◆ kTargetInlineByteBufferSize

constexpr size_t Stroika::Foundation::Memory::Support::StackBuffer::kTargetInlineByteBufferSize = qStroika_Foundation_Common_Platform_Windows ? 2 * 1024 : 4 * 1024

constexpr

Note: good to keep this small (around 2k) for Windows, cuz else _chkstack calls end up litering profiles in alot of functions even if along paths not actually used. COULD optimize those paths with specific value in usages, but seems reasonable to keep to 2k for now –LGP 2023-09-12

Definition at line 34 of file StackBuffer.h.

Namespaces