dan@dyndata.UUCP (Dan Everhart) (05/03/90)
Speaking of non-sequiturs....
It might be neat to be able to define objects anonymously, that is, if
you wrote
Xyz;
an instance of class Xyz with no name would be created. Why? If the
object was created only for the side effects caused by the constructor
and destructor. For example, here's a way to implement critical
sections:
class Critical {
Critical ()
{ ShutOffInterrupts (); };
~Critical ()
{ TurnOnInterrupts (); };
};
If you didn't have to name objects you could just say
{
Critical;
... // Stuff in here runs with interrupts disabled.
}
// Interrupts snap back on when the block is exited.
Of course you can just put in any old name for the object and it
will work. But why bother if there is never a reference to the
object?
No doubt somebody is going to suggest naming the object "section" in
the above example. Oops, I just did.cline@cheetah.ece.clarkson.edu (Marshall Cline) (05/03/90)
In article <351@dyndata.UUCP> dan@dyndata.UUCP (Dan Everhart) writes: ..... For example, here's a way to implement critical sections: > class Critical { > Critical() { ShutOffInterrupts(); } > ~Critical() { TurnOnInterrupts(); } > }; ... > { > Critical; > ... // Stuff in here runs with interrupts disabled. > } > // Interrupts snap back on when the block is exited. ... Clearly this is an effective mechanism for mutual exclusion. However it is dangerous to allow users to directly control the hardware (what if they went into an infinite loop after they shut off interrupts?). Another concern is its coarse granularity -- other solutions exist which provide finer granularity of control. For example, Ouij (the Concurrent-C++ mailing list admin -- see below for subscription info), posted the following on how mutual exclusion can be obtained on a class-by-class and member-by-member basis: | ``Capsules: A shared Memory Mechanism'' [Gehani, 1988] describes how | Concurrent C++ users could use a `capsule' to describe shared memory | constructs: facilties which Concurrent C lack since it is based on a | message passing model. In brief a capsule looks as follows: | | Capsule Foo { | int a, b; | public: | int reader(int k) { k = a;} | int writer(int k) { a = k;} | int useless(int k) { if (a == 1 && k > b) cout << "?????\n"; } | sync: | accept reader(k) suchthat (evaluation criteria) by (eval_criteria) | par: | { reader, useless* } | }; | | Capsules allow the programmer to specify a critical region and attach | synchronization conditions (using the `suchthat' and `by' clauses). | The `par' section is used to specify which member functions can execute | in parallel. The * denotes that multiple instances of of a member | function can execute. For those interested in further discussion, send a subscription request to the Concurrent-C++ mailing list's request server: either: info-ccc-request@xurilka.uucp or: ..!uunet!xurilka!info-ccc-request Marshall -- =============================================================================== Marshall Cline/ECE Department/Clarkson University/Potsdam NY 13676/315-268-3868 cline@sun.soe.clarkson.edu, bitnet: BH0W@CLUTX, uunet!clutx.clarkson.edu!bh0w Career search in progress: ECE faculty. Research oriented. Will send vita. ===============================================================================
roger@procase.UUCP (Roger H. Scott) (05/05/90)
In article <351@dyndata.UUCP> dan@dyndata.UUCP (Dan Everhart) writes: >It might be neat to be able to define objects anonymously ... Not only *might* it be neat, it *is* neat: SomeClass(); constructs an anonymous instance of class SomeClass and the immediately proceeds to destroy it. You were warm.
beard@ux1.lbl.gov (Patrick C Beard) (05/07/90)
In article <139@logo.procase.UUCP> roger@procase.UUCP (Roger H. Scott) writes: #In article <351@dyndata.UUCP> dan@dyndata.UUCP (Dan Everhart) writes: #>It might be neat to be able to define objects anonymously ... #Not only *might* it be neat, it *is* neat: # SomeClass(); #constructs an anonymous instance of class SomeClass and the immediately proceeds #to destroy it. You were warm. Yes, I tried it, and it does work. Where is this documented? This still has the semantics of a function call however, and one could just as easily write a routine that has static data and call that. And another point, your message implies that the object is immediately destroyed. The original poster was using the fact that the destructor would get called at the end of the scope. I see that as an advantage. ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey - -------------------------------------------------------------------------------