From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,f92fbb4a0420dd57
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,f92fbb4a0420dd57
X-Google-Attributes: gid103376,public
From: Mike Young <mikey@mcs.com>
Subject: Re: some questions re. Ada/GNAT from a C++/GCC user
Date: 1996/03/30
Message-ID: <315CDCF9.31AF@mcs.com>#1/1
X-Deja-AN: 144971928
references: <wnewmanDoxrCp.DKv@netcom.com>
 <4je9ju$174r@watnews1.watson.ibm.com>
 <ROGOFF.96Mar28134118@sccm.Stanford.EDU> <4jhe1v$m0g@dayuc.dayton.saic.com>
content-type: text/plain; charset=us-ascii
organization: Fen Software, Inc.
mime-version: 1.0
newsgroups: comp.lang.ada,comp.lang.c++
x-mailer: Mozilla 2.0GoldB1 (Win95; I)
Date: 1996-03-30T00:00:00+00:00
List-Id: <comp.lang.ada>

John G. Volan wrote:
> 
> In article <315AC5E7.3A77@escmail.orl.mmc.com>
> Ted Dennison, dennison@escmail.orl.mmc.com writes:
> 
> >If you want to declare variables later in the code just
> >use a declare block:
> >   declare
> >      Var1 : My_Type;
> >      ...
> >   begin
> >      Var1 := My_Value;
> >      ...
> >   end;
> >
> >This has the added benefit of limiting the scope of Var1 to the
> >begin..end  block of code.
> 
> There is another benefit, but it isn't obvious unless you take into
> account the concurrency aspects of Ada:
> 
> A C programmer would complain about having to introduce an extra
> begin/end block in order to introduce variables.  Isn't the scope
> of a variable well-defined in C, even without this extra baggage?
> It just extends from the declaration to the end of whatever block
> you're already in.
> 
> An Ada programmer would counter that, in Ada, some variables might be
> instances of _task_ types.  By definition, a task object gets created
> when its declaration is elaborated, but it does not get _activated_
> (i.e., it doesn't start executing its statements) until you hit the
> "begin" of the enclosing block.  This guarantees that everything in 

  [ ... some worthy thoughts snipped ... ]

> 
> C, of course, has no concurrency abstractions built in (nor does C++,
> last time I checked), so, gee, I guess this isn't an issue in C. :-)

============
Hmmmm. Lacking a language based synch method doesn't mean we always go 
straight to the semaphore library. I commonly use thin wrappers to guard 
precious resources -- for example: mutexes, semaphores, files, 
or database sessions. Local scoping allows precise control of lifetimes, 
and ensure release even when exceptions are possible:

void foo ()
{
   //-- some setup code here, perhaps
   ...
   {               // local scope
     LocalMutex<BazType> foo(mutexHandle);
     BazType & bar = foo.openResource();
     ...           // use the protected resource
   }               // end local scope. LocalMutex releases the resource
   ...
}