Re: [boost] Re: static sized strings
Rob Stewart wrote:
From: "Reece Dunn"
Rob Stewart wrote:
From: "Reece Dunn"
Currently, this implementation is missing iterator support (and thus
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
all 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?
Let me rephrase:
class char_string { virtual iterator begin() = 0; virtual const_iterator begin() = 0; // oops! begin already in vtable!! };
I'm still missing something. Why would you want a non-const mf to return the const iterator type?
That was a typeo!
class char_string { virtual iterator begin() = 0; virtual const_iterator begin() const = 0; };
That is what I was referring to. You need to change the name of the const version if you are to allow 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!
I was meaning to modify the above to:
class char_string { virtual iterator begin() = 0; virtual const_iterator cbegin() = 0; // ok - cXXX variant };
You'd have those same eight variations with const and non-const virtual functions.
That's the problem -- too many virtual functions.
But if you need all eight variations, then you need eight virtual functions. Is it that you're trying to minimize what the derived class must implement for the adaptor to work? Even if that's the
That is indeed what I am trying to do.
case, because the const and non-const functions return different types, you can't have the derived class implement a const implementation function that the adaptor can use to provide both const and non-const interface functions. So what am I missing?
Nothing. You do indeed need two functions: iterator iter_offset( difference_type ); const_iterator const_iter_offset( difference_type ) const; these can be used to implement the 8 iterator functions like this: begin() const = const_iter_offset( 0 ); begin() = iter_offset( 0 ); end() const = const_iter_offset( size()); end() = iter_offset( size()); rbegin() const = const_reverse_iterator( const_iter_offset( size())); rbegin() = reverse_iterator( iter_offset( size())); rend() const = const_reverse_iterator( const_iter_offset( -1 )); rend() = reverse_iterator( iter_offset( -1 )); Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband
From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
I'm still missing something. Why would you want a non-const mf to return the const iterator type?
That was a typeo!
class char_string { virtual iterator begin() = 0; virtual const_iterator begin() const = 0; };
That is what I was referring to. You need to change the name of the const version if you are to allow virtual functions.
Why?
case, because the const and non-const functions return different types, you can't have the derived class implement a const implementation function that the adaptor can use to provide both const and non-const interface functions. So what am I missing?
Nothing. You do indeed need two functions: iterator iter_offset( difference_type ); const_iterator const_iter_offset( difference_type ) const;
Why? This is perfectly valid C++: iterator iter_offset(different_type); const_iterator iter_offset(different_type) const; So is there something in how you want to use them that precludes your overloading them that way? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
class char_string { virtual iterator begin() = 0; virtual const_iterator begin() const = 0; };
That is what I was referring to. You need to change the name of the const version if you are to allow virtual functions.
Why?
I'm not sure if this is what Reece is alluding to, but the problem is if you want to subclass and only overload some of the begin() versions. class concrete_char_string : public char_string { virtual iterator begin(); virtual const_iterator begin() const; }; class my_char_string : public concrete_char_string { virtual iterator begin() const; }; my_char_string mcs = foo(); mcs.begin(); // calls const version We may have expected to call concrete_char_string's non-const begin(), but since it has the same name as my_char_string's begin(), it is hidden, and we call my_char_string's const version. This is a general problem problem with having multiple virtual functions with the same name. It's why people will have set_foo() and get_foo() rather than two versions of foo(). -- Colin Rafferty
From: colin.rafferty@morganstanley.com
Rob Stewart <stewart@sig.com> wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
Rob Stewart wrote:
class char_string { virtual iterator begin() = 0; virtual const_iterator begin() const = 0; };
That is what I was referring to. You need to change the name of the const version if you are to allow virtual functions.
Why?
I'm not sure if this is what Reece is alluding to, but the problem is
No, it isn't. He didn't realize that virtual functions could be overloaded.
if you want to subclass and only overload some of the begin() versions.
Note that the overloaded functions are declared pure virtual. They both have to overridden somewhere. The derived class could be left abstract by only overriding one of the two, so that does still leave to a further derived class the need to prevent hiding of either of them.
class concrete_char_string : public char_string { virtual iterator begin(); virtual const_iterator begin() const; };
class my_char_string : public concrete_char_string { virtual iterator begin() const; };
my_char_string mcs = foo();
mcs.begin(); // calls const version
We may have expected to call concrete_char_string's non-const begin(), but since it has the same name as my_char_string's begin(), it is hidden, and we call my_char_string's const version.
Sure, but you changed the problem. Your begin() overloads in the concrete_char_string class are no longer pure virtual.
This is a general problem problem with having multiple virtual functions with the same name. It's why people will have set_foo() and get_foo() rather than two versions of foo().
Such functions are not likely candidates for being virtual and are unlikely to be hidden by a redeclaration in a derived class. The reason for such names is that some folks dislike the overloaded use of the same name to mean assignment or query depending upon context. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (3)
-
colin.rafferty＠morganstanley.com -
Reece Dunn -
Rob Stewart