(off-topic) RE: [Doxygen-users] Documenting IDL

[Stephen G. <ste...@pi...>]

> From: dox...@li...
> [mailto:dox...@li...]On Behalf
> Of Victor A.
> Wagner, Jr.
> Sent: 08 May 2001 12:17
> To: dox...@li...
> Subject: RE: [Doxygen-users] Documenting IDL
>
>
> Slightly off topic (maybe this is C++ style):
> Is there some reason you chose to write IsValid() rather than
> overloading a
> conversion to void*:
>
> operator void*() {return static_cast<void*>(IsValid());}
> would suffice.
>
> Then you could write (like the 'real pointer' you're emulating:
> ThingPtr fred;
> .
> .
> .
> if (fred)
>     fred->DoSomething();
>
> similarly for operator !()
> so you can write:
> if (!fred)
>     blah....blah...
> At Tuesday 2001/05/08 04:02, you wrote:
> > > -----Original Message-----
> > > From: dox...@li...
> > > [mailto:dox...@li...]On
> Behalf Of Dale
> > > Ogilvie
> > > Sent: 08 May 2001 06:27
> > > To: 'dox...@li...'
> > > Subject: [Doxygen-users] Documenting IDL
> >[deleted]
> >There is a problem though - many "smart-pointer" classes
> also declare
> >their own
> >methods: quick example, I have a ref counting pointer that declares
> >IsValid() to
> >check for
> whatever-the-condition-is-that-corresponds-to-a-non-null-pointer:
> >
> >  ThingPtr fred;
> >  ..blah..
> >  if (fred.IsValid())
> >     fred->DoSomething();
> >
> >[I have less trivial methods on some pseudo-pointer classes as well]
> >
> >So if you convert from ThingPtr to Thing every time there is
> the risk of the
> >documentation's reader missing out on the other methods of ThingPtr.
> >

Ah, the number of problems trying to do that caused me :-(

I did originally have an operator int() that could be used in if-statements,
which worked fine using VC++2 through to VC++4; then a client bought VC++5 and
it became ambiguous (I forget the precise reason why), so everything switched to
IsValid() from then on.

I would be tempted nowadays to try and hid IsValid(), but I take the attitude
that if something was done because one compiler needed it (and the results are
still legal) then keep it in, because the code will be used on a.n.other
compiler next week, or the week after...

Even with a decent compiler, there is the vexed question of what the cast
operator should be casting _to_ - you don't really want to return another
pointer type, as that looks too much like you're providing a backdoor. These
days, 'bool' would be a reasonable choice (now that the compilers actually
support 'bool'). The best choice would be the mythical 'logical' type that 'if',
'while' etc use, but that isn't available :-(

Stephen Goudge