Re: Virtual method inlining
Leigh Johnston <leigh@i42.co.uk> wrote:
On 10/11/2012 09:19, Tobias M??ller wrote:
Leigh Johnston <leigh@i42.co.uk> wrote:
On 10/11/2012 00:10, 1 2 wrote:
On Nov 9, 5:46 pm, Leigh Johnston <le...@i42.co.uk> wrote:
On 09/11/2012 22:35, 1 2 wrote:
On 9 nov, 10:39, Leigh Johnston <le...@i42.co.uk> wrote:
On 09/11/2012 07:12, 1 2 wrote:
On 8 nov, 18:28, Leigh Johnston <le...@i42.co.uk> wrote:
On 08/11/2012 20:15, 1 2 wrote:
And in the code that uses the polymorphic operations, we use a
template parameter, but make sure that it implements the interface by
using a static_assert that tests a std::is_base_of:
template<class Shape>
void DrawShape(Shape* s)
{
static_assert(std::is_base_of<IShape, Shape>::value, "Shape must
implement IShape");
s->Draw(200, 100);
}
I can definitely see this being used at large scale.
What is the point of doing that? The compiler doesn't know that Draw is
"final" so still requires dynamic (virtual dispatch) unless it knows
Shape is the most derived type; the "final" overrider in C++11 improves
the situation somewhat.
OK, then maybe it can be changed to the following to disable calling
through the vtable:
template<class Shape>
void DrawShape(Shape* s)
{
static_assert(std::is_base_of<IShape, Shape>::value, "Shape must
implement IShape");
s->Shape::Draw(200, 100);
}
Totally pointless.
Why? It accomplishes what I said earlier: combine the contracts
provided by runtime polymorphism with the fast (w/o virtual dispatch)
calls of compile-time polymorphism.
Pointless because you need the object that draws all the shapes to be
aware of all the different types of shapes which is a nonsense from a
design point of view.
No it doesn't need that. Where in this code:
template<class Shape>
void DrawShape(Shape* s)
{
static_assert(std::is_base_of<IShape, Shape>::value, "Shape must
implement IShape");
s->Shape::Draw(200, 100);
}
do you see awareness of all the different types of shapes? It's just
like the original runtime polymorphism and compile-time polymorphism
examples in my reply to Tobias M??ller, except that I basically
combined the two into one.
The code that instantiates the template has to pass an object of the
correct type to benefit from your "optimization" which means that code
needs to know all the different types which is a nonsense from a design point of view.
That's exactly the point of compile time polymorphism. The caller can of
course be a template itself, but at one point you have an object of a
concrete type anyway, that's where the template is instanciated.
This whole concept is of course pointless if you want to draw an
inhomogenous collection of shapes. There you have to find out the concrete
type by hand, which is worse that normal virtual function dispatch IMO.
That was the point I was making: if a single object is responsible for
drawing all the shapes then for it to benefit from this dubious
"optimization" it needs to be aware of all the different sub-class types
in order to correctly instantiate this useless function template.
I really cannot that single object you are talking about.
For example if you want to draw all pixels of an Image, you could use the
same rendering algorithm for your collection of pixels and it will be
nicely optimized due to inlining.
I wouldn't even consider rendering pixel like this with runtime
polymorphism.
Consider the following example:
class Drawable
{
public:
virtual void draw(/*...*/) = 0;
};
template <typename Iterator>
void drawSequence(Iterator begin, Iterator end)
{
static_assert(std::is_base_of<Drawable,
std::iterator_traits<Iterator>::value_type>::value, "Must implement
Drawable");
for (Itetator it = begin; it != end; ++it)
it->draw(/*...*/);
}
class Pixel : public Drawable
{
public:
virtual void draw(/*...*/) final { /* simple */ }
};
class Image : public Drawable
{
public:
virtual void draw(/*...*/) final
{
// can be optimized, value type is statically known
drawSequence(pixels.begin(), pixels.end());
}
private:
std::vector<Pixel> pixels;
};
class Path : public Drawable
{
public:
virtual void draw(/*...*/) final { /* complex */ }
};
typedef boost::indirect_iterator<std::vector<Drawable*>, Drawable> ItD;
int main(/*.../)
{
std::vector<Drawable*> objects;
objects.push_back(new Image);
objects.push_back(new Path);
// Normal runtime polymorphism
draw_sequence(ItD(objects.begin()), ItD(objects.end()));
}
C++ templates are great especially for things
such as generic containers/algorithms, traits and policies but you are
misusing them: you need to learn how to do proper OOP.
I know proper OOP. Normally I would just use runtime polymorphism and
no templates at all (in this case), but this is more of an
optimization issue (maybe premature optimization if the virtual call
overhead is negligible compared to the actual work of the method, but
not otherwise).
It is an "optimization" I have never had to employ modulo *normal* (read:
"sane") template use.
Then again it seems to be a real demand amongst 'sane' developers to
restrict the types for template arguments, how else do you explain C++
'concepts'? IShape is just a poor men's 'concept'.
Typeclasses in Haskell or Traits in Rust (www.rust-lang.org) are also
conceptionally similar.
Like I said earlier C++ templates are great I just feel they are being
misused in this case. This is a classic example of premature optimization.
I think in a program or library that deals with graphics, this an important
design decision, not premature optimization.
Tobi