Re: virtual operator +
On Sep 12, 2:27 pm, Hunk <santosh.udyav...@gmail.com> wrote:
On Sep 12, 4:26 pm, James Kanze <james.ka...@gmail.com>
wrote:> On Sep 11, 4:17 pm, Hunk <santosh.udyav...@gmail.com>
wrote:
I ws wondering if there is a way to implement operator+ in case of
virtual classes.
In general, polymorphism and operator overloading don't work
well together; operator overloading requires a value type for
the return values. (In cases where it is necessary, the
letter/envelop idiom can be used to may a class with value
semantics act polymorphically.)
You are right... learnt it the hard way... you say there is
some way in letter/envelop idiom?
Yes. It gives value semantics with polymorphic behavior. But
there's no free lunch; it typically has a non-negligeable impact
on runtime, and significantly increases coupling between the
derived classes. (Of course, if you want to support binary
operators, you're going to have a lot of coupling between the
derived classes anyway, since you need some sort of double
dispatch.)
For now i have taken the decision to restrict the user to use
only +=. I know this is a very restrictive way , but for now
i know of no other way to tackle the issue.
Look up the letter/envelop idiom (originally from Coplien, if
I'm not mistaken). If performance isn't an issue, it should
solve the problem. (But if performance isn't an issue, why
bother having the length as part of the string type. The real
advantage in doing so is to avoid extra dynamic allocations, and
the letter/envelop idiom uses a lot of extra dynamic
allocations.)
Here's the problem. I have to have a base string class from which two
classes (normal char string and a hash string class ) are derived. The
two derived classes are template classes specifying the sizes. The
base class is a non-template class so that it can be used generically
in the interface classes. the design would look like
class Base_string {
};
template<size>
class Char_string : Base_string {
};
template<size>
class Hash_string: Base_string{
};
So that in the interface class of the application he can use just the
generic Base_string to access the functions and doesnt have to know
whether its a Char or hash string
The issue is in implementing the operator+ . Since all the methods are
virtual in the base class and it should call the desired methods
polymorphically, operator+ is a challenge as it returns a Base_string
object
So if I have something like
Char_string<24> char_string1("Hello");
Char_string<24> char_string2("world");
Char_string<24> char_result;
Base_string* base_a = &char_string1;
Base_string* base_b = &char_string2;
Base_string* base_r = &char_result;
i wouldnt be able to do
*base_r = *base_a + *base_b; as the operator+ would return a
Base_object?
Just a general question: if I add a Char_string< 16 > and a
Hash_string< 14 >, what concrete type should the results have?
This is an important aspect of the problem. But not the only
aspect. Typically, for addition if there are N different
derived types, then you have NxN different functions to
implement, each with potentially a different return type (or
different rules for determining the return type).
Thats a good question. I would prefer giving a compilation
error for this.
In other words, you don't need a common base class, but maybe
(at most) implicit conversions.
This is for the simple reason that Hash_string data members
are different than Char_string. So would'nt know which to
return
I'm not sure what the difference is between a Hash_string
and a Char_string, but for just a single hierarchy, where
the derived types only differ in length, you can probably
work something out with templates, e.g.:
The difference in Hash_string and Char_string is that the
Hash_string class has a hash value computed and stored as a
data member. So comparisons are faster as they would be
comparing integers rather than characters.
You still have to compare the characters, in order to ensure
equality. You only gain when most of the comparisons return not
equal. And depending on your value set, most comparisons
between non-equal strings may return false after only one or two
character comparisons. Using a hash value here is only useful
in a very few, specific cases: a fixed set of strings, for which
you can generate a perfect hash, or value sets where most, if
not all of the strings have a common prefix (URL's, for
example); in the latter case, if this is known, you can arrange
to start comparison after the common prefix, and only go back
and verify commonality if the rest is equal. (For URL's, and
for many other cases, if you start by comparing length, you'll
detect a lot of inequalities immediately.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34