CVS difference for acs/ac-00016.txt

Differences between 1.1 and version 1.2
Log of other versions for file acs/ac-00016.txt

--- acs/ac-00016.txt	2001/10/17 21:24:58	1.1
+++ acs/ac-00016.txt	2001/10/19 01:36:42	1.2
@@ -51,3 +51,99 @@
 vendor! This is the sort of thing that Inline was designed to handle).
 
 ****************************************************************
+
+From: Craig Carey
+Sent: Thursday, October 18, 2001  7:23 PM
+
+At 2001.October.10 09:12 -0500 Wednesday, Santhanam, Vdot wrote:
+ >Issue:
+ >
+ >In Ada, it is awkward to create a variable in a package for read/write use
+ >internally but read-only use by clients. To achieve this, one would have to
+ >declare the variable either in the private part of the package spec or in
+ >the body, and provide a visible function to read the variable.
+ >
+ >Solution:
+ >
+ >Provide a Read_Only pragma which can be applied to variables in the visible
+
+What about "exported constant" (etc.) ?, or "pragma Export_As_Constant(...)" ?.
+'Read_Only' sounds like a description that can make the variable be constant,
+even inside of the body of the package.
+
+ >part of a package so that they are treated as constants by the clients of
+ >the package. Example:
+ >
+ >       Error_Count : Natural := 0;
+ >       pragma Read_Only (Error_Count);
+ >
+ >The read-only restriction is not applicable the declaring package itself.
+ >
+
+In GNAT there is this error message:
+
+     "error: access-to-variable designates constant";
+
+when the 'Access attribute is applied to a constant. Pointers to constants
+can't be assigned and the language does not dynamically keep track of
+whether a pointer is to a constant or to a variable.
+
+I saw a comment (not public at this list) that suggested that this could be
+a difficult thing for a compiler vendor to implement.
+
+Note that there was no mention of interfacing with another language, e.g. C.
+
+-------------------------------------------------
+
+At 2001.October.16 19:13 -0500 Tuesday, Randy Brukardt wrote:
+ >
+ >> The reader function approach incurs a significant run-time penalty.
+ >
+ >It shouldn't have any runtime penalty, if combined with a pragma Inline.
+ >Why doesn't that solve your problem without introducing any new language
+ >features?
+
+It could be bugs in the compiler that Boeing was using or a suspicion of
+them.
+
+ >          (If your vendor doesn't Inline these properly, either pressure or
+ >change the vendor! This is the sort of thing that Inline was designed to
+ >handle).
+ >
+
+
+Inlining is something that may not happen even after the compiler is told
+to inline. If it is a serious suggestion, then universities could teach
+students how to study Ada code in its assembly language form.
+
+In GNAT there are restrictions on inlining: (quoting from the user guide):
+
+        "The call appears in a body (not in a package spec).".
+
+Also the -gnatn option must be specified and so must a -O1 or -On
+optimising option.
+
+An option could be to put the many variables of the package spec, into a
+a single record and then have two of those records overlaid.
+
+One record would be constant and exported to other packages.
+The other record would be not constant, and its components could be used
+inside of the package. Some trick I can't think of at the moment is
+used to circumvent the prohibition against applying 'Access to a
+constant.
+
+That could be regarded as a proof that compiler vendors can implement the
+feature easily. But I am not sure.
+
+Another option might be to have a simple dummy package to get around the
+safety problem. Here is an example":
+
+generic
+    Pkg_Security_ID_Code : Boolean;
+package West_Coast_Consts is
+    ...
+    A69  : constant Boolean := East_Coast_Vars.A96;
+    ...   -- 555 more lines
+end West_Coast_Consts;
+
+****************************************************************

Questions? Ask the ACAA Technical Agent