Hi all,

I am thinking of subclassing the standard string class so I can do
something like:

mystring str;
....
str.toLower ();

A quick search on this newsgroup has found messages by others
suggesting that subclassing a standard class is a bad idea, especially
for beginners...

Can someone suggest what is the recommended way to add functionality
to (say) the string class? Actually, I would like to do other things
to strings, and toLower is just one of them. Is it better or is the
only way to just perform a function call:

toLower (string s)

[Of course, there is a C function with the same name, so something
similar to it.]

Another way is to create a class with a private member variable "data"
of type string I should add that I'm somewhat motivated by efficiency
as these tasks with strings will be performed very often.

Which of these two is recommended? Or is there a third that I have
not thought of?

Thank you!

Ray

Ray wrote:
> I am thinking of subclassing the standard string class so I can do
> something like:
>
> mystring str;
> ...
> str.toLower ();
>
> A quick search on this newsgroup has found messages by others
> suggesting that subclassing a standard class is a bad idea, especially
> for beginners...

I actually don't even like the term "subclassing"...

> Can someone suggest what is the recommended way to add functionality
> to (say) the string class? Actually, I would like to do other things
> to strings, and toLower is just one of them. Is it better or is the
> only way to just perform a function call:
>
> toLower (string s)

string toLower(string const& s);

>
> [Of course, there is a C function with the same name, so something
> similar to it.]

There is no C function with the same name. It's 'tolower' (no capital
letter).

> Another way is to create a class with a private member variable "data"
> of type string I should add that I'm somewhat motivated by efficiency
> as these tasks with strings will be performed very often.
>
> Which of these two is recommended? Or is there a third that I have
> not thought of?

Stand-alone functions are better than members of the class deriving from
the standard class. At least with those you could expect application of
conversions (standard and user-defined).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

* Victor Bazarov:
>
> Stand-alone functions are better than members of the class deriving from
> the standard class. At least with those you could expect application of
> conversions (standard and user-defined).

Huh?

Consider

struct M {};
void foo( M& );

versus

struct M { void foo(); };

With the former you can write

M o;
foo( o );

With the latter you can write

M().foo();

If foo is an operator like << this can be of practical significance.


Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:
> * Victor Bazarov:
>>
>> Stand-alone functions are better than members of the class deriving
>> from the standard class. At least with those you could expect
>> application of conversions (standard and user-defined).
>
> Huh?

If you have a function that can uppercase a string, it's better if you
make it a non-member because a class that defines a conversion to a
string, cannot be used with a member.

Consider

class M {};
void foo(M&);
class L { public: operator M&(); };

versus

class M { public: foo(); };
class L { public: operator M&(); };

With the former you can have

L l;
foo(l);

but with the latter you can't do

L l;
l.foo();

>
> Consider
>
> struct M {};
> void foo( M& );
>
> versus
>
> struct M { void foo(); };
>
> With the former you can write
>
> M o;
> foo( o );
>
> With the latter you can write
>
> M().foo();
>
> If foo is an operator like << this can be of practical significance.

Huh?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

* Victor Bazarov:
> Alf P. Steinbach wrote:
>> * Victor Bazarov:
>>>
>>> Stand-alone functions are better than members of the class deriving
>>> from the standard class. At least with those you could expect
>>> application of conversions (standard and user-defined).
>>
>> Huh?
>
> If you have a function that can uppercase a string, it's better if you
> make it a non-member because a class that defines a conversion to a
> string, cannot be used with a member.
>
> Consider
>
> class M {};
> void foo(M&);
> class L { public: operator M&(); };
>
> versus
>
> class M { public: foo(); };
> class L { public: operator M&(); };
>
> With the former you can have
>
> L l;
> foo(l);
>
> but with the latter you can't do
>
> L l;
> l.foo();

Reference operators are bad 'uns generally, but for latter you could just
static_cast<M&>(l).foo(), and even static_cast<M&>(L()).foo().

But I think the above misses the point, by introducing that conversion to reference.


>> Consider
>>
>> struct M {};
>> void foo( M& );
>>
>> versus
>>
>> struct M { void foo(); };
>>
>> With the former you can write
>>
>> M o;
>> foo( o );
>>
>> With the latter you can write
>>
>> M().foo();
>>
>> If foo is an operator like << this can be of practical significance.
>
> Huh?

Like the old problem with temporary std:stringstream() << "blah".


Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Ray wrote:

> Can someone suggest what is the recommended way to add functionality
> to (say) the string class? Actually, I would like to do other things
> to strings, and toLower is just one of them.

Why not use the String Algorithms library in Boost?
http://www.boost.org/doc/libs/1_35_0...ring_algo.html

It may already offer most of the functionality you need, including case
conversion algorithms.

std::string source = "FooBar";
boost::algorithm::to_lower(source);
std::cout << source; //prints "foobar"

Note how the library does *not* derive from std::string but uses
non-member functions that take std::string parameters.


--
Christian Hackl

Hi Victor/Alf,

Thank you both for your replies. Actually, I had gotten a little
further than what I posted and stumbled on exactly what you two are
now discussing...

I derived a class mystring (sorry, I won't say "subclass" :-) ) from
string and was trying to do:

mystring foo
....
foo.length ();

I didn't think about casting...but I thought somehow that should have
worked. Obviously, not... Thanks for the two suggestions and the
pros/cons of each!

Ray



On Jul 16, 6:25 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * Victor Bazarov:
> > Alf P. Steinbach wrote:
> >> * Victor Bazarov:
>
> > class M {};
> > void foo(M&);
> > class L { public: operator M&(); };
>
> > versus
>
> > class M { public: foo(); };
> > class L { public: operator M&(); };
>
> > With the former you can have
>
> > L l;
> > foo(l);
>
> > but with the latter you can't do
>
> > L l;
> > l.foo();
>
> Reference operators are bad 'uns generally, but for latter you could just
> static_cast<M&>(l).foo(), and even static_cast<M&>(L()).foo().
>
> But I think the above misses the point, by introducing that conversion to reference.

Hi Christian,

Thanks for this -- I didn't know that the Boost library had string
algorithms. I should have thought that something like "tolower" would
be there. I think I'll take this option; I'm obviously too new to
continue going down the current path. :-) Thank you!

Ray



On Jul 16, 7:13 am, Christian Hackl <ha...@sbox.tugraz.at> wrote:
> Ray wrote:
> > Can someone suggest what is the recommended way to add functionality
> > to (say) the string class? Actually, I would like to do other things
> > to strings, and toLower is just one of them.
>
> Why not use the String Algorithms library in Boost?http://www.boost.org/doc/libs/1_35_0...ring_algo.html
>
> It may already offer most of the functionality you need, including case
> conversion algorithms.
>
> std::string source = "FooBar";
> boost::algorithm::to_lower(source);
> std::cout << source; //prints "foobar"
>
> Note how the library does *not* derive from std::string but uses
> non-member functions that take std::string parameters.
>
> --
> Christian Hackl