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,9ac62ca34a465706 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,9ac62ca34a465706 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: on OO differnces between Ada95 and C++ Date: 1996/02/24 Message-ID: #1/1 X-Deja-AN: 140974552 references: <4gbq7q$g08@qualcomm.com> <3129F185.41C6@Rational.COM> <312C5160.41C6@Rational.COM> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c++ Date: 1996-02-24T00:00:00+00:00 List-Id: Jerome said, answering me: > for Ada files, and GNAT does not require specs to be explicitly > compiled Even GNAT will perform a semantic analysis of Ada specs. Try to run a C++ compiler against a .h file! Absolutely true. I was using compiled here in the sense of creating an object file. GNAT does not create object files for: subunits generic units package specs that require a body However, it is perfectly fine, and very useful, to be able to compile all these kinds of units using the -gnatc swich that asks GNAT to fully check the syntax and semantics. It is indeed an important advantage of Ada that such checking is possible (you said "try to run a C++ compiler against a .h file", and of course a similar suggestion is "try to run a C++ compiler against a template". In Ada, the generic contract model means that a generic body that compiles clean will always instantiate clean, but that of course is not the case for C++ templates. It is true that you get some extra flexibility in return for this freedom in C++, but for the construction of large systems, the contract model is an important guarantee (so important that it is the one place in Ada 95 where an incompatible change was made to Ada 83 to fix up the one serious hole in the model, namely the business of passing unconstrained types). In a small program with GNAT, you don't need to bother to compile these non-object-producing units at all, since you will find the errors immediately from the clients, and can then fix up whatever needs fixing. But in a large program, the ability to verify specs, subunits, and generics independently is critical (and required by the RM), so there the use of the -gnatc switch is very useful. Note: if you attempt to compile any of the above units to produce object files (by omitting the -gnatc), then an error is signalled: No code generated for file xxx (package spec) or somesuch. The error message is needed (and the compiler will indicate error status) because the expected object file is not produced. Actually I think I wll change the message to No object file created for file xxx (...) since that is clearer. If you find this confusing, just follow the proper procedure, which is to use -gnatc when compiling a subunit, generic unit, or package spec. Note also that -gnatc is useful when comilling a parent unit with subunits, it checks the syntax and semantics JUST of the parent unit, without checking the subunits.