extending std::string

Discussion in 'C++' started by Lars Schouw, Apr 7, 2010.

  1. Lars Schouw

    Lars Schouw Guest

    How can I extend the std::string class to become more cleaver with
    regards to regexp build right into my extended string class?

    * I am not allowed to derive from std::string since there is no
    virtual destructor.
    * I don't want to aggregate the std:string as a private member
    variable since I need to expose all it's methods and maintain changes
    in the future of the std standard.
    * I could have an extra util file that where all the functions takes
    in the std::string as the first agument but this would not be as
    elegant.

    I know this has been discussed before but just wanted to see if anyone
    has any new ideas.

    Lars
    Lars Schouw, Apr 7, 2010
    #1
    1. Advertising

  2. Lars Schouw

    Kai-Uwe Bux Guest

    Lars Schouw wrote:

    > How can I extend the std::string class to become more cleaver with
    > regards to regexp build right into my extended string class?
    >
    > * I am not allowed to derive from std::string since there is no
    > virtual destructor.


    Uhm, in itself that should not stop you. There are other classes, like
    std::iterator or std::binary_predicate clearly meant to be derived from that
    lack virtual destructors.

    > * I don't want to aggregate the std:string as a private member
    > variable since I need to expose all it's methods and maintain changes
    > in the future of the std standard.


    Then, public derivation seems to be your friend. But there are some gotchas.
    You could also consider private derivation, which does require some using
    directives for forwarding. These, of course, would need to be updated with
    any change in the string class.

    > * I could have an extra util file that where all the functions takes
    > in the std::string as the first agument but this would not be as
    > elegant.


    Why not? To me, it appears that regular expressions are orthogonal to
    strings. In fact, I would picture a regexp class that can operate (determine
    matches, ...) on _any_ sequence of chars: std::string, std::vector< char >,
    std::deque< char >, ... I would assume that such a regexp class has member
    function templates like

    template < typename Char >
    class regexp {

    ...

    template < typename CharIter >
    bool match ( CharIter from, CharIter to );

    template < typename CharIter >
    CharIter first_match ( CharIter from, CharIter to );

    };


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Apr 7, 2010
    #2
    1. Advertising

  3. Lars Schouw

    tonydee Guest

    On Apr 8, 4:11 am, Lars Schouw <> wrote:
    > How can I extend the std::string class to become more cleaver with
    > regards to regexp build right into my extended string class?
    >
    > * I am not allowed to derive from std::string since there is no
    > virtual destructor.


    As mentioned by Christian, this isn't a show stopper.

    > * I don't want to aggregate the std:string as a private member
    > variable since I need to expose all it's methods and maintain changes
    > in the future of the std standard.


    Understandable.

    > * I could have an extra util file that where all the functions takes
    > in the std::string as the first agument but this would not be as
    > elegant.


    In terms of elegance, can you show us what usage you're trying to
    achieve? How it'd be "better" than boost::regex and std::string? I
    need to see that before the implementation implications are obvious
    enough that I might offer concrete advice. For now, I guess you want
    a variant that can be in string or regexp state, but how will you
    specify which type it should be in constructors and especially
    operator=? What happens if people try to insert/replace etc. in a
    regexp: will you recompile the regexp each time, or lazily on first
    use? There are lots of implementation questions and the usage and
    consequences may be hard to keep consistent, let alone test and
    document and train people in. I suspect that when you get into this
    you'll find separate classes is cleaner and reliable than a fat
    interface merging concepts of both....

    Cheers,
    Tony
    tonydee, Apr 8, 2010
    #3
  4. Lars Schouw

    Lars Schouw Guest

    I understand it is very difficult to extend stl since it is elegantly
    designed to be used with containers and algoritms.

    Acually what I am trying to do it mimic powerful VBA string
    functionallity, which C++ seems to be missing out of the box.

    Here is a list of requirements:

    A) The VBA method Like can be done using regexp. regexp is part of C++
    0X (TR1)

    B) Tokenize a string easily. Split stings by chars or string
    delimiters. Split stings in fixed sizes.

    C) trim strings trailing and ending of whitespaces and also strip
    strings of whitespaces

    D) Compare string case insensitive

    E) IsNumeric and IsAlphanumeric, determin if a string is numeric (0-9)
    or alphanumeric (a-z, A-Z and 0-9)

    F) Convert from string to bool, double, long or date

    G) Rounding of numbers in strings

    H) Easily handle pascal and C strings

    I) Ideally be able to stored in a stl container

    J) join a N strings into one.

    K) Repeate a string N times.

    L) convert strings to lower or upper case

    M) Find out if a string is lower or upper case

    N) swap lower and upper case.

    Keenan Tims seems to have done a number of them already
    http://www.gotroot.ca/ext_string/

    I am not such a big fan of your do all functions that just encapsulate
    the helper functions, need to think a little.
    Maybe we should just do regexp everywhere like in VBA!

    When I am done with the extended string class, I also need to extend
    the C++ language date functionality.

    Lars

    On 8 Apr, 02:52, tonydee <> wrote:
    > On Apr 8, 4:11 am, Lars Schouw <> wrote:
    >
    > > How can I extend the std::string class to become more cleaver with
    > > regards to regexp build right into my extended string class?

    >
    > > * I am not allowed to derive from std::string since there is no
    > > virtual destructor.

    >
    > As mentioned by Christian, this isn't a show stopper.
    >
    > > * I don't want to aggregate the std:string as a private member
    > > variable since I need to expose all it's methods and maintain changes
    > > in the future of the std standard.

    >
    > Understandable.
    >
    > > * I could have an extra util file that where all the functions takes
    > > in the std::string as the first agument but this would not be as
    > > elegant.

    >
    > In terms of elegance, can you show us what usage you're trying to
    > achieve?  How it'd be "better" than boost::regex and std::string?  I
    > need to see that before the implementation implications are obvious
    > enough that I might offer concrete advice.  For now, I guess you want
    > a variant that can be in string or regexp state, but how will you
    > specify which type it should be in constructors and especially
    > operator=?  What happens if people try to insert/replace etc. in a
    > regexp: will you recompile the regexp each time, or lazily on first
    > use?  There are lots of implementation questions and the usage and
    > consequences may be hard to keep consistent, let alone test and
    > document and train people in.  I suspect that when you get into this
    > you'll find separate classes is cleaner and reliable than a fat
    > interface merging concepts of both....
    >
    > Cheers,
    > Tony
    Lars Schouw, Apr 8, 2010
    #4
  5. Lars Schouw

    Lars Schouw Guest

    If I wanted to go wild I would like the same from VBA strings in
    Excel.
    http://www.mvps.org/dmcritchie/excel/strings.htm


    On 8 Apr, 09:29, Lars Schouw <> wrote:
    > I understand it is very difficult to extend stl since it is elegantly
    > designed to be used with containers and algoritms.
    >
    > Acually what I am trying to do it mimic powerful VBA string
    > functionallity, which C++ seems to be missing out of the box.
    >
    > Here is a list of requirements:
    >
    > A) The VBA method Like can be done using regexp. regexp is part of C++
    > 0X (TR1)
    >
    > B) Tokenize a string easily. Split stings by chars or string
    > delimiters. Split stings in fixed sizes.
    >
    > C) trim strings trailing and ending of whitespaces and also strip
    > strings of whitespaces
    >
    > D) Compare string case insensitive
    >
    > E) IsNumeric and IsAlphanumeric, determin if a string is numeric (0-9)
    > or alphanumeric (a-z, A-Z and 0-9)
    >
    > F) Convert from string to bool, double, long or date
    >
    > G) Rounding of numbers in strings
    >
    > H) Easily handle pascal and C strings
    >
    > I) Ideally be able to stored in a stl container
    >
    > J) join a N strings into one.
    >
    > K) Repeate a string N times.
    >
    > L) convert strings to lower or upper case
    >
    > M) Find out if a string is lower or upper case
    >
    > N) swap lower and upper case.
    >
    > Keenan Tims seems to have done a number of them alreadyhttp://www.gotroot..ca/ext_string/
    >
    > I am not such a big fan of your do all functions that just encapsulate
    > the helper functions, need to think a little.
    > Maybe we should just do regexp everywhere like in VBA!
    >
    > When I am done with the extended string class, I also need to extend
    > the C++ language date functionality.
    >
    > Lars
    >
    > On 8 Apr, 02:52, tonydee <> wrote:
    >
    > > On Apr 8, 4:11 am, Lars Schouw <> wrote:

    >
    > > > How can I extend the std::string class to become more cleaver with
    > > > regards to regexp build right into my extended string class?

    >
    > > > * I am not allowed to derive from std::string since there is no
    > > > virtual destructor.

    >
    > > As mentioned by Christian, this isn't a show stopper.

    >
    > > > * I don't want to aggregate the std:string as a private member
    > > > variable since I need to expose all it's methods and maintain changes
    > > > in the future of the std standard.

    >
    > > Understandable.

    >
    > > > * I could have an extra util file that where all the functions takes
    > > > in the std::string as the first agument but this would not be as
    > > > elegant.

    >
    > > In terms of elegance, can you show us what usage you're trying to
    > > achieve?  How it'd be "better" than boost::regex and std::string?  I
    > > need to see that before the implementation implications are obvious
    > > enough that I might offer concrete advice.  For now, I guess you want
    > > a variant that can be in string or regexp state, but how will you
    > > specify which type it should be in constructors and especially
    > > operator=?  What happens if people try to insert/replace etc. in a
    > > regexp: will you recompile the regexp each time, or lazily on first
    > > use?  There are lots of implementation questions and the usage and
    > > consequences may be hard to keep consistent, let alone test and
    > > document and train people in.  I suspect that when you get into this
    > > you'll find separate classes is cleaner and reliable than a fat
    > > interface merging concepts of both....

    >
    > > Cheers,
    > > Tony

    >
    >
    Lars Schouw, Apr 8, 2010
    #5
  6. Lars Schouw

    Lars Schouw Guest

    Christian,

    Thank you for taking time to point out all the goodes of Boost to me.

    So when will all this be part of standard C++ so there is no need to
    use Boost?

    By pascal strings I mean stdlen + string
    C string is string \0

    Lars

    On 8 Apr, 11:42, Christian Hackl <> wrote:
    > Lars Schouw ha scritto:
    >
    > > I understand it is very difficult to extend stl since it is elegantly
    > > designed to be used with containers and algoritms.

    >
    > Actually, it's the other way round. Its elegance makes it easy to extend.
    >
    > > Acually what I am trying to do it mimic powerful VBA string
    > > functionallity, which C++ seems to be missing out of the box.

    >
    > Yes, but it's all in Boost.
    >
    > You don't want to extend std::string with yet another 1000 functions
    > when its interface is already too comprehensive as it is. Instead, you
    > want to add new functionality in terms of existing member functions.
    >
    > > A) The VBA method Like can be done using regexp. regexp is part of C++
    > > 0X (TR1)

    >
    > Just write a free-standing function like() function which uses regular
    > expressions in its implementation.
    >
    > > B) Tokenize a string easily. Split stings by chars or string
    > > delimiters. Split stings in fixed sizes.

    >
    > See Boost.Tokenizer.
    >
    > > C) trim strings trailing and ending of whitespaces and also strip
    > > strings of whitespaces

    >
    > See the Boost String Algorithms library. It contains some trim functions.
    >
    > > D) Compare string case insensitive

    >
    > http://www.boost.org/doc/libs/1_42_0/doc/html/boost/algorithm/ilexico...
    >
    > > E) IsNumeric and IsAlphanumeric, determin if a string is numeric (0-9)
    > > or alphanumeric (a-z, A-Z and 0-9)

    >
    > This can be done by the String Algorithms library, too.
    >
    > > F) Convert from string to bool, double, long or date

    >
    > boost::lexical_cast, Boost.Date_Time.
    >
    > > G) Rounding of numbers in strings

    >
    > Convert the string to a number using boost::lexical_cast, then round,
    > then convert it back to a string using boost::lexical_cast. If you need
    > this functionality so often, then just put it into a convenience function..
    >
    > > H) Easily handle pascal and C strings

    >
    > std::string does easily handle C strings.
    >
    > Pascal strings? What do you mean?
    >
    > > I) Ideally be able to stored in a stl container

    >
    > std::string can be stored in any STL container.
    >
    > > J) join a N strings into one.

    >
    > That in the Boost String Algorithms library, too:
    >
    > http://www.boost.org/doc/libs/1_42_0/doc/html/string_algo/reference.h...
    >
    > > K) Repeate a string N times.

    >
    > If it's not in Boost String Algorithms, then it's trivial to implement
    > by yourself.
    >
    > > L) convert strings to lower or upper case

    >
    > Again, Boost String Algorithms.
    >
    > > M) Find out if a string is lower or upper case

    >
    > if (boost::algorithm::all(my_string, boost::algorithm::is_lower))
    > {
    >   // ...
    >
    > }
    > > N) swap lower and upper case.

    >
    > I think Boost does not provide anything like this, but it's not hard to
    > write and put into a convenience function.
    >
    > > I am not such a big fan of your do all functions that just encapsulate
    > > the helper functions, need to think a little.

    >
    > It's the other way round. Helper functions encapsulate core
    > functionality. This is the preferred way of
    >
    > > Maybe we should just do regexp everywhere like in VBA!

    >
    > Why? It works fine the way it is.
    >
    > > When I am done with the extended string class, I also need to extend
    > > the C++ language date functionality.

    >
    > No, you don't need to extend the C++ language date functionality. You
    > need to learn Boost.Date_Time and use it :)
    >
    > http://www.boost.org/doc/libs/1_42_0/doc/html/date_time.html
    >
    > --
    > Christian Hackl
    >
    >
    > Milano 2008/2009 -- L'Italia chiamò, sì!
    Lars Schouw, Apr 8, 2010
    #6
  7. Lars Schouw

    Lars Schouw Guest

    It is better since you don't rely on the silly end of string character
    in C++.
    It is also used in .dll interfaces in Windows as far as I remember.

    No intermediate need just a nice to have.

    Lars

    On Apr 8, 6:13 pm, Christian Hackl <> wrote:
    > Lars Schouw ha scritto:
    >
    > > Thank you for taking time to point out all the goodes of Boost to me.

    >
    > You're welcome :)
    >
    > > So when will all this be part of standard C++ so there is no need to
    > > use Boost?

    >
    > Perhaps some of this will never make it into standard C++ because it's
    > not considered useful, important or general-purpose enough to become
    > part of the language.
    >
    > But is that really such a big problem? What keeps you from using Boost?
    >
    > > By pascal strings I mean stdlen + string

    >
    > I still didn't get it, because it's been 12 years since I used Pascal.
    > The Internet, however, came up with the following description on
    > Wikipedia [1]. I don't know if it's correct. Here we go:
    >
    > | The length of a string can also be stored explicitly, for example by
    > | prefixing the string with the length as a byte value — a convention
    > | used in Pascal; consequently some people call it a P-string.
    >
    > If I understand correctly, this is like constant char arrays in C++,
    > whose length is known at compile time.
    >
    > But what would you need this feature for, anyway? It calls for trouble.
    >
    > [1]http://en.wikipedia.org/wiki/String_(computer_science)
    >
    > --
    > Christian Hackl
    >
    >
    > Milano 2008/2009 -- L'Italia chiamò, sì!
    Lars Schouw, Apr 8, 2010
    #7
  8. Lars Schouw

    Lars Schouw Guest

    Kai-Uwe,

    Does that mean I can derive from a lower level class like
    std::iterator or std::binary_predicate instead of std::string safely
    and extend the string class that way?

    still allowing it to be used in containers.

    Lars

    On 7 Apr, 20:21, Kai-Uwe Bux <> wrote:
    > Lars Schouw wrote:
    > > How can I extend the std::string class to become more cleaver with
    > > regards to regexp build right into my extended string class?

    >
    > > * I am not allowed to derive from std::string since there is no
    > > virtual destructor.

    >
    > Uhm, in itself that should not stop you. There are other classes, like
    > std::iterator or std::binary_predicate clearly meant to be derived from that
    > lack virtual destructors.
    >
    > > * I don't want to aggregate the std:string as a private member
    > > variable since I need to expose all it's methods and maintain changes
    > > in the future of the std standard.

    >
    > Then, public derivation seems to be your friend. But there are some gotchas.
    > You could also consider private derivation, which does require some using
    > directives for forwarding. These, of course, would need to be updated with
    > any change in the string class.
    >
    > > * I could have an extra util file that where all the functions takes
    > > in the std::string as the first agument but this would not be as
    > > elegant.

    >
    > Why not? To me, it appears that regular expressions are orthogonal to
    > strings. In fact, I would picture a regexp class that can operate (determine
    > matches, ...) on _any_ sequence of chars: std::string, std::vector< char >,
    > std::deque< char >, ... I would assume that such a regexp class has member
    > function templates like
    >
    >   template < typename Char >
    >   class regexp {
    >
    >     ...
    >
    >     template < typename CharIter >
    >     bool match ( CharIter from, CharIter to );
    >
    >     template < typename CharIter >
    >     CharIter first_match ( CharIter from, CharIter to );
    >
    >   };
    >
    > Best
    >
    > Kai-Uwe Bux
    Lars Schouw, Apr 9, 2010
    #8
  9. Lars Schouw

    Kai-Uwe Bux Guest

    Lars Schouw wrote:

    > Kai-Uwe,
    >
    > Does that mean I can derive from a lower level class like
    > std::iterator or std::binary_predicate instead of std::string safely
    > and extend the string class that way?
    >
    > still allowing it to be used in containers.


    a) Please don't top-post. That a cultural thing and frowned upon in these
    parts. The reference for your question is clearer if you put it directly
    below to what you are referring to.

    > On 7 Apr, 20:21, Kai-Uwe Bux <> wrote:
    >> Lars Schouw wrote:
    >> > How can I extend the std::string class to become more cleaver with
    >> > regards to regexp build right into my extended string class?

    >>
    >> > * I am not allowed to derive from std::string since there is no
    >> > virtual destructor.

    >>
    >> Uhm, in itself that should not stop you. There are other classes, like
    >> std::iterator or std::binary_predicate clearly meant to be derived from
    >> that lack virtual destructors.


    b) I assume this is the context of your question.

    No, I did not mean that you can derive from std::binary_predicate to extend
    std::string. I meant that lack of a virtual destructor by and in itself is
    not a sufficient reason to shun derivation.


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Apr 9, 2010
    #9
  10. Lars Schouw

    Lars Schouw Guest

    On Apr 9, 4:17 pm, Kai-Uwe Bux <> wrote:
    > >> Uhm, in itself that should not stop you. There are other classes, like
    > >> std::iterator or std::binary_predicate clearly meant to be derived from
    > >> that lack virtual destructors.

    >
    > b) I assume this is the context of your question.
    >
    > No, I did not mean that you can derive from std::binary_predicate to extend
    > std::string. I meant that lack of a virtual destructor by and in itself is
    > not a sufficient reason to shun derivation.


    OK, but in that case I would just have to be careful that my member
    variables get's correct destructor in the derived class since it's
    destructor will never be called?
    Lars Schouw, Apr 11, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Jansson
    Replies:
    5
    Views:
    6,265
    Ivan Vecerina
    Mar 17, 2005
  2. Fei Liu
    Replies:
    9
    Views:
    433
  3. Jeffrey Walton
    Replies:
    10
    Views:
    928
    Mathias Gaunard
    Nov 26, 2006
  4. peter koch
    Replies:
    6
    Views:
    379
    James Kanze
    Mar 24, 2009
  5. James Kanze
    Replies:
    1
    Views:
    345
    James Kanze
    Mar 20, 2009
Loading...

Share This Page