Cass object returning a value by name?

Discussion in 'C++' started by Lilith, Feb 16, 2008.

  1. Lilith

    Lilith Guest

    Sorry if the subject line is vague.

    I *think* I've seen discussion in the past of this capability but I'm
    unable to find it. 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;


    };
    ..
    ..
    X a;
    X b;
    ..
    ..
    xxxCopy (a, b);

    xxxCopy() is unrelated to class X and works on integer values that are
    stored within its own system. My class has to store the number used
    by the system that uses xxxCopy(). I know I could provide a member
    function of X to return the value but using the name of the object and
    not a method within it is more instinctive for my uses.

    I think I've read that it's possible to over load an operator to
    provide this functionality but at the time it was of interest but no
    immediate need. Then again, I may have just had a dream about it.

    --
    Thanks,
    Lilith
     
    Lilith, Feb 16, 2008
    #1
    1. Advertising

  2. Lilith

    Jerry Coffin Guest

    In article <>,
    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.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Feb 16, 2008
    #2
    1. Advertising

  3. Lilith

    Lilith Guest

    On Sat, 16 Feb 2008 13:32:08 -0700, Jerry Coffin <>
    wrote:

    >In article <>,
    > 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.

    Once more, thanks.

    --
    Lilith
     
    Lilith, Feb 16, 2008
    #3
  4. Lilith

    Kira Yamato Guest

    On 2008-02-16 16:58:58 -0500, Lilith <> said:

    > On Sat, 16 Feb 2008 13:32:08 -0700, Jerry Coffin <>
    > wrote:
    >
    >> In article <>,
    >> 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?

    --

    // kira
     
    Kira Yamato, Feb 16, 2008
    #4
  5. Jerry Coffin wrote:
    > operator int() { return XNumber; }


    Basically Jerry is right, but you'd probably want to indicate that the
    conversion does not modify your X object, by adding a "const":

    class X {
    int XNumber;
    public:
    operator int () const { return XNumber; }
    };

    Lilith wrote:
    > 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.


    The dangerous thing about those conversion operators is that their
    conversion happens so "implicitly". Fortunately the next C++ Standard
    will allow you to declare the conversion operator as "explicit". But I
    guess your compiler won't support it yet. Anyway, if you want to know
    more, read: "Explicit Conversion Operator Draft Working Paper (revision
    3)", by Lois Goldthwaite, Michael Wong, Jens Maurer, and Alisdair
    Meredith - www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf

    [Oops, my original reply went to the wrong newsgroup: comp.lang.c It's
    because of a bug in my good old (VERY old) newsgroup client. Hmmm,
    maybe I should upgrade!]

    Kind regards,
    --
    Niels Dekker
    http://www.xs4all.nl/~nd/dekkerware
    Scientific programmer at LKEB, Leiden University Medical Center
     
    Niels Dekker - no return address, Feb 16, 2008
    #5
  6. Lilith

    Jerry Coffin Guest

    In article <>, lid
    says...

    [ .... ]

    > Basically Jerry is right, but you'd probably want to indicate that the
    > conversion does not modify your X object, by adding a "const":


    Quite true. In fact, nearly _all_ conversion operators should be const
    -- they should supply a value FROM the object, but the original object
    should remain unchanged.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Feb 17, 2008
    #6
  7. Should a wrapper have a conversion operator T&()? [Cass object returninga value by name?]

    Jerry Coffin wrote:
    > In fact, nearly _all_ conversion operators should be const
    > -- they should supply a value FROM the object, but the original object
    > should remain unchanged.


    What do you think of the (const) conversion operator of Boost's wrapper
    template class value_initialized<T>? value_initialized<T> wraps an
    object of type T, and it has a conversion operator to a reference-to-T,
    providing full access to the object it wraps:

    // From Boost: www.boost.org/libs/utility/value_init.htm
    template<class T> class value_initialized {
    public:
    operator T&() const;
    T& data() const;
    ...
    };

    I'm thinking of removing this conversion operator, and replacing it by a
    set of dereference and arrow operators, overloaded for const and
    non-const:

    template<class T> class value_initialized {
    public:
    const T & operator*() const;
    T & operator*();
    const T * operator->() const;
    T * operator->();
    T& data() const;
    ...
    };

    Basically Fernando Cacciola - the creator and owner of
    boost::value_initialized - already likes this idea, but I would
    appreciate having your opinion as well :)


    Kind regards,
    --
    Niels Dekker
    http://www.xs4all.nl/~nd/dekkerware
    Scientific programmer at LKEB, Leiden University Medical Center
     
    Niels Dekker - no return address, Feb 17, 2008
    #7
  8. Lilith

    Jerry Coffin Guest

    Re: Should a wrapper have a conversion operator T&()? [Cass object returning a value by name?]

    In article <>, lid
    says...

    [ ... ]

    > Basically Fernando Cacciola - the creator and owner of
    > boost::value_initialized - already likes this idea, but I would
    > appreciate having your opinion as well :)


    It looks pretty good to me, with the caution that (of course) it breaks
    any existing code that uses the conversion. IMO, it's enough of an
    improvement that I'd favor it unless the existing conversion was in
    _really_ wide use.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Feb 17, 2008
    #8
  9. Lilith

    Lilith Guest

    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 <>,
    >>> 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
     
    Lilith, Feb 17, 2008
    #9
  10. Lilith

    Lilith Guest

    On Sat, 16 Feb 2008 23:09:29 +0100, Niels Dekker - no return address
    <> wrote:

    >Jerry Coffin wrote:
    >> operator int() { return XNumber; }

    >
    >Basically Jerry is right, but you'd probably want to indicate that the
    >conversion does not modify your X object, by adding a "const":
    >
    > class X {
    > int XNumber;
    > public:
    > operator int () const { return XNumber; }
    > };


    Got ya.

    >Lilith wrote:
    >> 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.

    >
    >The dangerous thing about those conversion operators is that their
    >conversion happens so "implicitly". Fortunately the next C++ Standard
    >will allow you to declare the conversion operator as "explicit". But I
    >guess your compiler won't support it yet. Anyway, if you want to know
    >more, read: "Explicit Conversion Operator Draft Working Paper (revision
    >3)", by Lois Goldthwaite, Michael Wong, Jens Maurer, and Alisdair
    >Meredith - www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2437.pdf


    Thanks for the link. I'll have a look.

    >[Oops, my original reply went to the wrong newsgroup: comp.lang.c It's
    >because of a bug in my good old (VERY old) newsgroup client. Hmmm,
    >maybe I should upgrade!]


    >Kind regards,


    --
    Lilith
     
    Lilith, Feb 17, 2008
    #10
  11. Lilith

    Kira Yamato Guest

    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 <>,
    >>>> 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
     
    Kira Yamato, Feb 17, 2008
    #11
  12. Re: Should a wrapper have a conversion operator T&()?

    Jerry Coffin wrote:
    > It looks pretty good to me, with the caution that (of course) it breaks
    > any existing code that uses the conversion. IMO, it's enough of an
    > improvement that I'd favor it unless the existing conversion was in
    > _really_ wide use.


    Thanks! I'm glad that you agree that it would be better if a wrapper
    class like boost::value_initialized wouldn't have a conversion operator,
    returning a reference to the object it wraps...

    Kind regards,

    Niels
     
    Niels Dekker - no return address, Feb 18, 2008
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob Meade
    Replies:
    1
    Views:
    303
    Rob Meade
    May 22, 2004
  2. ding feng
    Replies:
    2
    Views:
    2,876
    ding feng
    Jun 25, 2003
  3. Replies:
    11
    Views:
    685
    Christos Georgiou
    May 2, 2006
  4. Ralph
    Replies:
    4
    Views:
    337
    Ralph
    Jun 12, 2008
  5. Jean-Michel Pichavant

    Mocked object returning another Mocked object

    Jean-Michel Pichavant, Jul 13, 2012, in forum: Python
    Replies:
    1
    Views:
    214
    Ulrich Eckhardt
    Jul 13, 2012
Loading...

Share This Page