Re: [boost] Re: Re: [string algo formal review]

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-27 15:46:19

On Mon, Oct 27, 2003 at 10:49:03AM -0500, Rob Stewart wrote:

[snip]

> 
> A substring is not a structural element of the container.  A
> container is, by definition, composed of elements.  A substring
> is a semantic notion temporarily associated with a portion of a
> container.  Thus, the former should be denoted using the usual
> C/C++ indexing notation.  The latter, OTOH, should be denoted
> using the vernacular: we use ordinals to refer to things like
> substrings.  That means numbering from one for substrings.
>

That's partialy true. But all matching substrings in a sequence form
an ordered set. Given this I see no problem with a notion that the first element
has the index 0. It is very natural notion in the computer domain.
  
> > What would then denote find_nth( s, XX, 0 )? Should it throw an exception?
> 
> Sure.

So let's see on one hand we have a compile time checked, well defined domain for 0-based indexing,
on the other hand run-time exception.
I don't see any good reason to prefer the second alternative.

[snip]
 
> I think this reveals a fundamental issue with this library.  It
> is called a "string" algorithms library, and that means something
> like std::string, MFC's CString, etc. to most people.  This
> library follows the STL convention of treating many things
> alike.  (If it looks like a duck, and quacks like a duck, we call
> it a duck.)  Thus, this library generalizes the notion of a
> "string" beyond what many find comfortable or typical.
> Recognizing this, the documentation must clearly, loudly, and
> early set straight the record.
> 
> On the conversion issue raised above, may I point out that if the
> underlying "string" container is std::basic_string in some form,
> then conversions of iterator_ranges to the same string type
> should be trivial, if not implicit.  Thus, if someone uses the
> "string" algorithms library on std::string, then they should be
> able to work with and convert to std::string very easily, with a
> minimum of fuss.  Extra steps, especially steps that don't read
> right, should be avoided.  Thus, the suggested copy() mf should
> at least be named "str" in keeping with the STL, if the
> conversion to the string type can't safely be made implicitly.

Problem is that even thou iterator_range models a substring,
it is not a "substring". It is only a kind of "pointer" to
a substring. It has no reference to an underlying container,
except for the iterators. 

Similary to iterators, it abstracts from the undelying container
and allows to simply iterate through the values as the iterator
allows to access values.

Problem with a conversion to f.e. std::string is that, itertor_range
has no information about what the underlying container is and
sometimes, it is not even a container (e.g. char*).
So it cannot be converted to a container without explicit
statement of the container type.

For such conversion there is a copy_range function.

I can propose a slight variation to the copy_range, with a different naming:

template< typename ContainerT, typename InputContainerT  >
ContainerT container_cast( InputContainerT& Source )
{
        return ContainerT( begin(Source), end(Source) );
}

This utility function can be used convert an arbitrary InputContainer to
an other Container.

Such a facility would cover also the requested conversion currently
porvided by copy_range.

> OTOH, if the "string" type is std::vector<char>, then conversions
> to std::string should require extra glue logic, just as one would
> expect when given a std::vector<char> and wanting to create a
> std::string from it.  This library shouldn't be expected to treat
> std::string as a lowest common denominator type, especially given
> that some string types may not convert "normally" to std::string
> (conversion traits aside).
> 

Regards,

Pavol