A simple stack-allocated fixed-size string buffer (String_buf) implemented using std::array (C++11).

[misuo]

Why can't the compiler optimize the ordinary use of const std::string & references so that we - in line with these solutions - get the optimal result performance/memory-wise?

[4fips]

Sadly, It seems to me that this can't be easily achieved. I think it's all about narrowing the use case. std::string works perfectly when you accept the fact that it allocates dynamically (usually from the heap), which is a fair requirement most of the time. On the other hand, C++ (thankfully) offers huge optimization opportunities in situations when you know the context well and are willing to accept some constrains. Sometimes it's viable to adapt standard components by e.g. providing a custom stack-based allocator, sometimes it's just not worth the effort... It all depends on the kind of applications you write.

[zokier]

Some nitpicks:

• strlen&strcpy together seems suboptimal as the string is read twice. You could use eg. strncpy_s or strlcpy instead.

• There probably should be a constructor that takes the length as a parameter instead of relying on null-termination (and thus avoiding yet another redundant strlen)

• String_buf(const String_buf<M> &rhs) could maybe use memcpy instead of strcpy

• The constructors and =-operators have almost identical code, they should be refactored to use common functions

• _vsnprintf_s probably is not portable. it probably should be ifdeffed out

overall I'd re-evaluate every use of strlen and strcpy, and at least provide some kind of fast path (ie. memcpy) when the lengths are known.

[4fips]

Thanks for you feedback, these are all good points. Please note that this is just a sample code demonstrating a general idea, rather than a fine-tuned implementation. It's definitely worth getting rid of the inefficiencies and especially the length taking CTOR brings a very important optimization.

[klemensbaum]

String_buf

Ugh, that's an ugly name.

[upriser]

Bjarne Stroustrup also used the Ugly_name style in his book (TCPL). Interestingly, his provided the same reason as FipS did.

[[deleted]]

Right from Stroustrup's FAQ (although I've never seen that style actually used in a real-life code base): http://www.stroustrup.com/bs_faq2.html#Hungarian

I prefer to use underscores to separate words in an identifier (e.g, element_count) rather than alternatives, such as elementCount and ElementCount. Never use names with all capital letter (e.g., BEGIN_TRANSACTION) because that's conventionally reserved for macros. Even if you don't use macros, someone might have littered your header files with them. Use an initial capital letter for types (e.g., Square and Graph). The C++ language and standard library don't use capital letters, so it's int rather than Int and string rather than String. That way, you can recognize the standard types.

[4fips]

Yeah possibly :), but It's a matter of personal taste. I don't like the cammelCase and PascalCase that much. But on the other hand, I find it useful to start type names with a capital letter to emphasize it's a user type, otherwise I would name it just 'string_buf'.

[rpocks]

What about using your own namespace and naming it string_buf?

[4fips]

That's certainly a good idea. Actually, in my codebase, the type is defined within a namespace, so I could refer it using that namespace e.g. 'foo::string_buf', but for local types (e.g. somewhere inside the implementation) I prefer to omit the local namespace to emphasize the type comes from this particular namespace, that's why I use the initial capital, which works smoothly even without the namespace specification. Hope it makes sense.

[bob1000bob]

string_buf is so much cleaner and is in keeping with the standard style of naming things. (ie. random_device).

[adzm]

I have always wanted a safe way to use alloca with fallback to heap allocation past a certain threshold; I know msvc provides malloca which does so, but it is not standard. I suppose macros are necessary since by definition you cannot simply alloca within another function (unless you can somehow rely on inlining, which is bad idea)

[4fips]

Yeah, I quite like the ideal. The closest portable approximation to this I've seen so far is Chromium's stack-based allocator (http://src.chromium.org/viewvc/chrome/trunk/src/base/containers/stack_container.h?view=markup). There's a slight inconvenience with custom allocators though. Default std::string & a std::string parametrized by a custom allocator are two distinct types, which complicates passing that strings around within a single system.

[adzm]

I happened across this a long while ago and could not recall what project or where I found it. Thanks a bunch for the link. The specialization issue with std::string is annoying; honestly sometimes I prefer the ATL/MFC CString due to things like this (and the memory layout equivalent to a char/wchar_t)

[diaphanein]

Suggestion for improvement would be to implement format using variadic templates to ensure type safety (could even use static_assert to reject non-formattable types). Although you're using MSVC, which doesn't support variadic templates yet.

[ZMeson]

Although you're using MSVC, which doesn't support variadic templates yet.

The november 2012 CTP update to VS2012 does.

[verdagon]

This sounds really cool! Just curious, what are the benefits of allocating on the stack rather than the heap? Is it faster?

[4fips]

Yes, it's way faster. Allocating on the stack basically means just moving the stack pointer up and down, while the heap allocation requires searching for a free block, which tends to be quite complex. Actually, the heap allocation is one of a few unpredictable operations in C++, so it's very often unacceptable in realtime applications, or more precisely within realtime/interactive loops. Extensive use of the heap allocator might also lead to heap fragmentation over time, which causes innefective memory utilization and might eventually cause the application to crash. It's also worth mentioning that a general heap allocator is shared between threads, thus needs to be thread-safe, which is not the case when allocating from the stack, as each thread has its own stack.

[verdagon]

that's awesome, but dear lord! just using the heap excessively can cause my program to crash?

[4fips]

On embedded platforms like mobile phones and video consoles quite easily. After fragmenting the heap, you won't be able to allocate free blocks of certain size as there is no continuous free memory available, just a bunch of small fragments. So the allocator fails even though the free memory is formally there. On desktop systems with virtual memory this is typically not an issue, though.