Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

<-- __Chronological__ --> <-- __Thread__ -->

Re: overloading by return type



"Stephen Howe" <[EMAIL PROTECTED]> writes:

| > The question is not if it can be done, but rather if it is needed at all.
| > IMHO it is not.
|
| Nonsense. Here is an example
|
| long setpixel(int x, int y, long colour);    // 1st version
| void setpixel(int x, int y, long colour);    // 2nd version
|
| The first version sets a new colour for a pixel and returns the previous
| colour.
| The second version just sets a new colour for a pixel.
|
| Now, it can be that for some graphics systems, the act of determining the
| old colour can be significant cost, therefore there is no point calling this
| version if the programmer is not concerned with return value. I would expect
|
| setpixel(5, 5, 0L);   // 1st version called as no return value matches
| "void"
| long oldcolour = setpixel(15,15, 0x1F1F1FL);   // 2nd version called

In this *specific* configuration, I think a third option is

    struct setpixel {
      setpixel(int, int, long);
      ~setpixel();  // implements 1st version

      operator long(); // implements 2nd version

    private:
      int x;
      int y;
      long colour;
      bool done;
    };

    inline setpixel::setpixel(int x, int y, long coulour)
              : x(x), y(y), colour(colour), done(false) { }

    inline setpixel::~setpixel()
    {
       if (!done)
         void_returing_setpixel(x, y, colour);
    }

    inline setpixel::operator long()
    {
       long old_colour = nonvoid_returning_setpixel(x, y, colour);
       done = true;
       return old_colour;
    }

Now, you can just have your

   setpixel(5, 5, 0L);   // 1st version called as no return value
   long oldcolour = setpixel(15,15, 0x1F1F1FL);   // 2nd version called

I'm not saying that overload on return-type is not useful.  I'm just
pointing out how you can have you cake and eat it now.

Simple examples are useful to explain what will happen in specific
situations. They rarely capture  what should happen in much more
genral situations, in particular they usually fail to convey the
overall complexity of a functionality.

-- 
                                                        Gabriel Dos Reis
                                            [EMAIL PROTECTED]

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]



<-- __Chronological__ --> <-- __Thread__ -->


Usenet.com



Please check out one of the premium Usenet Newsgroup Service Providers below for access to Usenet.