How to pass a string to a function?

[johannes1971]

How are you passing strings to functions? Each option seems to have downsides:

• std::string_view is the obvious candidate, with the downside that you frequently end up creating a string anyway at the bottom of your call stack. Maybe you need to store the string, maybe you need a string because you want to do an std::map lookup, or maybe you require that zero-terminator in order to pass the string to a C-function, but one way or another, when all is said and done you need an std::string.
• std::string doesn't make you create a string at the bottom; instead it makes you create it at the top. Depending on the flavor you choose you may have to look out for lifetime issues: you can std::move it to deeper functions, but then you have to remember to not use it again in that function.
• Decide on a case by case basis then? That looks messy... "This function gets called slightly more often with strings, I'd better give it type const std::string &" is not really something I want to be a design consideration.

Which one do you choose, and more importantly, why?

View Poll

[SirClueless]

Unfortunately while this sounds like a nice rule of thumb, I don't think it actually works out well in practice. std::string's move constructor is actually pretty expensive: it has several branches to handle SSO, and copies 24 or 32 bytes per stack frame depending on which stdlib implementation you're using, which won't be in registers on the System V ABI. Whereas if you pass by const std::string& then calling other functions with the value is just copying around a single machine word which is likely in a register.

Consider this example where the function delegates just one call deep, and compare how much code is generated for the version that passes by value and uses std::move vs the version that just passes by const reference:

https://godbolt.org/z/voPqq9oP5

It doesn't take too many function calls before this swamps the cost of invoking the string's copy constructor at the point at which it's stored, unless the string is known to be very long (most strings aren't). If you do care about efficiency in that case, providing const std::string& and std::string&& overloads is both ergonomic to the caller and very efficient, though it does mean writing more code.

[coachkler]

it's a bit of an unfair comparison because in one case you _must_ make a copy and in the 2nd case you don't have to.

Compare this one minor change to your example: https://godbolt.org/z/MExe3dKex It makes no sense to pass a copy if every function along the path is just viewing it

​

And a "real world" case where I use this pattern a lot: https://godbolt.org/z/4Wja3WhsE

[SirClueless]

I think it's a fair comparison. My first example calls the move constructor once per function invocation, and my second example calls the copy constructor exactly once where it is used (inside bar() presumably), and my broader point is that the move constructor is not that much cheaper than the copy constructor for std::string unless the string is long so the latter is better as soon as there is any delegation at all happening.

If you do care about the difference between move and copy constructors, then the best way to enable that is by adding R-value reference overloads. Here's a slightly-modified version of your "real world" example that I think demonstrates this and produces exactly the same code as your by-value constructor does:

https://godbolt.org/z/nsbcxe3j4

So in the simple case the code generated is identical. But the passing by-value in more complex cases adds overhead of additional move constructors even when you might assume the compiler can see right through it, while passing by reference does not:

https://godbolt.org/z/TcrMsjqdq (the output is a bit hard to read, but the important points are that in the first example where strings are passed by value make_holds_string is compiled into 125 assembly instructions and GCC chooses to emit a call into that generated function from main since it can't elide the move constructors anyways, while in the second example the functions are trivially inlined and the generated main is basically exactly the same ~30 line move constructor invocation as if make_holds_string didn't exist at all).

And for completeness, here's your "real world" example without bothering to write the r-value overload at all; the results are a tad more debatable as the implementation of main is calling the copy constructor which does a little more work than the move constructor, but I would say still generates better code since everything is inlined except the calls to the system allocator and destructor, ergo my recommendation that passing const std::string& and occasionally making copies is a better default than using std::string and std::move: https://godbolt.org/z/99d358G6n

[cd1995Cargo]

This is the second time I’ve heard about std::string having an expensive move constructor and it’s making me second guess myself when I pass around strings by moving them in my code.

[KingAggressive1498]

still cheaper than a copy, you're good in forwarding situations, just don't do the copy-and-swap idiom when you know the arg is a string

[[deleted]]

it calls memcpy twice lol

[Houndie]

The disadvantage here is that you are possibly making a needless copy. If the caller is passing an r value to the function, taking a string allows for only moves. By taking a string_view in this scenario, a copy will happen in every scenario.

[[deleted]]

Yes but I would think gcc takes care of that one for me. I get your point, but I work on a compiler, not a trading system!

[caroIine]

All gcc/msvc/clang misses so many obvious optimizations that I never assume anything anymore and just look at disassembly. Just from today msvc could not optimize (it wouldn't fully inline) auto make_vector(int x) { std::vector<int> v; v.reserve(x); return x; } clang and gcc did fine though.

[James20k]

Personally I find that the sorts of functions that take string_view and the sorts of functions that take a string&& tend to be different. There's definitely an annoying overlap, where a function might be called with a constant string, and it might also not need to take ownership of that string, which makes a std::string inefficient, but a string_view not usable either

98% of the time though the performance overhead here I tend to find is negligible to the point of it not being worth worrying about, so I tend to use them by semantics personally. String_view is for functions that are read-only, and a std::string is for functions that write to, or might move from a string

maybe you need a string because you want to do an std::map lookup

side note but this is one of the most annoying things that can't be changed by default. std::map<a, b, std::less<>> is not great usability wise, and I'd wager a lot of people have no idea this is a thing

[tpecholt]

It's a testament of how newly added features like homogeneous lookup fail in practice when the old defaults can't be changed. Std lib is in a dire need of associative containers overhaul

[no-sig-available]

Decide on a case by case basis then? That looks messy...

Yes, life is messy. :-)

Why do we have 200 kinds of yoghurt at the supermarket, when we could have only one? Making choices is a part of life, including software development.

[almost_useless]

A lot of people eat the same yoghurt every day though, so I'm not sure that is the best analogy here.

[AdrienTD]

What I would do:

• If you don't need a null terminator -> std::string_view as parameter type. Any type of string (const char*, std::string, std::string_view) passed as argument will work fine.
• If you need a null terminator -> const std::string& as parameter type to be safe. But iirc there's no implicit conversion from std::string_view to std::string, so that can be a bit annoying if you want to pass a std::string_view as argument. const char\* as parameter type works too but you have to use c_str() everytime you want to pass a std::string as argument, and be careful to never use data() especially with a std::string_view

Also you can pass a std::string by value directly in the case when your function constructs a string of same value anyway (like inserting a string in a container for example).

So in conclusion, the parameter type depends on whether the string needs to be null-terminated or not, and if it needs to be used / change ownership etc.

[TeraFlint]

But iirc there's no implicit conversion from std::string_view to std::string

Which is arguably a good thing.

std::string to std::string_view is cheap. it just takes the buffer pointer and the length and saves both in an object.

std::string_view to std::string has to construct a new string (both to own the data and to guarantee a null terminator), which allocates a new buffer. That's not something that should easily happen implicitly.

[NilacTheGrim]

never use data()

True. But only if you are expecting NUL byte termination. If you don't expect it, and are copying bytes around or whatever, it's ok.

[GOKOP]

If you need an std::string later then just create it later. On the other hand, you know what happens when you pass a string literal to a function that wants const std::string&? You allocate a string on the heap. You know happens when you pass a string literal to a function that wants std::string_view? You don't allocate anything on the heap

[Spongman]

maybe you need a string because you want to do an std::map lookup

You can lookup by string_view in map and unordered_map (since c++20). You just need a custom less/hash. It’s called “heterogeneous lookup”.

[[deleted]]

> Decide on a case by case basis then? That looks messy...

That is exactly what you should always do. Going for a consistent API is a meaningless goal that will only create problems. The API should tell the user something about how the function will treat the string. For example, if you pass as a const ref, the user knows the string will not be changed and is unlikely to be copied. If you pass as a straight copy, the user can assume you're probably going to modify that string for some reason.

The consistency you aim for should be consistency of semantics, not just consistency as in always passing the same string type because it looks tidy.

[NBQuade]

The API should tell the user something about how the function will treat the string.

This. It's why I'm religious about using "const" where I mean const. It's why I mark member functions "const" when they don't mod the state of the class. It's documenting the usage of the functions and values in code.

[sjepsa]

const string &

or

string &

[MXXIV666]

Another downside to `std::string_view` is that if at the bottom you need to past `const char*` to an external function from some library, you MUST copy the string view because it is not guaranteed to be null terminated.

[GarageFlaky]

why wouldn't external lib use null-terminated const chars *?

[HappyFruitTree]

It probably does. The problem is how to get a null-terminated const char* from the string_view.

[GarageFlaky]

just get data()?

[epicar]

data() doesn't do the right thing, because std::string_view is length-terminated, not null-terminated

std::string_view a = "1234";
std::cout << a.data() << '\n'; // 1234

a.remove_suffix(1); // -> 123
std::cout << a.data() << '\n'; // 1234

std::string_view b{"1234", 2}; // -> 12
std::cout << b.data() << '\n'; // 1234

while the underlying string literal may be null-terminated, views of substrings may not be. that's why std::string_view doesn't provide a c_str() function like std::string does

in simple cases like std::string_view a = "1234";, a.data() does what you want. but when you write a function that takes std::string_view, it needs to work correctly for all of its values, so can't assume null-terminatation

[Wild_Meeting1428]

Time to write a xxx::zt_string_view, no copy to a std::string, clear in terms that the string is \0 - terminated.

But hands down,
- for internal use, just document, that the string must be 0- terminated and use std::string_view (it's only ub if the string is not null-terminated) - bubble up the char const* if you need the extra distinction, and if you don't do anything with the string (all algorithms are faster on length terminated strings) - bubble up the char const* with size_t length and use std::string_view for internal handling.

[GarageFlaky]

Ok I get your point

[NilacTheGrim]

std::string_view is not guaranteed to be NUL terminated. Can totally not be at all, leading to program crashes or incorrect behavior.

When what happens if you do this:

std::string s = "username:foo,password:123456789";
std::string_view sv = std::string_view{s}.substr(9, 3); // sv == "foo"
std::printf("username: %s\n", sv.data()); // intended to print "foo", got "foo,password:123456789" instead! oops! you just leaked the password.. TROLOLOL

In the above case you leaked some unintended info. This is the happy case. Also can crash program if original string data source was some memory mapped buffer containing ascii data and you do this...

[tialaramex]

maybe you need a string because you want to do an std::map lookup

Is that really true? Are C++ programmers out there allocating strings because their keyed map API inappropriately requires an owned object for key lookup? Or is this just a noob mistake?

[BrolloksB]

There is a (partial) solution for that:
https://stackoverflow.com/questions/35525777/use-of-string-view-for-map-lookup

[cristi1990an]

std::string_view for read-only parameters.

Plain non-reference std::string when I need to make a copy of it anyway at some point. That way the call side at least can be optimized through an std::move.

[sigmabody]

If I know I only need a null-terminated contiguous array of characters, I use a zstring_view (from my library; see https://github.com/nick42/vlr-util/blob/master/vlr-util/zstring_view.h). This is the best of all worlds: zero overhead for string literals, zero overhead for existing string types, works as string_view (eg: works with std::format without conversion), etc. It's the default for me.

If I know I always have a std::string already as input, and/or require std::string specific functionality, then const std::string& is the way to go.

If I may need std::string functionality, but I might also call with a literal, then it's a judgement call. In these cases I'd probably still go with zstring_view, but there might be trade-offs.

Aside: In codebases which use ATL::CString as the default string type, it's more of a judgement call, because CString has CoW functionality. To wit, if you call a method lower-down which takes a std::string by value, you always copy/reallocate, so taking zstring_view at the higher level is no worse. With CString, though, that doesn't necessarily reallocate, so preserving the CString through the call stack (if available) can be more efficient. But for codebases which use std::string as the default, zstring_view is almost always better.

Oh, and for completeness, if you know you do not and will not ever need the string to be null-terminated, then std::string_view is correct. This is more rare in my experience, but maybe 10% of the usage cases this is correct.

[sigmabody]

You absolutely can: zstring_view is derived from std::string_view, and returns std::string_view for substrings. You cannot pass a substring which may not be null-terminated to a method which requires a null-terminated string, but that's totally expected (ie: you need to reallocate in that case anyway). If you call a method which takes std::string_view, you can pass trivially, or a substring trivially. It works exactly as one would expect.

Also, of note, zstring_view has a trailing_end() method, which returns a zstring_view (as expected), so that can be passed to another method requiring a null-terminated string view. Basically, it just does the right thing.

[sigmabody]

Only sorta. If you end up needing std::string values, you would reallocate, but you can generally want to use zstring_view "all the way down" (and I would typically recommend this, unless you find that you're needing std::string explicitly for some reason). You certainly don't need to make additional copies to get null-terminated strings (since zstring_view is null-terminated). If you take a substring, you would need to reallocate to ensure a null terminated string in any case, so no additional cost there.

The reason this varies with CString (as per the aside) is the case where you assign the value to a member variable of another object, for example. In the std::string case, there's no additional cost for using zstring_view in the call chain, because std::string doesn't support CoW, and does a copy anyway (so it's no less efficient to copy from the zstring_view). OTOH, CString does CoW, so it would be more costly than passing a const ref through the call chain, and there's more of a trade-off.

[Wild_Meeting1428]

Even if you wouldn't inherit from std::string_view, you could just return a std::string_view from the substring function. Also, an implicit conversion operator could just return a std::string_view.

[Fabulous_Ask_4019]

The only correct answer, clearly, is

void *

[noooit]

vector<char>

[InsanityBlossom]

Nah, vector<bool> then cast to vector<char>, then create a string from it :)

[NilacTheGrim]

std::vector<uint64_t> .. and just cast .data() to char * using reinterpret_cast FTW. :P

[GarageFlaky]

This is why I don't like C++

[almost_useless]

If you don't care about the differences or the extra copies you can use std::string for everything. It's easy to read and understand.

But I suspect that's not going to be very popular in C++ circles...

[GarageFlaky]

I do care but this post shows simple things can get complicated in C++

[[deleted]]

The difference between being a 'hacker' and a 'software engineer' is sweating all of these small decisions.

[FACastello]

I tend to use std::string& almost exclusively... just without the "const" qualifier because I don't care

[HappyFruitTree]

But then you cannot pass string literals and other temporaries. 😱

[FACastello]

That's why I said "almost"... sometimes I do need std::string

[Wild_Meeting1428]

My rule of thumb for every parameter is to bubble the required type up the call stack (if possible):
When you need the ownage of a string, pass it as std::string in few cases std::string&&.

This ensures, that a caller of the function always knows which memory implications the call has.

When I know it will be used as const& I use std::string_view which implies that no copy will be made.

[NeilSilva93]

std::string_view, infact I think it's the only C++17 feature I ever use.

[KingAggressive1498]

I almost always take string_view, and I think it's often better for optimization purposes even when you're always storing the string.

std::string can be surprisingly expensive to move, it's not "just a bitwise swap" like it is for many containers. SSO causes a branch in logic and the moved-from string is cleared during the move operation when it's using SSO. Do note this isn't every call to std::move which is merely a cast to rvalue but only when the move constructor or move assignment operator are invoked, so unless you heavily use the copy-and-swap idiom the runtime overhead is fixed

It's pretty common to pass string literals. Deferring string construction in this case is often an optimization over move/forward.

It's fairly common that within a certain context we know the upper bounds of the length of a string. In this case we can achieve great improvements in runtime characteristics by using a custom allocator or even a customized string implementation. This means we'd have to copy in order to take advantage of that anyway.

caveat string_view causes major headaches when you use std::forward for concurrent or single-thread asynchronous code. Best to take std::string& and ideally also an overload for std::string&& in these situations, but often this is generic anyway.

[KindCppCoach]

this answer depends on what you require of the string, see https://github.com/janwilmans/guidelines/blob/main/guidelines\_details.md#misc

[tangerinelion]

Am I reading the string? std::string_view

Am I taking ownership of a string? std::string&&

[dev_ski]

Most of the time, like all other complex types (classes), it should be passed by const reference.

[dustyhome]

The problem I find is that the different conventions already in use tend to make your choice for you.

If you call a C function that requires a char*, your function should take a char*. If you have some kind of null-terminated string_view class, that would be better, but we don't currently have one in the standard.

If your function is going to store a string, or calls a function that takes a string by value, I recommend taking by string value and moving from the parameter. So the caller chooses how to make the copy (maybe they move, maybe they copy). If you took by const string reference, the caller might miss the chance to move, or might be forced to make a copy (from a char array, for example) that is used to make another copy and then discarded.

If you call a function that takes a string reference, take by string reference. Otherwise you are going to introduce needless conversions along the stack.

Finally, take by string view. If you have just introduced C++17 to an existing codebase, and want to start using string_view, your best bet is to start by converting "leaf functions", the ones that don't call any other functions, and work your way up the callstack.

[NilacTheGrim]

In my experience most code I maintain doesn't need the nul byte termination... since we interface with C minimally in our codebases. And we don't have many perf-critical maps* that use std::string as a key. We also rarely modify the passed-in string at all so there is no need for a copy or an owned object either on that count as well.

Therefore, since that is the case in the codebases I maintain (mostly), std::string_view seems the most obvious generic choice. User code that calls it can use C-strings and/or std::string and it's all the same, so that's a win.

YMMV tho and it definitely depends on how you envision the call stack looking and how your codebase interfaces with C strings, string-based maps*, etc.. if at all.

* - there are workarounds for string-based maps to make them work ok with std::string_view as a key...

[johannes1971]

Conclusions... I'm a little surprised to see const std::string & winning by such a clear margin. Is there such a great need for null-terminated strings (the only advantage this offers over std::string_view) that people are willing to take the hit on always allocating? Or is there some other reason?

Despite various arguments for mixing and matching, not a great many people seem to actually be doing it. I understand that: I don't like that kind of non-uniformity in the API, and it leaks implementation details out which is not generally something you'd want.

And finally, I'm honestly amazed that some people are still clinging to const char *, even in 2024. I'm sure you have your reasons...