Check the class of objects

[janderson]

Mael wrote:
> Hello,
> 
> another newb question ! I'm trying to design a large image library,
> that should be usable enough for students to learn it quickly, but
> powerful enough to be used in medium-sized projects
> 
> Since I'm building several image classes (depending on the
> characteristics of the image, such as grey / color, byte / float,
> etc), I can either include a flag in each image that tells its class
> ("I'm a color-byte image", "I'm a grey-byte image", etc.), or use
> many if( cast(ColorByteImage)img !is null ) { doactionColorByte ; }
> to check the type. What would be the most efficient way to test the
> type of the class ? How is the cast(Class)v construct implemented in
> the compiler (I guess there's some equivalent of a "i'm a color-byte
> image" flag in the class structure) ?

I don't like either approaches.  RTTI should be looked at with a 
suspicions eye in my opinion (ie has its uses but the this is not one of 
them).  Efficiency wise, dynamic casts can be slow depending on how the 
compiler implements them it may need to traverse each item in the tree. 
  So the deeper the tree (another thing you should avoid) the worse the 
performance.  enum/flag compares are pretty efficient (as long as they 
aren't strings).

Polymorphism's bread and butter is this type of problem.  Virtual 
lookups aren't that much worse when compared to enum flag.  Its 2 memory 
lookups and 1 jump.  Look at the surrounding code around the virtual, 
how much work is that doing comparatively?  Probably a whole lot more. 
I wouldn't prematurely optimize this sort of thing.

> 
> Another question for people designing graphic libraries : would you
> recommend to pad image rows on 32-bits ? I hardly see when this is
> useful in practice (usually it's done for efficiency reasons, but I
> don't see how this would improve speed significantly, except if
> you're trying to extract a couple of lines of an image...). The only
> advantage I see is that it permits to make fast 'ImageViews' of a
> subset of an Image without having to duplicate it. Maybe some webcams
> give padded output, and it would therefore be faster to have them
> output directly in the image ? Someone sees the main reason (I might
> be missing some thing here?)
> 


I'm not exactly sure what sort of padding your talking about so I'll 
take a stab at what I think you mean.  I think you more or less say this 
but I'll clarify it a bit.

Its important because of how data is aligned.  If the data is not 
aligned the compiler will have to do extra work to realign the data 
before it can do work on it.  Or alternatively the software will work on 
each byte individually rather then working on the whole 32-bits at once 
(or even several 32-bits at the same time).   That's of course on a 
32-bit machine, on a 64-bit machine you might want to align to 64-bits 
in some cases.  It can make a big difference to performance since there 
are 1000s X 1000s of pixels in an image.

I hope that was helpful.
-Joel