Re: [boost] Re: static sized strings

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-20 12:41:04

From: "Reece Dunn" <msclrhd_at_[hidden]>
> 
> 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).

Since when can you not 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!

You'd have those same eight variations with const and non-const
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 the object is really const, then this results in undefined
behavior.

> If there are alternate solutions, I'd like to hear them.

Use const and non-const virtual functions. ;-)

> 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).

But how would the iterator know whether to give const or
non-const access to the elements?

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;