Jump to content
  • Advertisement
Sign in to follow this  
Genjix

string vs const char*

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

assuming nothings being done with the string, only read which would you choose? I often find myself using const char* over string because of compatibility with C functions and less hassle/overhead, whereas with strings I know everything is safer. What are you're thoughts on this? Is this necessarily a bad thing?

Share this post


Link to post
Share on other sites
Advertisement
If you don't need to manipulate it at all (not even save copies) then there's really no downside to using char pointers.

Share this post


Link to post
Share on other sites
You could use const std::string references, that way it's even safer. [smile]

But yeah, I'd probably just use const char*'s for something like that, and I usually do unless I'm doing some funky parsing.

Share this post


Link to post
Share on other sites
Well, here's why I use std::string, or references thereof religiously:

1) pro pro ______: Consistancy. This is a reason to use one or the other rather than one specifically.
2) pro pro string: Simplicity and Safety. std::string > char * for manipulation.
3) con pro char[]: Speed shouldn't be an issue with strings, and thus I do not rank it as sufficient reason to use a char array of any sort. Strings are meant for display on a screen, and the cost of that makes a little un-necessary copying from const char * to an internal buffer of std::string minor - assuming you're not trying to store an entire book in a single string or something equally stupid.

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
3) con pro char[]: Speed shouldn't be an issue with strings, and thus I do not rank it as sufficient reason to use a char array of any sort. Strings are meant for display on a screen, and the cost of that makes a little un-necessary copying from const char * to an internal buffer of std::string minor - assuming you're not trying to store an entire book in a single string or something equally stupid.
This is, of course, highly application specific.
Games rarely perform much string manipulation but many other high-performance systems rely heavily on it, especially parsing.

Using std::string instead of char pointers isn't necessarily much slower, in fact it can often be faster since the string stores its size directly. Instead the danger lies in having an abstraction that lets us ignore what's actually going on.
Just don't pretend that information hiding is an absolute good.

Share this post


Link to post
Share on other sites
Quote:
Original post by Genjix
assuming nothings being done with the string, only read which would you choose? I often find myself using const char* over string because of compatibility with C functions and less hassle/overhead, whereas with strings I know everything is safer. What are you're thoughts on this? Is this necessarily a bad thing?


If "nothing's being done", why is "compatibility with C functions" or "hassle" an issue? In fact, why bother declaring the variable at all? :P

Basically I use std::string if I can, const char* if I have to.

Share this post


Link to post
Share on other sites
the only time I use const char* is for declaring constants. it avoids order of initialisation issues with static const std::strings

Share this post


Link to post
Share on other sites
O V E R L O A D

foo::mess_with_string(const char* str)
{
//do my business
}

inline foo::mess_with_string(const std::string& str)
{
this->mess_with_string(str.c_str());
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!