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 {
};
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 {
};
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
So what you suggest me for having the std::string in my class and to be able to extend it?
That depends on what you name as "extending"
if you want to add some functions, inheriting is the best option, IMHO.
if you want to add some functions, inheriting is the best option, IMHO.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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!
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> 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"
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"
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
Extension Methods
http://blogs.vbcity.com/mcintyre/archive/2007/09/21/8721.aspx
Bob
>> C#
This is about C++ ...
This is about C++ ...
Yes, I know, but that means that the .NET framework won't support it until 2008, so that means C++, too.
Bob
Bob
>>>> "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.
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.
>> 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 ?
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 ?
>>>> 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::str
{
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.
>>>> 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::str
{
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.
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 ?
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 ?
>>>> 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.
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.
2) no