char[] (c lang) to string (c++ lang) conversion

Question

I can see that almost all modern APIs are developed in the C language. There are reasons for that: processing speed, low level language, cross platform and so on.

Nowadays, I program in C++ because of its Object Orientation, the use of string, the STL but, mainly because it is a better C.

However when my C++ programs need to interact with C APIs I really get upset when I need to convert char[] types to C++ strings, then operate on these strings using its powerful methods, and finally convert from theses strings to char[] again (because the API needs to receive char[]).

If I repeat these operations for millions of records the processing times are higher because of the conversion task. For that simple reason, I feel that char[] is an obstacle in the moment to assume the C++ as a better c.

I would like to know if you feel the same, if not (I hope so!) I really would like to know which is the best way for C++ to coexist with char[] types without doing those awful conversions. Thanks for your attention.

Answer 1

I'm not sure what you mean by "conversion", but won't the following suffice for moving between char*, char[], and std::string?

char[] charString = {'a', 'b', 'c', '\0'};
std::string standardString(&charString[0]);
const char* stringPointer(standardString.c_str());

Answer 2

If you use std::vector<char> instead of std::string, the underlying storage will be a C array that can be accessed with &someVec[0]. However, you do lose a lot of std::string conveniences such as operator+.

That said, I'd suggest just avoiding C APIs that mutate strings as much as possible. If you need to pass an immutable string to a C function, you can use c_str(), which is fast and non-copying on most std::string implementations.

Answer 3

I don't think it's as bad as you make it out to be.

There is a cost converting a char[] to a std::string, but if you're going to be modifying the string, you have to pay that cost anyway whether converting to a std::string or copying to another char[] buffer.

The conversion going the other way (via string.c_str()) is usually trivial. It's usually returning a pointer to an internal buffer (just don't give that buffer to code that will modify it).

Answer 4

I'm not sure why you would be constrained to using C strings and still have an environment that runs C++ code but if you really don't want the overhead of conversion, than don't convert. Just write routines that operate on the C strings.

Another reason for converting to C++ style strings is for bound safety.

Answer 5

"... because it is a better C."

Baloney. C++ is a vastly inferior dialect of C. The problems it solves are trivial, the problems it brings, much worse than those it solves.

Answer 6

The C++ string class has a lot of problems, and yes, what you're describing is one of them.

More specifically, there is no way to do string processing without creating a copy of the string, which may be expensive.

And because virtually all string processing algorithms are implemented as class members, they can only be used on the string class.

A solution you might want to experiment with is the combination of Boost.Range and Boost.StringAlgo.

Range allows you to create sequences out of a pair of iterators. They don't take ownership of the data, so they don't copy the string. they just point to the beginning and end of your char* string.

And Boost.StringAlgo implements all the common string operations as non-member functions, that can be applied to any sequence of characters. Such as, for example, a Boost range.

The combination of these two libraries pretty much solve the problem. They let you avoid having to copy your strings to process them.

Another solution might be to store your string data as std::string's all the time. When you need to pass a char* to some API functoin, simply pass it the address of the first character. (&str[0]).

The problem with this second approach is that std::string doesn't guarantee that its string buffer is null-terminated, so you either have to rely on implementation details, or manually add a null byte as part of the string.