Jump to content
  • Advertisement
Sign in to follow this  
paic

A custom String class BASED ON std::string

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

Hi, I'm still playing with strings, and now, I'd like to test std::strings. But I want to have the same method names, functionalities than my own string class. So my question is : what's the best way of doing that. I thought of : 1) Create a class which inherit from std::string. I would have my methods that simply call the std::string equivalent, or implement it if it doesn't exists in std::string. 2) Create a class which stores a std::string. Is there any other way ? And what's the best (I mean the cleanest and most efficient) way ? Thx for any advice.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Either way is fine but DO NOT use public inheritance from an STL container (e.g. std::string). They don't have virtual descructors, that's one reason. You can use "using" declarations for the methods that are same as in std::string superclass:

struct A { //"std::string"
void foo() {...}
};

struct B : private A { //"mystring"
using A::foo;
};

Now you can do

B b;
b.foo();

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Either way is fine but DO NOT use public inheritance from an STL container (e.g. std::string). They don't have virtual descructors, that's one reason.


Never say never [wink], it's okay (as in not exactly a great idea never-the-less) as long as you aware of the predicaments of doing such things. That is no dynamic binding of methods (since there are no viritual member functions in std::basic_string), undefined behaviour when invoking delete on pointers to the base type (basic_string in this case since it does not have a virtual destructor).

@paic - making a wrapper around std::basic_string (std::string is a type alias for std::basic_string) with all wrapper functions inlined wont effect efficiency in anyway but as with any form of "wrapping" it's annoying to write them.

Personally i think it would better do as the boost string algorithms library does, just extend it by writing generic algorithms that can work on any string type. In fact take a look at boost string algorithms library [grin].

[Edited by - snk_kid on November 21, 2005 5:38:56 AM]

Share this post


Link to post
Share on other sites
Hi,

You can either have a member variable of std::string or privately inherit from std::string.

However, given what I've seen of what you want to do so far, I'd say you'd be better off using free functions to accomplish what you want:

e.g. instead of:
void String::toIntArray(char seperator, int* array);

consider doing:

std::vector<int> toIntVector(const std::string& String, char seperator);

PS. I 'm working on an email with more comments about your stirng class.


Share this post


Link to post
Share on other sites
So, the reason I shouldn't have "class myString : public std::string" is because the destructor of std::string won't be called ?
I may ask something stupid here, but isn't it possible to explicitely call the std::string destructor is the destructor of myString (the same way you can call its constructor) ??
(that's just for my knowledge ^^)

Nitage, thx for the help, I'll read your mail when I get it ^^ For what you said, I can't : I already use my string class, so I really have to keep the same structure / method names / etc. (I can't use "free functions" like the one you gave as an example)

I think I'll store a std::string and inline wrapper functions for the moment. I still feel reticent to use boost, so maybe in the future when I have some time, I'll look more carefully into it.

Thx for the help ^^

Share this post


Link to post
Share on other sites
Quote:
Original post by paic
So, the reason I shouldn't have "class myString : public std::string" is because the destructor of std::string won't be called ?


Nope. The destructor for your class won't be called if you are deleting a pointer to the base class. By deriving from std::string privately, not only do you make the members of std::string inaccessible outside of your class, but you also prevent a pointer to your class from being cast to a pointer of its base (which in turn prevents the above problem).

Quote:
I may ask something stupid here, but isn't it possible to explicitely call the std::string destructor is the destructor of myString (the same way you can call its constructor) ??


While I believe the compiler will let you, it won't do what you're thinking. Because std::string doesn't have a virtual destructor, when you try and delete a (std::string*) that actually points to your class only std::string's destructor will be called. However, if your class's destructor will still call std::string's destructor as normal if it gets called. By calling it yourself you'll be trying to deconstruct the std::string twice.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!