www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Check the class of objects

reply Mael <mael.primet gmail.com> writes:
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) ?

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?) 
Jun 05 2008
next sibling parent Urban Hafner <urban bettong.net> writes:
Mael wrote:
 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 think you should have each class report it's "class". This way it's easy to add new subclass to your Image class. If you do it in the Image class (your second idea) you would have to change the Image class every time you add a new subclass! This is (IMHO) bad design as the parent class should only contain stuff that's the same for all subclasses. After all, if that's not the case, what's the point of having subclasses at all? Urban
Jun 05 2008
prev sibling next sibling parent reply janderson <askme me.com> writes:
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
Jun 05 2008
next sibling parent janderson <askme me.com> writes:
janderson wrote:
 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.

BTW: let me clarify what I mean by polymorphism. I'm not talking about the class return from a function its type like bool isGray(); That's almost RTTI. No, what I mean is moving the code that does stuff on isGray() into the image class, if it makes sense. Note, depending on what your doing it may be better to use a flag, or "is function" instead of polymorphism but I'd need an example. -Joel
Jun 05 2008
prev sibling parent Mael <mael.primet gmail.com> writes:
 Its important because of how data is aligned.  If the data is not 

I guess there must be reasons linked to image viewing (like screens that like to have their data padded), but I could not find precise references on this
Jun 05 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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) ?

The correct way is to use the if(cast(ColorByteImage)img) if you have a single attribute you want to switch on. This is implemented in the compiler as a check to make sure the class is of the valid type, and then return the casted value if it is correct, or return null if it is not. You can also get information about the most derived class at runtime using the .classinfo property, but if you have a deep hierarchy, it is less code to just do the cast test. If you want to switch on multiple orthogonal attributes, it would be better to provide properties in the class that indicate which ones are which. For example, the properties grey/color and byte/float could be orthogonal producing 4 different variations. If you only care if an image is grey or color, it would be inefficient to do something like: if(cast(ColorByteImage)img !is null || cast(ColorFloatImage)img !is null) if you could just do: if(img.isColor) -Steve
Jun 05 2008
parent reply Mael <mael.primet gmail.com> writes:
Well, most of the time, the check won't occur a big penalty, because, first the
image hierarchy will be small, and second, the pattern of use will be like :

algorithmprocess(Type)(args)
{
 static switch(Type) dostuff ;
}

algorithm(args)
{
if( isByteImage(img) ) algorithmprocess(ByteImage)(cast(ByteImage)img) ;
...
}

which is a bit ugly but should work.. except I can't make it work :

I did something like

_myalgo( T )( T u )
{
static if (T == ByteImage) { do something ; }
else static if( T == FloatImage) { ..; }
}

myalgo( Image u )
{
if( isByteImage(u) ) _myalgo( ByteImage )(cast(ByteImage)u) ;
 ...
}


and I obtain something like
Error: cannot evaluate opEquals(cast(Object)(ByteImage)) at compile time
(refering to the line "static if( T == ByteImage ) .."

someone knows what is the correct way to check for the arg types?

sorry to ask newb question .. 
  
Jun 05 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Mael" wrote
 Well, most of the time, the check won't occur a big penalty, because, 
 first the image hierarchy will be small, and second, the pattern of use 
 will be like :

 algorithmprocess(Type)(args)
 {
 static switch(Type) dostuff ;
 }

 algorithm(args)
 {
 if( isByteImage(img) ) algorithmprocess(ByteImage)(cast(ByteImage)img) ;
 ...
 }

 which is a bit ugly but should work.. except I can't make it work :

 I did something like

 _myalgo( T )( T u )
 {
 static if (T == ByteImage) { do something ; }
 else static if( T == FloatImage) { ..; }
 }

 myalgo( Image u )
 {
 if( isByteImage(u) ) _myalgo( ByteImage )(cast(ByteImage)u) ;
 ...
 }


 and I obtain something like
 Error: cannot evaluate opEquals(cast(Object)(ByteImage)) at compile time
 (refering to the line "static if( T == ByteImage ) .."

 someone knows what is the correct way to check for the arg types?

Static if can only inspect compile-time objects. This will not look up the derived type. If you did want static if to work, you need to use an is expression. Something like: static if(is(T == ByteImage)) But you are unnecessarily distributing your code, adding unnecessary templates, making it harder to understand/maintain What's wrong with: if(isByteImage(u)) { do something; } ... Either way, you still need the if-else block to determine what the image is at runtime. -Steve
Jun 05 2008
parent reply Mael <mael.primet gmail.com> writes:
 What's wrong with:
 
 if(isByteImage(u))
 { do something; }
 ...
 
 Either way, you still need the if-else block to determine what the image is 
 at runtime.

Well, actually the point is that the action "do something" is consistent accross images except when trying to access data (compare bytes/floats/value/triples), and using a run time if inside the loops would be unefficient, that's why I want to only use static if in the loop, but still share most of the code since it's truly redundant
Jun 05 2008
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
Mael wrote:
 What's wrong with:

 if(isByteImage(u))
 { do something; }
 ...

 Either way, you still need the if-else block to determine what the image is 
 at runtime.

Well, actually the point is that the action "do something" is consistent accross images except when trying to access data (compare bytes/floats/value/triples), and using a run time if inside the loops would be unefficient, that's why I want to only use static if in the loop, but still share most of the code since it's truly redundant

Why not use the Visitor pattern?
Jun 06 2008
parent janderson <askme me.com> writes:
Chris Wright wrote:
 Mael wrote:
 What's wrong with:

 if(isByteImage(u))
 { do something; }
 ...

 Either way, you still need the if-else block to determine what the 
 image is at runtime.

Well, actually the point is that the action "do something" is consistent accross images except when trying to access data (compare bytes/floats/value/triples), and using a run time if inside the loops would be unefficient, that's why I want to only use static if in the loop, but still share most of the code since it's truly redundant

Why not use the Visitor pattern?

This may be a good idea, however I wonder how you'd construct visitor that does the right conversion since you can't have virtual template inheritance. I guess you could write up a function for each version. -Joel
Jun 06 2008
prev sibling parent reply janderson <askme me.com> writes:
Mael wrote:
 What's wrong with:

 if(isByteImage(u))
 { do something; }
 ...

 Either way, you still need the if-else block to determine what the image is 
 at runtime.

Well, actually the point is that the action "do something" is consistent accross images except when trying to access data (compare bytes/floats/value/triples), and using a run time if inside the loops would be unefficient, that's why I want to only use static if in the loop, but still share most of the code since it's truly redundant

I still think you should do this instead: interface Image { void DoSomething1(); } class ByteImage : Image { override void DoSomething1() { //do something; } } class ByteImage : Image { override void DoSomething1() { //do something else; } } ... Use case Image image = new ByteImage(); ... image.DoSomething(); Using a switch statement like you have is very poor design in my book. The great thing about doing it this way is you have no coupling to a switch statement. Someone wants to create a new type of Image they can just by inheriting from your interface. They don't need to update a whole heap of switch statements (which they may not even have access to if you used a lib.) Its becomes more like a plug-in architecture. Sorry to come across as harsh here but if your going to show this to students you should show them the right way to do such stuff. This is called the adapter pattern BTW. Wiiiiiiiiiiiiiiiiiii, -Joel
Jun 06 2008
parent reply janderson <askme me.com> writes:
janderson wrote:
 Mael wrote:
 What's wrong with:

 if(isByteImage(u))
 { do something; }
 ...

 Either way, you still need the if-else block to determine what the 
 image is at runtime.

Well, actually the point is that the action "do something" is consistent accross images except when trying to access data (compare bytes/floats/value/triples), and using a run time if inside the loops would be unefficient, that's why I want to only use static if in the loop, but still share most of the code since it's truly redundant

I still think you should do this instead: interface Image { void DoSomething1(); } class ByteImage : Image { override void DoSomething1() { //do something; } } class ByteImage : Image { override void DoSomething1() { //do something else; } } ... Use case Image image = new ByteImage(); ... image.DoSomething(); Using a switch statement like you have is very poor design in my book. The great thing about doing it this way is you have no coupling to a switch statement. Someone wants to create a new type of Image they can just by inheriting from your interface. They don't need to update a whole heap of switch statements (which they may not even have access to if you used a lib.) Its becomes more like a plug-in architecture. Sorry to come across as harsh here but if your going to show this to students you should show them the right way to do such stuff. This is called the adapter pattern BTW. Wiiiiiiiiiiiiiiiiiii, -Joel

Oh the other piece of the puzzle in your case since your doing the same thing for each case is a template. void DoStuffTemplate(T)(T obj) { //Do nasty stuff to obj (no cast required since is the given type) } class ByteImage : Image { override void DoSomething1() { DoStuffTemplate(this); //Note, can't be in base class } } class ByteImage : Image { override void DoSomething1() { DoStuffTemplate(this); //Note, can't be in base class } } Also if you need to special case something you have 2 options, template spealization or changing the contents of DoSomething1(). -Joel
Jun 06 2008
parent reply mael <mael.primet gmail.com> writes:
Actually, this wouldn't be the right solution,
because the doSomething action is specific to a particular algorithm, and there
will be tens of such algorithms, and I don't want to clutter the main class
with parts of algorithms adapted to each class...
 
Jun 07 2008
parent reply janderson <askme me.com> writes:
mael wrote:
 Actually, this wouldn't be the right solution,
 because the doSomething action is specific to a particular algorithm, and
there will be tens of such algorithms, and I don't want to clutter the main
class with parts of algorithms adapted to each class...
  

http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism http://c2.com/cgi/wiki?SwitchStatementsSmell The following is an excerpt from Scott Meyers’ new book, Effective C++, Third Edition: 55 Specific Ways to Improve Your Programs and Designs. "Effective C++, Third Edition Item 27 7 One thing you definitely want to avoid is designs that involve cascading dynamic_casts, i.e., anything that looks like this: class Window { ... }; ... // derived classes are defined here typedef std::vector<std::tr1::shared_ptr<Window> > VPW; VPW winPtrs; ... for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter) { if (SpecialWindow1 *psw1 = dynamic_cast<SpecialWindow1*>(iter->get())) { ... } else if (SpecialWindow2 *psw2 = dynamic_cast<SpecialWindow2*>(iter->get())) { ... } else if (SpecialWindow3 *psw3 = dynamic_cast<SpecialWindow3*>(iter->get())) { ... } ... } Such C++ generates code that’s big and slow, plus it’s brittle, because every time the Window class hierarchy changes, all such code has to be examined to see if it needs to be updated. (For example, if a new derived class gets added, a new conditional branch probably needs to be added to the above cascade.) Code that looks like this should almost always be replaced with" I think that only becomes appropriate if you use a template or operator overloads to generate this so its generic, less brittle and without evil down casting. -Joel
Jun 07 2008
parent janderson <askme me.com> writes:
janderson wrote:
 mael wrote:
 Actually, this wouldn't be the right solution,
 because the doSomething action is specific to a particular algorithm, 
 and there will be tens of such algorithms, and I don't want to clutter 
 the main class with parts of algorithms adapted to each class...
  

http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism http://c2.com/cgi/wiki?SwitchStatementsSmell The following is an excerpt from Scott Meyers’ new book, Effective C++, Third Edition: 55 Specific Ways to Improve Your Programs and Designs. "Effective C++, Third Edition Item 27 7 One thing you definitely want to avoid is designs that involve cascading dynamic_casts, i.e., anything that looks like this: class Window { ... }; ... // derived classes are defined here typedef std::vector<std::tr1::shared_ptr<Window> > VPW; VPW winPtrs; ... for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter) { if (SpecialWindow1 *psw1 = dynamic_cast<SpecialWindow1*>(iter->get())) { ... } else if (SpecialWindow2 *psw2 = dynamic_cast<SpecialWindow2*>(iter->get())) { ... } else if (SpecialWindow3 *psw3 = dynamic_cast<SpecialWindow3*>(iter->get())) { ... } ... } Such C++ generates code that’s big and slow, plus it’s brittle, because every time the Window class hierarchy changes, all such code has to be examined to see if it needs to be updated. (For example, if a new derived class gets added, a new conditional branch probably needs to be added to the above cascade.) Code that looks like this should almost always be replaced with"

Sorry part of that got cut off. It says something like "replaced with virtual functions".
 
 
 I think that only becomes appropriate if you use a template or operator 
 overloads to generate this so its generic, less brittle and without evil 
 down casting.
 
 -Joel

Jun 07 2008