comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Parsing a line into strings
Date: 1998/07/09
Date: 1998-07-09T00:00:00+00:00	[thread overview]
Message-ID: <dewar.899956473@merv> (raw)
In-Reply-To: 6o14rm$3nv@drn.newsguy.com

Nasser says

<<one of things I like about the Ada language is its portability. I hope
we dont get to the situation where some Ada 95 code compile on one
compiler but not on another. may be this unrestricted_access attribute
should be implemented by other compiler vendors to match GNAT.
>>

The Ada language is not portable, rather the Ada language facilitates
writing portable code. If portability is a requirement, then if you
take appropriate care, Ada is a particularly good language to meet
this requirement.

However, it is most certainly possible to write non-portable code, and
this is not necessarily a bad thing, it depends on whether or not portability
is a requirement.

For the GNAT library, the only requirement is that it be portable to
any implementation of GNAT, it is simply not a requirement that it
be able to be compiled on other compilers. This may be possible for
some of the simpler packages, and if so fine, but the requirements
for these routines are performance, functionality, and a convenient
interface -- portability is simply not a requirement, so we feel
absolutely free to use non-portable attributes and pragmas when
implementing these packages.

You can't expect all other vendors to implement Urestricted_Access.
Remember that several vendors fought furiously any attempt to provide
features of this kind, because they are not display-friendly. Since at
least one Ada 95 compiler uses displays, you can anticipate that this
implementation at least is unlikely to implement Urestricted_Access,
and that situation is unlikely to change.

At the same time, we definitely feel free to add useful pragmas and
attributes to GNAT (see the GNAT programmers guide for a list). Of
course if portability to other Ada compilers (as opposed to portability
to other GNAT implementations) is a consideration, then you should not
use these implementation dependent attributes and pragmas.

One extra features that GNAT implements that I *do* think all vendors
should implement is two extra Restriction identifiers:

   pragma Restrictions (No_Implementation_Pragmas);
   pragma Restrictions (No_Implementation_Attributes);

which respectively prevent any use of implementation dependent
pragmas or attributes.






  reply	other threads:[~1998-07-09  0:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-08  0:00 Parsing a line into strings C N
1998-07-08  0:00 ` Samuel Tardieu
1998-07-08  0:00   ` C N
1998-07-09  0:00     ` Dmitriy Anisimkov
1998-07-08  0:00       ` Brian Rogoff
1998-07-08  0:00         ` Robert Dewar
1998-07-09  0:00           ` Brian Rogoff
1998-07-08  0:00         ` nabbasi
1998-07-09  0:00           ` Robert Dewar [this message]
1998-07-09  0:00             ` Michael F Brenner
1998-07-14  0:00             ` Norman H. Cohen
1998-07-15  0:00               ` Robert I. Eachus
1998-07-18  0:00                 ` Robert Dewar
1998-07-09  0:00 ` dennison
1998-07-09  0:00 ` Darren Davenport
1998-07-10  0:00   ` Robert I. Eachus
1998-07-09  0:00 ` Dale Stanbrough
1998-07-11  0:00 ` david.c.hoos.sr
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox