C
christopher diggins
--
Christopher Diggins
http://www.heron-language.com
I agree. It also doesn't generalize to the large number of general design
cases that approximate the FuBar example.
Thanks for bringing this up.
Or you could take it as evidence of an idea that was ahead of its time.
Historic rejection of a similar idea does not reduce an idea's validity for
reevaluation. By this argument, we would still be convinced the world is
flat.
Thank you for your insightful comments.
Christopher Diggins
http://www.heron-language.com
Christopher Diggins
http://www.heron-language.com
Marco Manfredini said:Creating a _copy_ of the BaseFuBar subobject isn't something that could
easily be called a "common way to appoximate" the intended design.
could it? I mean copying can have quite some expensive effects..
I agree. It also doesn't generalize to the large number of general design
cases that approximate the FuBar example.
Another way of "approximation" would be to write a
thunking-implementation of IFuBar:
template<class T>
struct IFuBarImpl : public IFuBar
{
T &impl;
void FuBar() { impl->FuBar(); }
};
This has the same effect without slicing, but is more extensive and less
confortable to use, may involve argument/return value copies (if you
use IFuBar). So I think the author has a point here: If you want to
extract a type, you're adding overhead somewhere.
Thanks for bringing this up.
In fact, to become historical, GNU C++ almost *had* exactly what the
author suggested in form of the "signature" extension which hasn't
survived the transition to version 3.* -- you could take this as an
evolutionary argument for the significance of the proposed language
construct to the c++ community...
Or you could take it as evidence of an idea that was ahead of its time.
Historic rejection of a similar idea does not reduce an idea's validity for
reevaluation. By this argument, we would still be convinced the world is
flat.
Marco
Thank you for your insightful comments.
Christopher Diggins
http://www.heron-language.com