Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Extending string class

Reply
Thread Tools

Extending string class

 
 
Carl Youngblood
Guest
Posts: n/a
 
      07-08-2004
I imagine this subject has probably been brought up numerous times.
Forgive me for bringing it up again. I was googling through old posts
on this newsgroup about it and found a good suggestion on how to add
functionality to the string class. Rather than trying to inherit from
the string class, the author was suggesting wrapping the string class
in another class, like so:

>Right !!!, we should not derive from string, but we should wrap the
>string class, for example.
>
>class Mystring {
> string data;
>
> Mystring(char* x) : data(x){};
> Mystring(string* x) : data(x){};
>
> Mystring& operator=(const Mystring& x){
> data=x.data;
> return *this.
> }
>}


The only confusing thing about his post was that he said this at the
end:

>This is actually a very easy thing to do. You just have to check all

the
>interface functions of string class (which is basic_string<char>) and

do the
>same inline like above. The new class will have about the same

efficiency as
>the std::string class one (because of the inlining), however, you

will be
>able to extend your own additions of behaviors. Don't forget to

define the
>value type, iterator type and reference type, like this ....
> typename string::value_type value_type;
>and etc .....


I don't know exactly what he meant by "Don't forget to define the
value type, iterator type and reference type". I've done a good bit
of C++ programming but am by no means an expert.

Thanks for your help,

Carl Youngblood
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      07-08-2004
Carl Youngblood wrote:
> I imagine this subject has probably been brought up numerous times.
> Forgive me for bringing it up again. I was googling [...]


I think you should consider reading a decent book on the Standard C++
containers and iterators (and other parts of the library).

> [...]
>
> I don't know exactly what he meant by "Don't forget to define the
> value type, iterator type and reference type". I've done a good bit
> of C++ programming but am by no means an expert.


std::basic_string is a standard class template that is made compatible
with standard algorithms by implementing (declaring) types that the
algorithms expect from any other compliant container. If you find
a good book on C++ library, its algorithms, and how to implement your
own container (or a container template), you'd see how those "value
type, iterator type and reference type" are used. In essence, you
need to do something like

class MyString {
string data;

typedef string::value_type value_type;
typedef string::reference reference;
typedef string::iterator iterator;

and so on. You will basically re-declare those types to be valid
types in the scope of your class, so that anybody who needs them can
use MyString::value_type instead of figuring out what that type should
be...

Victor
 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      07-08-2004
Carl Youngblood wrote:

> I imagine this subject has probably been brought up numerous times.
> Forgive me for bringing it up again. I was googling through old posts
> on this newsgroup about it and found a good suggestion on how to add
> functionality to the string class. Rather than trying to inherit from
> the string class, the author was suggesting wrapping the string class
> in another class, like so:
>
> >Right !!!, we should not derive from string, but we should wrap the
> >string class, for example.
> >
> >class Mystring {
> > string data;
> >
> > Mystring(char* x) : data(x){};
> > Mystring(string* x) : data(x){};
> >
> > Mystring& operator=(const Mystring& x){
> > data=x.data;
> > return *this.
> > }
> >}

>
> The only confusing thing about his post was that he said this at the
> end:
>
> >This is actually a very easy thing to do. You just have to check all

> the
> >interface functions of string class (which is basic_string<char>) and

> do the
> >same inline like above. The new class will have about the same

> efficiency as
> >the std::string class one (because of the inlining), however, you

> will be
> >able to extend your own additions of behaviors. Don't forget to

> define the
> >value type, iterator type and reference type, like this ....
> > typename string::value_type value_type;
> >and etc .....

>
> I don't know exactly what he meant by "Don't forget to define the
> value type, iterator type and reference type". I've done a good bit
> of C++ programming but am by no means an expert.


It's bad advice.

There are two kinds of classes: Library classes, and application-specific
classes.

Library classes must have extraordinarily wide interfaces, to ensure they
see use. Iterators and traits permit std::string to satisfy many many more
situations than any single application should ever use.

Application-specific classes must have the narrowest interfaces possible to
do their jobs. If an application-specific class delegates to a library
class, it should HIDE that super-wide interface, not reveal every stinkin'
permutation of it.

Do not ever add any method anywhere that nobody needs, right now. Prove
every method works with both unit tests and with re-use among other
application classes that are themselves unit-tested.

The more methods a class exposes, the less flexible that class's internals
become. If you needed to replace std::string with CString or _bstr_t (and
you might find legitimate reasons to do so), your change should be as simple
as replacing MyString's data, and then trivially re-writing each method.
When all of MyString's tests pass, integrate and run all integration tests,
and you are done.

That refactor would be incredibly difficult if you wrote every method
std::string uses, and if application code then called all of those methods.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces


 
Reply With Quote
 
David Hilsee
Guest
Posts: n/a
 
      07-09-2004
"Carl Youngblood" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> I imagine this subject has probably been brought up numerous times.
> Forgive me for bringing it up again. I was googling through old posts
> on this newsgroup about it and found a good suggestion on how to add
> functionality to the string class. Rather than trying to inherit from
> the string class, the author was suggesting wrapping the string class
> in another class, like so:
>
> >Right !!!, we should not derive from string, but we should wrap the
> >string class, for example.
> >
> >class Mystring {
> > string data;
> >
> > Mystring(char* x) : data(x){};
> > Mystring(string* x) : data(x){};
> >
> > Mystring& operator=(const Mystring& x){
> > data=x.data;
> > return *this.
> > }
> >}

>
> The only confusing thing about his post was that he said this at the
> end:
>
> >This is actually a very easy thing to do. You just have to check all

> the
> >interface functions of string class (which is basic_string<char>) and

> do the
> >same inline like above. The new class will have about the same

> efficiency as
> >the std::string class one (because of the inlining), however, you

> will be
> >able to extend your own additions of behaviors. Don't forget to

> define the
> >value type, iterator type and reference type, like this ....
> > typename string::value_type value_type;
> >and etc .....


These "extensions" are probably best provided as non-member functions,
possibly in some string utility namespace for your application. Most
likely, creating a separate string class will not add any value, and it will
only create overhead when the client has to copy the string's contents into
an instance of your class to to invoke the member functions in that class.
I say "probably" because the description you gave leads me to believe that
you have no intention of hiding the std::string implementation from the
users of the class. If that is true, then do not bother creating a separate
class to hold your utility functions for std::string, as it will not provide
anything that non-member ("free") functions could also provide with less
overhead. If your intention is to keep the class's clients from depending
on std::string, then this class may have some merit, as Phlip described.

--
David Hilsee


 
Reply With Quote
 
Carl Youngblood
Guest
Posts: n/a
 
      07-10-2004
Thanks for all your advice. I'm sorry but the easiest way to handle
to problem was to write a helper function in another namespace, as the
last post suggested. However, this just doesn't sit well with me from
an OO standpoint. If I'm adding functionality that someone would want
on a string, it seems like I should be able to add it to the string
class, or a class derived from it, but this is a monumental task in
C++, akin to swimming the English channel or something. It appears
that I've spent too much time in VHLLs like Ruby. Thanks anyway for
your help.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Cleverly extending the std::string class peter koch C++ 6 03-24-2009 08:41 AM
Re: Cleverly extending the std::string class James Kanze C++ 1 03-20-2009 08:35 AM
java.util.Properties extending from HashMap<Object, Object> insteadof HashMap<String, String> Rakesh Java 10 04-08-2008 04:22 AM
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
maps and class types: extending a class factory Simon Elliott C++ 0 01-11-2005 01:02 PM



Advertisments