compilation mechanisms (Was: Dependency Management)
in [OOP]
|
Prev: Using static factories to create two objects with bidirectional linking
Next: Using static factories to create two objects with bidirectionallinking
From: S Perryman on 29 Apr 2007 08:13 adaworks(a)sbcglobal.net wrote: > One of the things I most like about Ada is that it has > the most effective model of dependency management > of any language I have found. > Java's dependency model is awful. C++ is not much > better. Eiffel still includes everything in a single compilation > unit. Modula-2 and Modula-3 are pretty good. Modula-2 is the same as (old) Ada. All publically accessable aspects are in a "DEFINITION" module M. All implementation aspects relating to the DEFINITION module (public and not) are in the "IMPLEMENTATION" module M. If you want to define true ADTs (information hiding) , Modula-2 uses the concept of "opaque" types (a type that is named but not defined in the DEFINITION module) . These concepts are key to separate compilation. > The nice thing about Ada is the ability to move dependencies > to the exact point in a design structure where they are needed, > thereby eliminating any need to worry about the recompilation > of a module, in most cases. Also, the compiler keeps track of > all the dependencies. There is no need for all the silly #IFNDEF > absurdities one finds in C++. Even C (via affiliated tools such as make) can build dependency graphs akin to those used by Ada and Modula-2. The problem with C is #include, which is a OS file-based mechanism where the module being built is effectively a textual transitive closure of all the modules depended on (hence the much longer compile times when compared to a similarly structured system in Ada or Modula-2) . But this does not stop a C compiler from creating/holding module 'summaries' etc for build management, akin to what Ada and Modula-2 do. Perhaps some C compilers already do so (I am ignorant as to what is done by past/current C compilers) . Regards, Steven Perryman
From: adaworks on 29 Apr 2007 13:27 "S Perryman" <q(a)q.net> wrote in message news:f12261$44v$1(a)aioe.org... > > Modula-2 is the same as (old) Ada. > All publically accessable aspects are in a "DEFINITION" module M. > All implementation aspects relating to the DEFINITION module (public > and not) are in the "IMPLEMENTATION" module M. > > If you want to define true ADTs (information hiding) , Modula-2 uses the > concept of "opaque" types (a type that is named but not defined in the > DEFINITION module) . > > These concepts are key to separate compilation. > When programming in Ada, I frequently design with opaque types. However, I also design those types so they are extensible when I want to support future options for inheritance. > > Even C (via affiliated tools such as make) can build dependency graphs akin to > those used by Ada and Modula-2. The problem with C is #include, which is a OS > file-based mechanism where the module being built is effectively a > textual transitive closure of all the modules depended on (hence the much > longer compile times when compared to a similarly structured system in Ada > or Modula-2) . > The #include is, as you note, an OS issue rather than one built in to the design of the language. Ada takes this a little further than the Modula language and lets the designer push dependencies all the way down to separately compiled subprograms. At the same time, the compiler checks the consistency of those dependencies including the conformance of all the associated interfaces. For large-scale software designs, this is no small advantage. When one considers the additional capabilities for separate compilation, added to the Ada 95 version of Ada, it becomes clear that the structural (and architectural) capabilities offered in Ada are notably superior to those in most other programming languages. > > But this does not stop a C compiler from creating/holding module > 'summaries' etc for build management, akin to what Ada and Modula-2 do. > Perhaps some C compilers already do so (I am ignorant as to what is done by > past/current C compilers) . > Actually, it does not stop anyone from trying to emulate the capabilities of Ada and Modula. But such attempts are certainly feeble. Morever, they are not inherent in the C or C++ language and therefore not portable, not widely understood by users of those languages, and completely non-standard. > Ada is not perfect. Nor is Modula-2 (or Modula-3). I know these languages (especially Ada) well enough to have my own criticisms of some things in their design, but when it comes to dependency management, there is no existing language as well-designed as Ada for solving that particular problem. Richard Riehle
From: ggroups on 30 Apr 2007 08:56
On Apr 29, 6:27 pm, <adawo...(a)sbcglobal.net> wrote: "S Perryman" <q...(a)q.net> wrote in message news:f12261$44v $1(a)aioe.org... >> Even C (via affiliated tools such as make) can build dependency graphs akin to >> those used by Ada and Modula-2. The problem with C is #include, which is a OS >> file-based mechanism where the module being built is effectively a >> textual transitive closure of all the modules depended on (hence the much >> longer compile times when compared to a similarly structured system in Ada >> or Modula-2) . >The #include is, as you note, an OS issue rather than one built in to >the design of the language. It is both IMHO. The 'textual closure' that #include implies, can lead to poor compiler impls repeatedly parsing the same src modules. Not having explicit dependency declaration (Module-M.Component1, IMPORT Component1 FROM Module-M etc) means much more work for a compiler in discerning the true nature of the dependencies. >Ada takes this a little further than the Modula language and lets the >designer push dependencies all the way down to separately compiled subprograms. The same as Modula-2. >At the same time, the compiler checks the consistency of those dependencies >including the conformance of all the associated interfaces. The same as Modula-2. >> But this does not stop a C compiler from creating/holding module >> 'summaries' etc for build management, akin to what Ada and Modula-2 do. >> Perhaps some C compilers already do so (I am ignorant as to what is done by >> past/current C compilers) . >Actually, it does not stop anyone from trying to emulate the capabilities of >Ada and Modula. But such attempts are certainly feeble. Feeble is the wrong word. More appropriate IMHO is "complex" . A C compiler would have to do more work to discern the dependencies that an Ada/Modula-2 compiler sees explicitly (Module-M.Component1, IMPORT Component1 FROM Module-M etc) . But the dependencies can be discerned. >Morever, they are not inherent in the C or C++ language and therefore not >portable Build dependency management by a C compiler does not have to be portable, or standard. All this does is optimise the compilation process. It doesn't affect the generation of 'binary object' components etc. >not widely understood by users of those languages IMHO the users of C understand the problem of the very long compilation times they see (or have seen) as a result of the C model. Especially if they have used prog langs akin to Ada and Modula-2. > and completely non-standard. See above. Also, if someone has a good compiler, good for them. If the src code is built for the same target with a worse compiler, the build process may be much slower. But the end outcome is always the same (I hope :-) ) . Regards, Steven Perryman |