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: 103376,1a066a8221187698 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Environment Variables Date: 1997/01/24 Message-ID: #1/1 X-Deja-AN: 212075385 references: <5c1nf9$d3q@ultranews.duc.auburn.edu> content-type: text/plain; charset=ISO-8859-1 organization: Estormza Software mime-version: 1.0 newsgroups: comp.lang.ada Date: 1997-01-24T00:00:00+00:00 List-Id: In article <5c1nf9$d3q@ultranews.duc.auburn.edu>, greerjo@mail.auburn.edu (John M. Greer) wrote: >Does anyone know how to access environment variables from Ada code? >Specifically, Unix/Linux CGI environment variables from the latest >version of GNAT. Is POSIX supported on your machine. Did your compiler come with POSIX bindings? If so, then environment variables are available via POSIX_Process_Environment. >On an unrelated note (and this is a classroom question, but it's not >doing my homework for me), my professor commented that using WITH, though >common in Ada-83, is frowned upon by the industry in Ada 95. Any >specific reason for that? (I'm assuming name collisions with types that >look similar to the compiler, but I've only been in this class for about >a month, so . . .) I'm not sure what you mean here. You *must* with other library units to use the resources they provide. (Except of course for package Standard.) When there's a name collision, Ada forces you the programmer to name the unit containing the declaration so as to resolve the ambiguity. Ada never makes a "default choice." (Though that's a bit of a lie in the case of root types.) Perhaps he was refering to the "use" clause? Yes, this is a contentious issue in the Ada community. It's been my experience, though, that the use clause it either used too often, or not enough. There are a few techniques one can use that makes its use less pernicious. Your professor may have been refering to Ada 95's "use type" clause. This obviates one reason why programmers use use, which was to gain direct visibility to the operators of the type. For example, if I have package P is type T is new Integer; end; with P; procedure Proc is O : P.T; begin O := O + 1; The compiler complains because the "+" operator for the type isn't visible. So you had a few choices. with P; use P; procedure Proc is O : T; begin O := O + 1; This is probably what your professor was refering to. If I'm in a scope with a lot of variables and a lot of with's, then suddenly I don't know where any of my types came from. A real maintenance nightmare, committed by unthoughtful programmers. Shops often ban the use of use for that reason, but it's a really naive solution to the problem. So you have horrible code like this with P; procedure Proc is O : P.T; begin O := P."+" (O, 1); Ouch! A better solution (still Ada 83), is to use a renames: with P; procedure Proc is O : P.T; function "+" (L, R : P.T) return P.T renames P."+"; begin O := O + 1; At least now, everything is documented. But if you're using a lot of operators, then renames can be a bit of a chore. I like to localize the use clause, so at least I identify where the type came from. with P; procedure Proc is O : P.T; use P; begin O := O + 1; The (primitive) operations for a type are declared in the same package as the type declaration, so if I identify the package containing the type, then I've implicitly said where the operations (and operators) came from too. In Ada 95, there's a use type clause that allows me to get direct visibility to the operators only: with P; use type P.T; procedure Proc is O : P.T; begin O := O + 1; Which seems to solve the problem to everyone's satisfaction. The rules for use are as follows. To resolve the reference to the operation, the compiler looks in successively outer scopes for an explicit operation declaration or rename, until it hits the unit containing the type declaration (where presumably the operation is primitive). The units named in a use clause are considered only *after* this has been done. Localizing a use clause only limits the scope to which the use clause applies; it doesn't give the operations in the named unit any kind of "priority" when resolving the reference. The operations of the unit named in the use clause are still considered only after not finding explicit declarations or renames, no matter how "near" it appears to the invokation of the operation. Few Ada programmers really understand the rules for use, which is partly why it's use is so controversial. Feel free to email me privately if you have any Ada questions. (Your professor can email too, if he wants the opinion of an "industry representative.") matt -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271