[omniORB] omniEvents 2.6.1 install error on irix6

Alex Tingle alex at firetree.net
Sat Apr 23 16:31:45 BST 2005


Hi Maks,

Interesting point...

On Fri, 22 Apr 2005 14:50:28 +0200
Maks Verver <m.verver at student.utwente.nl> wrote:

>> Are you using an old compiler? That line should work, but it
>> is being a bit clever-clever. WriteLock() constructs a
>> temporary object of type WriteLock. It survives while the
>> output() method is executing, and it is then destroyed.
> 
> No, actually, the IRIX compiler is right and some others are
> broken. I would  expect GCC 3 to produce the same error
> (although I didn't actually test it  with omniEvents).
> 
> The thing is that temporaries are always const objects.
> Therefore,  WriteLock().os is a const object and cannot be
> passed to output() which  expects a non-const reference
> argument.
> 
> I know there are some older compilers which are forgiving about
> this (I  suppose there is no compelling
> implementation-technical reason to make  temporaries const);
> probably you are using one of them (GCC 2? VC++ 6?)

None of the compilers I've tried this code on has ever choked on
it (GCC 2 & 3, aCC on HP-UX, CC on Solaris, VisualAge on AIX, cxx
on Tru64). One emits a warning, I forget which.

You are not quite right to say that temporary objects are always
const. I CAN call a non-const method on a temporary object, BUT I
cannot bind a temporary object to a non-const reference. I don't
think my code breaks this rule here, so I suspect SGI's compiler
may be incorrect. Here's a simple example that captures the
essence of the code:

  int i; // global

  class C { // Class wraps a reference to 'i'.
  public:
    int& m;
    C():m(i){}
  };

  void increment(int& v) {
    ++v;
  }

  int main(int argc, char** argv) {
    i=::atoi( argv[1] );
    increment( C().m );
    std::cout << i << std::endl;
    return 0;
  }

`C()' makes a non-const temporary object.
`C().m' is a non-const reference to a NON-TEMPORARY int, so I'm
entitled to pass it to the `increment()' function.

However, just because you CAN do a thing, doesn't mean you SHOULD.
I think I'll take out this code - it's a bit too clever clever for
its own good. ;-)

-Alex

-- 
:: alex tingle
:: http://www.firetree.net/consulting/
:: alex.tingle AT firetree.net  +44-7901-552763 



More information about the omniORB-list mailing list