Your question is about constchar* and you got answers, but if you're dealing with API's that expect char* then that likely mean you'll have to use char*
I'm not sure, but it may be possible to construct std::string from char*, but usually it's much simpler to just deal with what you're faced with.
Use constchar * when you're dealing with string literals and don't need any of the methods that std::string provides. A good example is when you must store the days of the week:
I may be the odd guy out but a few places come to mind:
- code that needs to be serialized. strings can't be read and written to binary files or binary network chunks without going thru hoops to get it back to a fixed size.
- high performance deep code. For example your own number to text routine, to overcome the bad performance of the built in ones.
- most of the time you would use a char array, not pointer, for most of the cases mentioned.
unless performance is very important, using C-strings to get a tiny bit of speed in places where it does not matter is not good. It needs to be necessary, meaning you timed it (therefore coded it) both ways and can show that the increased performance is significant. Code it as string, get it working, and tweak to C only at the very end once proven out.
C-strings are surely not the way to go, because they don't know their size (so optimizations go out the window) and because they require indirection through a pointer, unlike short C++ strings. There are other options that are better in some circumstances than std::string of course, but they are not C strings.
depends on what you are doing. the size isn't critical for a lot of operations, where you can loop until you hit the zero. If you must you can pascal string it and use the back end as c-string after the size info byte(s). Most readers tell you how many you read in, so it can be pretty slick with minimal rewriting. Constantly iterating to get the sizes is awful for sure.
tiny string optimize is a whole field unto itself. If the strings will all fit into some integer type, for example 8 chars in 64 bit ints in ascii.... you can really make those scream.
tiny string optimize is a whole field unto itself. If the strings will all fit into some integer type, for example 8 chars in 64 bit ints in ascii.... you can really make those scream.
I don't think it's a forgone conclusion that a small string will be more efficiently handled in a std::string (with small string optimization) than a char*. Yes, you have to follow a pointer with char*, but there's extra stuff in the std::string code to handle the small string, at least some conditionals, which accessing the char* doesn't have. Although it's probably more likely that the std::string data will be in the cache since it's on the stack.
BTW, you can find out your small string limit like so:
1 2 3 4 5 6 7 8 9
#include <iostream>
#include <string>
int main() {
std::string s{"a"};
// prints 15 for me
// (presumably two 8-byte pointers - 1 for '\0')
std::cout << s.capacity() << '\n';
}
Another case are dynamic link libraries that may be consumed by other languages like C, ...
That's interfacing to C.
Use const char * when you're dealing with string literals and don't need any of the methods that std::string provides. A good example is when you must store the days of the week:
You should be using std::string_view. Ever written any C that uses zero copy strings, then abstracted that stuff out? You end up with something equivalent to std::string_view.
depends on what you are doing. the size isn't critical for a lot of operations, ...
Again, std::string_view is faster.
tiny string optimize is a whole field unto itself. If the strings will all fit into some integer type, for example 8 chars in 64 bit ints in ascii.... you can really make those scream.
That's something to consider, but that's a special case.
But really, you shouldn't use char arrays to represent strings in C++.