Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ronald Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Pre and Post actions - an idea.
Message-ID: <26422A73.22809@paris.ics.uci.edu>
Date: 5 May 90 01:20:52 GMT
References: <1990May4.195250.9662@xavax.com>
Reply-To: rfg@ics.uci.edu (Ronald Guilmette)
Organization: UC Irvine Department of ICS
Lines: 41

In article <1990May4.195250.9662@xavax.com> jat@xavax.com (John Tamplin) writes:
>In article <263BF5E3.16516@paris.ics.uci.edu> rfg@paris.ics.uci.edu (Ronald Guilmette) writes:
>...
>>Note that in the class `foo' shown above, the member function member_2 is
>>preceded by a new keyword, i.e. "exempt".  In the scheme proposed here, a
>>call to a member function declared as "exempt" would cause the normal
>>(implicit) pre and/or post member function invocations to be suppressed
>>for that member function only.
>>
>>The syntactic & semantic rules for the "exempt" keyword, would be virtually
>>the same as for the "virtual" keyword, except that it should be allowable for
>>constructors to be declared as "exempt".  (Note that destructors can be
>>virtual, and they should also be allowed to be "exempt".)
>
>The problem with this is that there is no way to implement something like
>the normal readers/writers solution:  n readers with no writers or 1 writer
>with no readers.

I agree.  The simple before & after methods feature that I elaborated on
(it was actually invented/suggested by others before me) was not meant to
solve all sorts of random problems in the world of parallel/concurrent
processing.  It is only meant to provide a simple and straightforward
mechanism for factoring out code that commonly has to be done either at
the beginning or at the end of a mjority of the member functions of a
given class (and possibly its descendants).

>I have not seen the Capsule stuff myself, but from the short except given
>before I would agree that it adds too much fluff for not enough functionality.

This was my primary point.

>I myself prefer to just use standard C++ and insert "mutex.P()" and
>"mutex.V()" around my member functions.

If before/after member functions *were* "standard" C++, you would not have
to introduce all that redundancy (or do all that keyboarding).


// Ron Guilmette (rfg@ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.