Boost logo

Boost :

From: John Nagle (nagle_at_[hidden])
Date: 2004-05-20 12:58:23


   This looks rather complex for what it does.

   It might be helpful to define the user-visible
API first. Then worry about the implementation.

                                John Nagle
                                Animats

Reece Dunn wrote:

> John Nagle wrote:
>
>> Reece Dunn wrote:
>>
>>> I have uploaded an initial version of this.
>>
>> Thanks. I'll take a look at that shortly.
>
>
> You might want to take a look at fixed_string.hpp. It is an alternate
> implementation of fixed_string that I intend to replace char_string.hpp
> once it is stable.
>
> Currently, this implementation is missing iterator support (and thus all
> basic_string functionality that relies on begin(), end(), etc). This is
> because I am wondering how to map them from the basic_string adaptor to
> the implementation (knowing that you cannot have const and non-const
> virtual functions).
>
> I have two possible solutions:
> [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the
> problem with this is that you have 8 virtual functions!
>
> [2] direct to non-const versions and convert to const iterators:
> inline const_iterator begin() const
> {
> return( const_iterator( const_cast< basic_string_impl & >( *this
> ).begin()));
> }
> but I am debating whether this is standards compliant and if it is a
> good design decision.
>
> If there are alternate solutions, I'd like to hear them.
>
> Another possibility would be to construct the iterators from offsets:
>
> inline iterator begin()
> {
> return( get_impl().iter_offset( 0 ));
> }
> inline reverse_iterator rbegin()
> {
> return( reverse_iterator( get_impl().iter_offset( size() - 1 )));
> }
>
> That way you would only need two functions (iter_offset and
> const_iter_offset).
>
> Regards,
> Reece


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk