This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc-4.0-virtual function return type


> > 3) It is (possibly) incomplete in that say, an 'int' returning function
> > cannot be overridden by a 'short' returning function, which some might
> > say is more specialized.
>
> This seems a very weak (almost bogus) counter argument. Yes, some might
> say that, but then some might say almost anything. It is obvious that
> this is entirely unrelated to me to the feature being discussed. In any
> case, fixing 2) by documenting the feature will cure this problem.
>
> > 4) It does not work for Ts that have non-trival destructors -- either
> > the destructor is not called, or the caller of the virtual function must
> > know which instance will actually be called so the dynamic type is
> > known (this rather misses the point of virtual function calls)[%].
>
> That's more serious to me. I think that unless this can be addressed
> cleanly, it's a strong argument, though it still seems this is a useful
> language extension.


Writing a base class as general interface with void* return type in its 
methods, seems to be useful. On the other hand, what for do you need an 
interface that only tells you, this function will return anything? The 
interface is then quite unnecessary- without casting you can't do anything 
with it. 

Do you know any situation where this is really useful? I can't imagine any at 
the moment, which does not mean that this feature can't be useful at all. 
Thats why I general dislike not implementing, easy to implement features 
which don't harm performance.

But it seems to me that this isn't the case, as Nathan wrote in his last 
paragraph ("it does not work for Ts that have non-trivial destructors..."). 
This destructor problem for me, is a good reason, for not implementing the 
feature. (As far as I've understood the problematic, but I think I have)

Best regards,


Robert Klotzner


By the way, a bit off topic: is there anyone like me, who doesn't like C++ 
templates? Could anyone imagine a better alternative?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]