Adding To A Class

[Technocrat]

This might not be possible but I thought I would ask. Is there any way to append public functions to a class with out editing source code?

What I mean is I am almost finished creating a bunch of custom functions for STL strings and it would be really nice to have be a part of any var that uses STL strings. For example I have a trim function, it would be nice just to do this:

string s;
s = "blahblah";
s.trim();

Or is there another way to do this that I am not thinking of?

[MXK]

The only thing that comes to my mind is creating a "friend" function. Don't remember the exect syntax of it, but it will basically give that function access to all private variables of that class. The problem for you, I think, is that you don't really know what private variables string has (might be wrong on that, I never use string class)...

[parksie]

You can't know. The internals of the basic_string class are implementation-specific.

You could always derive from basic_string if you wanted.

[Technocrat]

I think that is something along the same lines as what some one else suggested:

std::string does not have a rich supply of functions. I've always used it as a starting point by creating my own class and using std::string through containment. I use containment because std::string is not meant to be inherited from, as can be seen by the lack of a virtual destructor.

starting point:

class MyString
{
public:
// your complete interface here...
private:
std::string m_string;
};

Any one care to give me some more code to point me in the right direction.

[Zaei]

You can derive from std::basic_string as long as nothing you do needs to be undone in a constructor. Trim functions and other manipulations are fine to do this with. That also saves you from having to reimplement the things std::basic_string does for you.

Z.

[CornedBee]

Yep. Virtual destructors are only a necessary if you fear that delete might get called on a pointer to a base class that actually points to a derived class that needs to do something important in its destructor.


There is no way to add methods to an existing class.
You can't even make some function of yours a friend of an existing class - the friend declaration must be inside the class.

[Technocrat]

This is what some one is suggesting:

class MyString
{
public:
// various constructors here. Default, one taking const char*,
// etc.

// provide for implicit cast to const char*. Some argue against
// this, but I fiind it convenient.
operator const char*() const
{
return m_string.c_str();
}

void trim()
{
// your trim implementation here
}

// etc. etc. etc.

private:
std::string m_string;
};


Simply build up your own ideal string class by adding public methods that operate on the m_string member. You could provide an operator[], size(), empty(), subst(), trimLeft(), trimRight(), upper(), lower(), isalpha(), whatever you desire.

[MXK]

Keep in mind that when you define functions within the class declaration those functions are automatically inline, might present some problems with long functions.

[Zaei]

Originally posted by Technocrat
This is what some one is suggesting:
...
Simply build up your own ideal string class by adding public methods that operate on the m_string member. You could provide an operator[], size(), empty(), subst(), trimLeft(), trimRight(), upper(), lower(), isalpha(), whatever you desire.

Yes, but most of those are already implemented by std::basic_string... why add another layer of function calls, or, more to the point, why spend all that time typing them out when you can simply derive from std::basic_string?

Z.

[Technocrat]

Originally posted by Zaei
Yes, but most of those are already implemented by std::basic_string... why add another layer of function calls, or, more to the point, why spend all that time typing them out when you can simply derive from std::basic_string?

Z.

Can you give me a quick code to show me how you might do that?

[CornedBee]

template<typename C, typename T = std::char_traits<C>, typename A = std::allocator<C> >
class not_so_basic_string : public std::basic_string<C, T, A>
{
  // bla bla bla
};

You MUST add all those constructors std::basic_string has, else you can't use them.

[Zaei]

#include <string>

template<typename E, typename T = std::char_traits<E>, typename A = std::allocator<E> >
class my_basic_string : public std::basic_string<E, T, A>
{
public:
  /**/ trim(/**/);
  // your new functions here
};

typedef my_string my_basic_string<char>;

Should work, methinks.

Z.

[Technocrat]

Hmm sorry Zei but your code didnt compile, but Cornedbee's did.

[Zaei]

Whoops, forgot a word

Z.

[Technocrat]

Yeah I guess class is important I missed it too

[Technocrat]

Man I keep thinking I should have just taken no for an answer. Ok someone had this to say:

There are two reasons not to inherity from basic_string:

1. You aren't supposed to. There is no virtual destructor in basic_string, hence it's not meant to be inherited from.

2. You have less control over the interface. It's possible to get in a position where you don't want the user to call certain methods.

A better solution would be:

template<typename C, typename T = char_traits<C>, typename A = allocator<C> >
class not_so_basic_string
{
public:
// All methods;
private:
std::basic_string<C, T, A> m_string;
}

[Zaei]

Originally posted by Technocrat
Man I keep thinking I should have just taken no for an answer. Ok someone had this to say:

There are two reasons not to inherity from basic_string:

1. You aren't supposed to. There is no virtual destructor in basic_string, hence it's not meant to be inherited from.

2. You have less control over the interface. It's possible to get in a position where you don't want the user to call certain methods.

A better solution would be:

template<typename C, typename T = char_traits<C>, typename A = allocator<C> >
class not_so_basic_string
{
public:
// All methods;
private:
std::basic_string<C, T, A> m_string;
}

There is no virtual destructor in std::basic_string because a virtual destructor adds a virtual function table to every instance of the class, thus, a size increase, and a performance penalty. As long as you follow the rules of inheritance correctly, there is no reason you cannot inherit from std::basic_string because it doesnt have a virtual destructor.

Adding your own interface gives you a function call penalty everytime you call a normal std::basic_string member, on top of the normal speed of the call. I am also at a loss for any reason you would want to limit the calling of certain members.

Z.

[Technocrat]

Templates are a bit pass me because I havent gotten around to learn them, but your logic makes sense. It seems to me his solution will cause a great deal of over head and performace issues when alot of these classes are created.

I am more inclined to believe your answer than his anyways.

Thanks.

[parksie]

Originally posted by Zaei
There is no virtual destructor in std::basic_string because a virtual destructor adds a virtual function table to every instance of the class, thus, a size increase, and a performance penalty. As long as you follow the rules of inheritance correctly, there is no reason you cannot inherit from std::basic_string because it doesnt have a virtual destructor.

Adding your own interface gives you a function call penalty everytime you call a normal std::basic_string member, on top of the normal speed of the call. I am also at a loss for any reason you would want to limit the calling of certain members.

Z.

If you use inline functions, then any real function calls should not be affected. Most basic_string calls end up inlined anyway.

[Zaei]

Originally posted by parksie
If you use inline functions, then any real function calls should not be affected. Most basic_string calls end up inlined anyway.

Only if your compiler inlines

Z.

[parksie]

If it doesn't then either fix it or get a better one

[Zaei]

Originally posted by parksie
If it doesn't then either fix it or get a better one

Bad argument, eh?

I know what you mean... but inheriting still saves you a lot of typing to write your own interface =)

Z.

[CornedBee]

Zaei: your code has another problem: it allocates char_traits<C> objects instead of C objects.

Another thing we both forgot: char_traits and allocator both come from std too. I edited my post.

[Zaei]

Originally posted by CornedBee
Zaei: your code has another problem: it allocates char_traits<C> objects instead of C objects.

Another thing we both forgot: char_traits and allocator both come from std too. I edited my post.

Would you be surprised to know that I copied and pasted the template declaration from MSDN, the changed "class" to "typename"?

Z.

[CornedBee]

It's still wrong.