Re: [boost] string_algo review part 2

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-25 08:29:21

On Fri, Oct 24, 2003 at 01:06:57PM +0100, John Maddock wrote:
> > > 12) OK, I'm beginning to see the consistency in the *2.hpp headers now,
> > > but
> > > maybe if that's the intent, and you do want to keep them, then why not
> > > call
> > > them *_predicates.hpp, so we know what's what?  Just a thought.
> >
> > *2.hpp headers contain generic variants of algorithms. There is a section
> > about
> > the layered structure of the library in docs. *2.hpp represents the second
> > layer.
> > (a.k.a string_algo namespace )
> 
> OK I found a section in the rationale (not the first place I would have
> looked), it's hampered again by the docs for the individual functions not
> indicating what namespace they're in.  My main point is that the naming
> convension doesn't give the user any kind of a hint as to what's in what
> header.
>

I see. There are more possibilities to solve this. One solution is long term
one. It the big algorithm library (a combination of sequence_algo, container_algo
string_algo ant etc. libs) ther will be a top level algorithm namespace and
directory. This will be the place for .hpp files and functions. *2.hpp
will go to algorithm/string_algo and _2 prefix will go away.

Other way would be for instance to change suffix _2 to f.e. _generic. Thats
actualy to real meaning of *2 layer.

And actualy, the layered structure is mentioned also in the introduction

[snip]
> How about:
> 
> template <class Container>
> struct string_find_iterator
> {
>   typedef iterator_range<typename Container::const_iterator> value_type; //
> etc
> 
>   string_find_iterator(); // end of sequence
>   template <class Predicate>
>   string_find_iterator(const Container& c, const Predicate& pred); // what
> to find
> 
>   const value_type& operator*()const;
>   // other members etc
> };
> 
> Notice that you only have the one template parameter (the container type),
> the template constructor takes a predicate indicating what to match, and
> gets "virtuallised away" internally: the operator++ would have to make a
> virtual function call, but that's likely to be an irrelavent cost compared
> to the cost of a string find.
> 
> Just off the top of my head... :-)

Virtualization is indeed a viable solution. I have not considered it because of 
performance reasons, but now I see, that it might be used after all.

I will think about it more, but it seems as a doable way. Thanks!

> 
> > > 14) trim2 and trim.hpp don't have the relationship I suspected in #12
> > > :-(
> > >
> > See 12.
> > 
> Not quite, my point was that you are using the "2" suffix for two different
> kinds of headers - some kind of meaningful and descriptive suffix would be
> better IMO - I'm not entirely sure that the second level namespace is really
> needed either?
> 

Second layer namespace was added because, otherwise I was getting too many
nameclashes. I could either rename functions, or put them in the namespaces.

I have chosen the second alternative, because it also gave some way for
distinguishing between generic and specific variants of algorithms.

Putting everything into boost::string_algo namespace might be inconvinient
and it is not possible to put it to the namespace boost because there
are possibilitie for namecolisions (some names might be too generic).

Current structure is supposed to be a kind of compromise.

I received several complaint, that this separation is not clear enough.
I'll try to come up with some ideas, how to make it more understandable
from docs.

Regards,

Pavol