extending std::string

[Lars Schouw]

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

 

[Kai-Uwe Bux]

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

 

[tonydee]

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]

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

 

[Lars Schouw]

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

 

[Lars Schouw]

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

 

[Lars Schouw]

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

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
(e-mail address removed)

Milano 2008/2009 -- L'Italia chiamò, sì!

 

[Lars Schouw]

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

 

[Kai-Uwe Bux]

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.

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

 

[Lars Schouw]

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?