ansaurus

Question

use of char * vs std::string in different environments

Answer 1

+11 A:

std::string is part of the C++ Standard, and has been since 1998. It is available in all the current C++ compilers. There really is no portability reason not to use it. If you have an API that needs to use a C-style string, you can use the std::string's c_str() member to get one from a string:

std::string s = "foo";
int n = strlen( s.c_str() );

anon 2010-02-02 16:07:20

Answer 2

+1 A:

Using a char * you are sure that you will not get portability issues among libraries.
If a library exports a function that uses an std::string, it might have problems communicating with another library that has been linked against a different version of the standard library.

Paolo Tedesco 2010-02-02 16:08:13

You will have similar possible problems with char * if the thing being allocated to the char * is deallocated in a different library.

anon 2010-02-02 16:25:40

@Neil: Well, that's a different kind of problem. Please note that I'm not encouraging the use of char* per se, I'm just saying that this could be a possible source of problems with std::strings, since the question is "someone suggested that... is it true?"

Paolo Tedesco 2010-02-02 16:31:51

@Neil: that's true, but many APIs don't pass ownership of memory around - if all you do is read and write within the limits of my char* buffer, I don't care how you allocate memory. Whereas any use of a `std::string` can go wrong if the libraries aren't compatible. So, while it's possible to go wrong when using `char*`, there are many things you can do. With std::string, you simply can't call across the library incompatibility boundary at all. So whether char* is any better depends whether "I would need to do some memory management" in the question means, "across the boundary", or not.

Steve Jessop 2010-02-02 16:34:25

I am currently working on this code in unix which has a console interface. however i will be providing a static library (dll) for win environment. In that case should i be working with char * arrays instead? I don't want to do extra work for the windows platform anymore than is necessary. which means that if i know i will have to remove the console functionality. however, other than providing apis i want my code to be seemeless....which from what you guys are saying seems like i would need to stick with char * instead of std::strings.

djones2010 2010-02-02 16:46:18

@unknown Your original question was about portability, but it seems you should have been asking about library API design. The two issues are somewhat related, but by no means the same. It may be a good idea to ask a new question (don't edit this one) explaining exactly what you want to do, and not using words like "porting" if you are not sure of their meaning.

anon 2010-02-02 17:18:48

ok will do. thanks

djones2010 2010-02-02 17:23:57

Answer 3

A:

In C++, almost every string should be std::string unless another library requires a cstring, in which case you should still be using an std::string and passing string.c_str(), unless you're using functions that work with buffers.

However, if you're writing a library and exporting functions, it's better to use const char* parameters rather than std::string parameters for portability.

dauphic 2010-02-02 16:08:28

for portability? in the aforementioned discussion people seem to suggest that w/e issues would plague char * would also be the same for std::string. i am not sure i get that. Also, can you elaborate on what you mean by using buffers? The reason I ask that is because although I am writing this code on unix that will have a console interface. the windows version of this will be a dll and will most likely have api that will be called by third party programs.

djones2010 2010-02-02 16:39:29

const char* will be the exact same no matter who/what is using your code. std::string may not, especially if you're statically linked with the C++ runtime. If I compile and export a function void foo(const std::string) into a static library using C++ runtime 2.0, then compile and ship it to a client who uses C++ runtime 1.8, which doesn't use the same string implementation, things will blow up because their std::string isn't what my program expects when it wants an std::string

dauphic 2010-02-02 16:58:06

so basically i have to modify my code to remove all instances of the std::string and change it to char *. this is what I am understanding in order to not have any issues.

djones2010 2010-02-02 17:06:34

You don't have to, it's just more portable to make exported functions take const char*; if they aren't exported, they can take std::string without any problems. Either way, I construct an std::string with a char* after it's been passed, since C++ code should always use std::string where possible.

dauphic 2010-02-02 17:15:16

Answer 4

+1 A:

I think that there is nothing to worry about unless you are going to provide some API to 3rd party.

Just use std::string

Mykola Golubyev 2010-02-02 16:08:26

Answer 5

A:

There's nothing unportable about std::string that isn't also an issue with char *. std::string actually uses a char * internally...

Peter Alexander 2010-02-02 16:08:36

Answer 6

A:

string is better. There is nothing unreliable about it on any platform. If you're worried about passing large classes, you can pass const references of your strings into functions. Makes coding faster and less bug prone.

Chris H 2010-02-02 16:08:39

Answer 7

A:

In addition to the fact thata it's easier, std::string will probably be more efficient. Its small string optimization can keep the 10 digits in the std::string object itself, instead of putting them in another memory block off the heap.

MSalters 2010-02-02 16:09:48

ansaurus

tags:

views:

answers:

use of char * vs std::string in different environments

related questions