
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 _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

From: "Reece Dunn" <msclrhd@hotmail.com>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

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

I think I have a way to simplify this. I'll post something over the weekend. John Nagle John Nagle wrote:
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
participants (3)
-
John Nagle
-
Reece Dunn
-
Rob Stewart