Avatar of woigl
woigl asked on

Extend standard String class

I would like to create my own class which will inherit from std::string.

my questions:
1.) will i get the whole functionality from std::string into my class?
2.) or is there any better way as to extend the basic string class?

class gpslib::lang::String : public std::string {
};
Visual C++.NET

Avatar of undefined
Last Comment
itsmeandnobodyelse

8/22/2022 - Mon
SOLUTION
lucky_james

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Jaime Olivares

1) yes
2) no
ASKER
woigl

So what you suggest me for having the std::string in my class and to be able to extend it?
Jaime Olivares

That depends on what you name as "extending"
if you want to add some functions, inheriting is the best option, IMHO.
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
SOLUTION
Infinity08

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
ASKER
woigl

Well, that is even an option...

But then i have to write all my constructors, operators and functions by myself?

My idea would be to get the typical strng functions and to be able to extend with somemore new functions wihout to much work!
ASKER CERTIFIED SOLUTION
Log in to continue reading
Log In
Sign up - Free for 7 days
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
Infinity08

>> The disadvantage is that you need to reimplement *all* functions of std::string and you additionally have to proviode functions to convert from std::string and back to std::string.

Correct. But it would be a lot more "sturdy" imo ... and doesn't depend on assumptions like : "the user of the class shouldn't use the class polymorphically with std::string"
Bob Learned

C# 2008 will allow you to an extender methods for the String class, but I don't believe that 2005 supports it.

Extension Methods
http://blogs.vbcity.com/mcintyre/archive/2007/09/21/8721.aspx

Bob
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
Infinity08

>> C#

This is about C++ ...
Bob Learned

Yes, I know, but that means that the .NET framework won't support it until 2008, so that means C++, too.

Bob
itsmeandnobodyelse

>>>> "the user of the class shouldn't use the class polymorphically with std::string"
std::string is a template class where you have the full source code. You simply can make the destructor virtual and would get rid of that limitation.

I think that 'using std::string in a polymorphically way' is a rather academical question. You don't do it now, why should anyone do it later? In our system with 10 millions of lines of code, we had only one string class and it was only a few isolated cases where MFC CString was used and in some newer code where std::string was used. So when we changed our own string class, we easily could have derived it from std::string and we had not one single case where the polymorphical use would have been an issue. The only reason why we changed to the containment way was that there was an open question how to pass STL objects between dlls in a safely way. To keep the chance to replace std::string by an own string if necessary we used the method that let us make this easier. Later it turned out that we would have been safe with both ways but then the implementation already was completed.

Your help has saved me hundreds of hours of internet surfing.
fblack61
Infinity08

>> I think that 'using std::string in a polymorphically way' is a rather academical question.

If you're the user of your own class, then it's easy. If you let your class be used by others, then at some time, somebody will want to do it (and more than you think).

It also depends on what kind of extension we're talking about. Assume that I want to create an extension of std::string that limits the size of the string to a maximum size. Why would it be so unthinkable that at some point you want a container that stores both std::string's and LimitedString's ?
itsmeandnobodyelse

>>>> Why would it be so unthinkable that at some point
>>>> you want a container that stores both std::string's and LimitedString's ?
It is not unthinkable but you will not do it if your string class isn't a specialization of std::string (like the sample LimitedString implies) but a replacement. As I told we had a own class which was used everywhere and it has no importance how it was implemented. Going back to std::string would have been a step backwards, a loss of known comfortability. Moreover, to get the polymorphical issue, you have to use baseclass pointers or baseclass references. String pointers generally are of less importance (I can't remember a project out of hundreds where I ever used a string pointer). And baseclass references are only useful for baseclass member functions or if using a predefined interface. Note, std::string has not a single member function which deletes a string object passed by pointer or reference. So, if you don't make strange functions like

     void MyString::oddfunc(std::string* pstr)
     {
          delete pstr;
     }

you won't get any problems.

It is similar to MFC CString: though you have writeable access to the internal char buffer of it you wouldn't use functions like strcpy, strcat, strcmp cause it is no benefit but only problems when doing so. Of course it is a big difference whether you create a tool library or a a big application package. For the latter the usage of pure standard classes is of minor importance. For example, we used MFC but any of the GUI classes was derived (even multiple derived) and we never used the MFC baseclass in the interface.
Infinity08

I'll agree that if you know what you're doing, and know the limitations of deriving from std::string, there shouldn't be a problem. But those are two prerequisites that I wanted to be sure woigl knew about, and that what he intends to do with the derived string class is conform these prerequisites.

One last point I'd like to make : why do you think that std::string wasn't designed to be derived from ... and why go against that design decision ?
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
itsmeandnobodyelse

>>>> why do you think that std::string wasn't designed to be derived from
Hmmm. I was told to make a virtual destructor for any baseclass. I couldn't think that the designer of the std::string didn't agree to that. So, std::string doesn't seem to be designed as a baseclass.


>>>> ... and why go against that design decision ?
As told it makes a difference whether you make a tool library for external use or if you are 'using' a helper class to implement a own string class for a project or a company's software. In the latter case you must not make up restrictions which only are valid for the first case. It is like portability restrictions. If using the application frames of MFC or Windows Forms, I must not care whether to use Windows API or POSIX functions, I simply can use that what is defined in the project standards or where I am used to. I personally use the portable function if I have the choice. Nevertheless only one of hundred projects I made actually needs portability.

>>>> But those are two prerequisites that I wanted to be sure woigl knew about
No problem. I already told you that we decided for containment as well. I do not recommend for the one or the other, I only want to make clear that from my experience there is nothing relevant in praxis what speaks against to deriving from std::string.