comp.lang.c++

On Sat, 16 Feb 2008 17:06:53 -0500, Kira Yamato
wrote:

>On 2008-02-16 16:58:58 -0500, Lilith said:
>
>> On Sat, 16 Feb 2008 13:32:08 -0700, Jerry Coffin
>> wrote:
>>
>>> In article ,
>>> lilith@dcccd.edu says...
>>>
>>> [ ... ]
>>>
>>>> Essentially I have a context in which at makes
>>>> sense to have a class object return an integer value when the object's
>>>> name is used.
>>>>
>>>> class X {
>>>>
>>>> int XNumber;
>>>
>>> [ ... ]
>>>
>>> operator int() { return XNumber; }
>>>
>>> Keep in mind that this allows implicit conversion of an X to an int,
>>> even when you may not want that. Conversion operators can be handy, but
>>> they can also be somewhat dangerous.
>>
>> Many thanks. I anticipated the hazard and have tried think of an
>> instance where this might be a problem but at this time I can't.
>> However, I'll be on the alert as I progress through this development
>> and if it presents a problem I'll go the less intuitive route.
>
>A rule of thumb that I used to determine if conversion operator should
>be used or not, is to ask myself if my class and the conversion type
>obey the "is a" relationship in an object oriented fashion.
>
>So, my question to you is this: is your class X an integer, in the OOP sense?

Within the context I'm dealing with I think I can say yes. To give a
little perspective...

The API I'm dealing with is Dark GDK, a game development API from The
Game Creators. It's free for personal use and give-away applications.
It says it'd designed for C++ but the only thing C++ about it that I
see is a bit of polymorphism. Otherwise the system is nothing more
than calls that seem more procedural than OO.

The basic "objects" of the system are sprites, images and bitmaps. One
doesn't declare a sprite, one determines a number to use to represent
a sprite (or image or bitmap) and passes it to a function. Apparently
the system maintains some sort of internal collection of these items
rather than the user keeping an object in their program. So,
procedurally I'd create an image by loading it from a file and assign
it a number, say 10, when I make the call to load the image. When I
want to assign a sprite to use the image I call

dbSprite (6, 128, 256, 10);

where 6 is the number I want to assign to the sprite. The 2nd and 3rd
parameters are the x and y position and 10 is the image number to use.
If I don't maintain the x and y position somewhere in my program I
have to make calls to other functions to retrieve them, once again by
sepcifying the intended sprite number, one at a time.

I'd rather encapsulate the entire thing in a class object so my
sprite, or whatever, knows what number it is, where it's supposed to
be and can act on its own information. I don't think the overhead for
the encapsulation is any worse than having to make two calls to know
what the x and y positions or it's rotation, offset or any other
attribute is.

The screen is always bitmap #0, so if I have a bitmap I'm drawing to
for my background, call it bitmap #1, and I'm ready to write it to the
screeen I make the call

dbCopyBitmap (1, 0, 0, 0, 0, 0);

where the 4th parameter is the number representing the screen and the
other zeros reperesent the upper left corner of source and
desitination to copy from/to. (There may be some other parameters
providing a rectangle to draw but I'm not going to look it up right
now.)

AAR, if I'm going to have to make a call like this I'd rather write

dbCopyBitmap (Background, 0, 0, Screen, 0, 0);

where Background would be an object of my bitmap class and, when
passed to the function would result in the numeric value of the bitmap
rather than calling

dbCopyBitmap (Background.getBitmapNumber(), 0, 0, Screen, 0, 0);

I know I could use enumeration but there are potential pitfalls there
too. Eventually, I'll probably encapsulate a CopyToScreeen ()
function within my bitmap class that has a call that makes to call to
the Dark GDK function and it won't matter so much. But I may want to
copy to other bitmaps by name also.

--
Lilith