extending std::string
 

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

Re: extending std::string
 

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

Re: extending std::string
 

On Apr 8, 4:11*am, Lars Schouw <schou...@yahoo.com> 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

Re: extending std::string
 

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 <tony_in_da...@yahoo.co.uk> wrote:
> On Apr 8, 4:11*am, Lars Schouw <schou...@yahoo.com> 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

Re: extending std::string
 

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 <schou...@yahoo.com> 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 <tony_in_da...@yahoo.co.uk> wrote:
>
> > On Apr 8, 4:11*am, Lars Schouw <schou...@yahoo.com> 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
>
>

Re: extending std::string
 

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 <ha...@sbox.tugraz.at> 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...orithm/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...go/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...date_time.html
>
> --
> Christian Hackl
> ha...@sbox.tugraz.at
>
> Milano 2008/2009 -- L'Italia chiamò, sì!

Re: extending std::string
 

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 <ha...@sbox.tugraz.at> 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
> ha...@sbox.tugraz.at
>
> Milano 2008/2009 -- L'Italia chiamò, sì!

Re: extending std::string
 

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 <jkherci...@gmx.net> 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

Re: extending std::string
 

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 <jkherci...@gmx.net> 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

Re: extending std::string
 

On Apr 9, 4:17*pm, Kai-Uwe Bux <jkherci...@gmx.net> 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?