Re: [boost] Re: static sized strings
Rob Stewart wrote:
From: "Reece Dunn" <msclrhd@hotmail.com>
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?
No. I was not aware that it is possible to do this. I have now adopted struct char_string { ... virtual iterator iter_offset(different_type) = 0; virtual const_iterator iter_offset(different_type) const = 0; }; into my implementation. Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0; Because I had assumed that you could not do this, since (1) I haven't read the standard that properly, I have mainly focused on learning from other books (like Stroustrup, 3ed) and (2) I haven't seen any code that uses virtual functions like char_string above or my question. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo
From: "Reece Dunn" <msclrhd@hotmail.com>
Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0;
Absolutely. You can overload virtual functions just like non-virtual functions. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: "Reece Dunn" <msclrhd@hotmail.com>
Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0;
Absolutely. You can overload virtual functions just like non-virtual functions.
But unless they're all going to be overridden in one single class you're better off using the "template method pattern" and dispatching to differently-named functions to avoid problems with name hiding... or just be disciplined about bringing the base names into derived classes everywhere with "using". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
From: "Reece Dunn" <msclrhd@hotmail.com>
Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0;
Absolutely. You can overload virtual functions just like non-virtual functions.
But unless they're all going to be overridden in one single class you're better off using the "template method pattern" and dispatching to differently-named functions to avoid problems with name hiding...
Yep, something like this: class base { public: void something() { do_something(); } void something(int n) { do_something(n); } private: virtual void do_something() = 0; virtual void do_something(int n) = 0; }; class derived : public base { // both 'something' are still visible private: virtual void do_something(int n); // OK }; -- Aleksey Gurtovoy MetaCommunications Engineering
I've done a major rewrite on this. See http://www.animats.com/source boost_fixed_string.hpp - fixed strings boost_fixed_string_cstring.hpp - sprintf, etc. boost_fixed_string_test.cpp - a test program This does much the same thing as Dunn's fixed_string, but with a somewhat simpler structure. The main template class is "fixed_string<TYPE,LEN>", which is generic and does all the work. This is derived from the abstract class "fixed_string_base<TYPE>", which is used when you need a reference or pointer to a fixed string of unknown length. It doesn't do anything but redirect virtual functions. Then we define, very simply, "char_string<LEN>" "char_string_base" "wchar_string<LEN>" "wchar_string_base" These are just instantiations of fixed_string, but they also define functions that need type-based handling. So far, this is only "vsnprintf". There are no conditionals, other than the usual workaround for an MSVC problem. fixed_string has a length. Length is lazy-evaluated; some operations make the length -1, which forces a recount of the string when next the length is needed. The C-type operations and subscripting are all checked for length. Iterators are supported, but, consistent with std::string semantics, they are unsafe. Comments? John Nagle Animats
From: "Aleksey Gurtovoy" <agurtovoy@meta-comm.com>
David Abrahams writes:
From: "Reece Dunn" <msclrhd@hotmail.com>
Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0;
Absolutely. You can overload virtual functions just like non-virtual functions.
But unless they're all going to be overridden in one single class you're better off using the "template method pattern" and dispatching to differently-named functions to avoid problems with name hiding...
Yep, something like this:
class base { public: void something() { do_something(); } void something(int n) { do_something(n); }
private: virtual void do_something() = 0; virtual void do_something(int n) = 0; };
class derived : public base { // both 'something' are still visible
private: virtual void do_something(int n); // OK };
Sure, but you've both jumped off on a tangent unrelated to the purpose of the original query. See my reply to Dave's message. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: "Reece Dunn" <msclrhd@hotmail.com>
Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0;
Absolutely. You can overload virtual functions just like non-virtual functions.
But unless they're all going to be overridden in one single class you're better off using the "template method pattern" and dispatching to differently-named functions to avoid problems with name hiding... or just be disciplined about bringing the base names into derived classes everywhere with "using".
Sure, but in the case leading to this query, they are const and non-const versions of begin(), end(), rbegin(), and rend(). The only opportunity for reuse of an underlying, common implementation function, that I see is for the const overloads to call the non-const overload. The question is whether that is wise. Since the derived class would implement the non-const version, there's no telling whether it would try to modify the state of the object, so casting away const-ness in order to call that overload from the const overload could lead to undefined behavior. As I see it, the derived class will have to implement all eight of those functions, so they'll have to be pure virtual in the base class. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (5)
-
Aleksey Gurtovoy -
David Abrahams -
John Nagle -
Reece Dunn -
Rob Stewart