comp.lang.c++

On 2008-02-17 16:32:15 -0500, Lilith said:

> 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);

Actually, I prefer the second version over the first version. That is,
I prefer
dbCopyBitmap (Background.getBitmapNumber(), 0, 0, Screen, 0, 0);
over
dbCopyBitmap (Background, 0, 0, Screen, 0, 0);

The implicit conversion can hurt you later. For example, in the future
you might want to stream out the Background object. In that case, if
you keep the implicit integer conversion operator for Background, then
the following line

ofilestream << Background

might back-fire on you. It is fine if you absolutely sure that
Background class will never have other members other than the integer.
However, in that case, you probably should just use typedef anyway. On
the other hand, if you ever will have more members in Background, then
that implicit integer conversion will hide the oversight of the
programmer for not providing an << operator for Background class.

And this is just one example of implicit conversion trap.

>
> 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.

--

// kira