Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

johnnyBravo

why not to use char * for strings?

This topic is 5390 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

people are saying not to use char * for a string. How come? eg char * myString; or char * myMethod() { return "hi"; } And why not use LPSTR instead of std::string as the second one doesnt work with methods...? [edited by - johnnyBravo on October 14, 2003 7:55:25 AM]

Share this post


Link to post
Share on other sites
Advertisement
Because you need to (de)allocate memory for the strings yourself if they''re char pointers. And you can''t use operators to concatenate or copy strings. These together account to ugly code with lots of potential bugs, since you''ll forget to (de)allocate memory anyway.

Share this post


Link to post
Share on other sites
I''ll answer the 2nd question first. LPCSTR is Windows-specific. I haven''t done much windows programming, but won''t functions that accept LPCSTR accept a null-terminated C string? If so, you can use std::string::c_str().

Why use std::string instead of char *? You can eliminate a large class of memory problems by doing so. For static data, it''s not so much of an issue:

const char * PROG_NAME = "MyProgram";

But for variable length strings, I''d rather let std::string handle the memory management and resizing.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Share this post


Link to post
Share on other sites
Don''t listen to what people tell you, only use strings where you need them, eg you manipulate the string or such, and don''t use them as arguments for any type of interface that you want to maintain any binary compatibility for, or want to use from another language.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by johnnyBravo
char * myMethod()
{
return "hi";
}


Doesn''t that give you a memory error? If not, it''s probably more luck than anything else. Anyway, having a function return a pointer to a local variable that''s popped from the stack when the function exits, is one of the Two Mortal Sins of C programming (the other one is to malloc() without free()). Even if it works in this case, it''s still a really bad habit.
quote:

And why not use LPSTR instead of std::string as the second one doesnt work with methods...?


What? Of course std::string works with methods. Why wouldn''t it?

Share this post


Link to post
Share on other sites
I myself like to use char* instead of std::string.

Firstly its faster;
Secondly I'm comfortble with it; and
Thirdly even though I know I have to manage the memory for it, it keeps me from slacking off into the lazy chair and I know exactly whats going on.

Sure the std::string is comfortable to work with and does everything for you but if you have an array that is supposed to hold about 10,000 strings, then you are wasting a lot of RAM!

Well this topic depends on how well you know c-strings and for what purpose.

I'm not going to force you to use c-pointers but know that some time you are going to use it (or have to use it) and for that you need to know how it works.


// Last Attacker \\---=( LA )=---// LA Extreme \\

ICQ Number : 120585863

E-mail: laextr@icqmail.com

[edited by - Last Attacker on October 14, 2003 8:49:14 AM]

Share this post


Link to post
Share on other sites
AnonymousPoster brought up a good point about interfacing with other languages. That''s something to consider.

As with every decision, there are tradeoffs with each option. You have to choose which is best for your program.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

Share this post


Link to post
Share on other sites
People usually say use std::string becuase they assume you''re too damn retarded to deal with memory yourself.

Remember that std::string is a reasonably lightweight way to have a more or less nice string class. Sometimes it''s appropriate, and sometimes it''s not. Occasionally I''ll just create a 500char array and mess with it if I''m feeling lazy, and I nearly always use char* return types rather than std::string. Especially for DLL type stuff, where it''s conceivable that other languages might actually want to access the stuff.

LPSTR is something like this:
typedef char* LPSTR;
You probably won''t find that exact line in the windows headers, but when you hack through it all, that''s what you get. It''s nothing special.

As long as you can handle memory well, there''s nothing wrong with char*. I usually use std::string in places I don''t want to have explicit deletion, e.g. as a member of a struct that has a string in it, but for which i don''t want to write a destructor. std::string also has its nice concatenation operator, if you like that sort of thing.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Last Attacker
Sure the std::string is comfortable to work with and does everything for you but if you have an array that is supposed to hold about 10,000 strings, then you are wasting a lot of RAM!


Not really, not if you''re reasonably careful. That is, don''t force std::string to reallocate more than nessecary. Use reserve() and some good judgement.

IMHO char* is fine for constant strings, but when dealing with variable-sized strings, std::string is far superior on all possible levels. realloc() anyone? (*shudder*).

Share this post


Link to post
Share on other sites
As with all things in programming its a matter of the right tool for the right job, sometimes using a char * is needed, others you can use std::string.

Personaly i tend towards std::string as it saves me having to write string manip stuff myself and its just natural to use when using the rest of the STL.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!