[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