In article <3aq1de$d7h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:
>It's finally time to add a decent module support in C++.
>Is the new standard going to do anything with this?
>

 No. The one after might.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Andrew Fitzgibbon (andrewfg@aisb.ed.ac.uk) wrote:
: Ben Jones (jones@cais.cais.com) wrote:
: > Namespaces as currently defined could be improved further:
: > [deletia]
: > Furthermore, do away with the need for header files by letting a
: > namespace or class export its interface much the same way that Ada exports
: > the interface to "packages".

: Wonderful.

: > This scheme avoids "Make" problems by

: This is an incorrect implication.  You are allowing an opportunity for
: "advertising" to cloud your viewpoint.

: > backdating the generated interface if it does not change significantly
: > (i.e. in a way that warrants recompilation) from one compile to the next).

: Any packaging scheme neither implies nor mandates the hacked kludge that
: you propose.  "Warrants recompilation" is a per-importer concept, not
: per-exporter as your proposal implicitly assumes.  In addition, there
: are multiple levels of importers --- i.e. importers may depend on
: knowledge of the object in several ways:

In a situation involving generated interfaces, there would have to be some
way to prevent recompilations being triggered every time the exporting
module was recompiled.  Certainly you can compare the new interface with
the old and not supercede the old if there are no changes at all.
However, there are a lot of things you can do to an interface which cannot
possibly require a recompile:

* Edit comments and white space, of course.

* Add global data symbols and static members, since no previously
compiled module could have referenced them.

* Add non-static members provided that they do not change the size of a
class or change the offsets of existing non-static members.  Here, it
might be worthwhile to have a way of specifying a minumum size for
a class so that you could add new members during the development
phase.

* Add new global functions, static member functions, and non-static
non-virtual member functions.  This includes operator overloads
associated with added classes (since those classes could not have been
referenced previously).  It might also be worthwhile to have some
members and member functions be "proprietary" (accessible only in the
exporting module) so that they wouldn't show up in the interface at all.

* Add virtual member functions which do not change the offsets of
existing functions in the vtable.  In an exported header situation,
the exporting module would "own" the vtable (removing one ambiguity
from the current standard).

The Make would be set up to show dependencies on the generated interfaces,
which would be backdated if only the above changes were made from one
compilation to the next.  Without knowing anything at all about the
importing modules, this scheme would prevent enough unnecessary
recompilations to be extremely worthwhile in a development situation.

Ben Jones
ARSoftware Corporation

In article <3asorj$j3s@ztivax.zfe.siemens.de>, michi@km21.zfe.siemens.de (Michael Klug) writes:
|> In article <pjl.785421180@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
|> |> In <3aq1de$d7h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:
|> |>
|> |> >It's finally time to add a decent module support in C++.
|> |>
|> |>  Unsupported claim > /dev/null
|> |>
|> |> >Is the new standard going to do anything with this?
|> |>
|> |>  Yes: namespaces.
|>
|>         No. namespace != module
|>
|> A namespace is just a hack to avoid name clashes. It is in no way a
|> module concept. A module concept needs an interface specification
|> language construct. "Modularization" in C++ is still done by textual
|> inclusion via preprocessor using unstandardized header files with arbitray
|> contents.

   This might be a little obvious, but neither header files nor
textual inclusion via preprocessor is mandated by "C++".
Stroustroup in particular avoided tying C++ to header files and
if you read the articles from the AT&T Grail project you can see that
they were headed towards a day without header files.

   You can draw whatever conclusion you like from the fact that efforts
like Grail and Lucid Energize that try to avoid headers as a working model
have failed so far...

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

Andrew Fitzgibbon (andrewfg@aisb.ed.ac.uk) wrote:
> Ben Jones (jones@cais.cais.com) wrote:
> > backdating the generated interface if it does not change significantly
> > (i.e. in a way that warrants recompilation) from one compile to the next).

> Any packaging scheme neither implies nor mandates the hacked kludge that
> you propose.  "Warrants recompilation" is a per-importer concept, not
> per-exporter as your proposal implicitly assumes.  In addition, there
> are multiple levels of importers --- i.e. importers may depend on
> knowledge of the object in several ways>

WRT cutting down unneccessary compiling for efficiency, IMO using both
sides (importer/exporter) together is best.

One could argue that looking at the importer yields all the neccessary
information -- but that requires processing each importer, and the
entire effort can be saved if it's known that the exporter will not
require importer recompilation.

OTOH, once you've decided the exporter has changed, you still gain by
making a quick first pass over each importer to see if it needs
recompilation. (Essentially what you said)

        Tom

--
tob@world.std.com
TomBreton@delphi.com: Author of The Burning Tower

It's finally time to add a decent module support in C++.
Is the new standard going to do anything with this?

In <3aq1de$d7h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:

>It's finally time to add a decent module support in C++.

 Unsupported claim > /dev/null

>Is the new standard going to do anything with this?

 Yes: namespaces.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL

Paul J. Lucas (pjl@graceland.att.com) wrote:
: In <3aq1de$d7h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:

: >It's finally time to add a decent module support in C++.

:  Unsupported claim > /dev/null

: >Is the new standard going to do anything with this?

:  Yes: namespaces.

Namespaces as currently defined could be improved further:

If you think of a namespace as a class with all static members rather than
as a separate syntactical oddity, it would go a long way toward removing the
barrier between non-object-oriented and object-oriented programming:

    namespace name: name1, name2, ... { ... };

The base names would be other namespaces as well as classes.  Furthermore,
let a class inherit a namespace, eliminating the need for "using namespace".

If a namespace "inherits" a class, it behaves as though a static instance of
that class has its members directly accessible from within the namespace.

Furthermore, do away with the need for header files by letting a
namespace or class export its interface much the same way that Ada exports
the interface to "packages".  This scheme avoids "Make" problems by
backdating the generated interface if it does not change significantly
(i.e. in a way that warrants recompilation) from one compile to the next).

I have implemented such a scheme in an experimental preprocessor.  For more
information, please contact me:

Ben Jones
ARSoftware Corporation
jones@arsoftware.arclch.com

Ben Jones (jones@cais.cais.com) wrote:
> Namespaces as currently defined could be improved further:
> [deletia]
> Furthermore, do away with the need for header files by letting a
> namespace or class export its interface much the same way that Ada exports
> the interface to "packages".

Wonderful.

> This scheme avoids "Make" problems by

This is an incorrect implication.  You are allowing an opportunity for
"advertising" to cloud your viewpoint.

> backdating the generated interface if it does not change significantly
> (i.e. in a way that warrants recompilation) from one compile to the next).

Any packaging scheme neither implies nor mandates the hacked kludge that
you propose.  "Warrants recompilation" is a per-importer concept, not
per-exporter as your proposal implicitly assumes.  In addition, there
are multiple levels of importers --- i.e. importers may depend on
knowledge of the object in several ways:

* None.
* Opaque [void f(A *); can be defined without knowing the size of A]
* "Size".  Essentially, the object size plus the constructor interface
  sufficient to make a correctly initialized object on the stack or free
  store.
* Full -- methods will generally need access to all interfaces, both
  external and internal.

Better (and worse) solutions are possible.  The essential point is that
the compiler must help "make", and that a packaging system which does
not depend on textual inclusion can more easily provide this.

A.

--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
                        http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg
       "If it ain't broke, don't fix it" - traditional (c1950)
          "A stitch in time saves nine." - traditional (c1590)

In article <pjl.785421180@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
|> In <3aq1de$d7h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:
|>
|> >It's finally time to add a decent module support in C++.
|>
|>  Unsupported claim > /dev/null
|>
|> >Is the new standard going to do anything with this?
|>
|>  Yes: namespaces.

        No. namespace != module

A namespace is just a hack to avoid name clashes. It is in no way a
module concept. A module concept needs an interface specification
language construct. "Modularization" in C++ is still done by textual
inclusion via preprocessor using unstandardized header files with arbitray
contents.

--MiKl

Paul J. Lucas (pjl@graceland.att.com) wrote:
In <3aq1de$d7h@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:
>It's finally time to add a decent module support in C++.
  Unsupported claim > /dev/null

Really Paul!  Imagine if he'd said that the current seperate compilation
system were just perfect and that we shouldn't muck with it.  Now *that*
would be an unsupported claim :->

>Is the new standard going to do anything with this?
 Yes: namespaces.

I've not seen much discussion of namespaces, and they're not in the
11/94 FAQ.  Could someone outline the proposal please?

A.

--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
                        http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg
       "If it ain't broke, don't fix it" - traditional (c1950)
          "A stitch in time saves nine." - traditional (c1590)

If you're really serious about adding modules to C++, first look and see
how other languages such as Ada, Modula-2, and Modula-3 have done it.
There are some tricky issues involved to handle name-space collisions and
other problems.

For instance, here's just one way to manage names, lookups, and collisions
that would work for C as well as C++:

interface M1 {
   void foo();
   void f1();
}

interface M2 {
   void foo();
   void f2();
}

interface Main {
   int main();
}

module Main {
   import M1 as mod1;
   import M2;

   int M1;   // would hide module M1 if that was not renamed mod1

   int main()   // exported
   {
       foo();      // error - ambiguous M1.foo() or M2.foo()
       mod1.foo(); // OK - M1.foo()
       M2.foo();   // OK
       f2();       // OK - unambiguous M2.f2()
       return 0;
   }
}

There are a variety of other ways to deal with modules, aside from
syntax.  I also would like to point out that allowing the renaming of a
module upon import is a Real Good Idea and removes a lot of name-collision
headaches.  Modula-3 also adds generic modules, which may or may not be
appropriate for C++. Come to think of it, since everything but the kitchen
sink is now in C++ anyway, why not throw it *all* in?

Here's another idea: For every new feature added to C++, two must be removed.


        -- Parag Patel <parag@netcom.com>