Francis Glassborow wrote:
[...]
> The dynamic linking issue is very tough because the rules used by the
> two main desk-top families of OS seem incompatible. That does not mean
> we have given up, just that finding an answer is very far from trivial.

At the last meeting, the conclusion was that while the "default rules"
of Windows OSes and Unix-based OSes are incompatible, the Unix-based
OSes had apparently all evolved to also support the Windows-way of
doing things (e.g., in Unix external entities are visible across
dynamic library
boundaries by default, but programming models have been added to
require
explicit visibility attributes instead).

Incidentally, that particular topic is not independent from the Modules

proposal: Modules could be the unit mapped onto dynamic libraries.

        Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,
I'd like any news about the "Modules in C++" proposal made some time
ago by Daveed Vandevoorde. Has it been discussed? What are the chances
it will be incorporated into the Standard?

Thanks

Gianluca Silvestri

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gianluca Silvestri wrote:
> Hi,
> I'd like any news about the "Modules in C++" proposal made some time
> ago by Daveed Vandevoorde. Has it been discussed? What are the chances
> it will be incorporated into the Standard?

It was discussed peripherally at the last standardization meeting
(i.e., modules
were not discussed as a primary topic, but they were mention as a
possible
vehicle to solve other issues like dynamic libraries and ADL
pollution).  I hope
to have an updated paper ready for the next meeting.

I don't really know what its chances are.  I don't think they're zero,
but I don't
think it would be realistic to think they're very high.

        Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1139980206.075975.67010@o13g2000cwo.googlegroups.com>,
vandevoorde@gmail.com writes
>I don't really know what its chances are.  I don't think they're zero,
>but I don't
>think it would be realistic to think they're very high.

The BSI C++ panel is very supportive of the proposal but thinks it would
be more realistic to deal with it as a TR. We would be very disappointed
if it was simply dropped.

We think it has great potential but think that there are other things
such as a new memory model that are essential and must be tackled as a
priority. We think that the modules proposal has a number of effects
that need to be explored in more depth than we currently have available
for proposals for C++0x


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> The BSI C++ panel is very supportive of the proposal but thinks it would
> be more realistic to deal with it as a TR. We would be very disappointed
> if it was simply dropped.
>
> We think it has great potential but think that there are other things
> such as a new memory model that are essential and must be tackled as a
> priority. We think that the modules proposal has a number of effects
> that need to be explored in more depth than we currently have available
> for proposals for C++0x

I think the efforts so far taken for C++0x are a bit too much biased
towards templates. The risk is that useful features like Multithreading
or dynamic linking (last Pete Becker's proposal dates back in 2003) are
left aside.

What I mean is that templates are indeed one of the most useful tools
in C++ but are not really meant for an average user, who will benefit
more (for example) from a mechanism to distribute his code in separate
modules without resorting to a C-interface.

Just my humble opinion

Gianluca Silvestri

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1140083251.600639.272890@o13g2000cwo.googlegroups.com>,
Gianluca Silvestri <dishsi@tin.it> writes
>I think the efforts so far taken for C++0x are a bit too much biased
>towards templates. The risk is that useful features like Multithreading
>or dynamic linking (last Pete Becker's proposal dates back in 2003) are
>left aside.

Actually before tackling multi-threading we need to tackle the memory
model issues so that we can program safely in contexts of genuine
parallelism. However Multi-threading is considered an important issue
and is high on the list, just one that is dependant on the memory model.

The dynamic linking issue is very tough because the rules used by the
two main desk-top families of OS seem incompatible. That does not mean
we have given up, just that finding an answer is very far from trivial.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <395srp$3jd@tethys.otol.fi> tohoyn@janus.otol.fi (Tommi
H|yn{l{nmaa) writes:

|> The C++ supports grouping source code into classes. However, grouping code
|> into modules is not so well supported. It's quite odd that you have to use
|> preprocessor symbols to define modules.
|> e.g.
|>   #ifndef MODULE_H
|>   #define MODULE_H
|>   ...
|>   #endif
|> This way of implementing modules has some problems. The C++ compiler does not
|> know where the module is implemented. The compiler doesn't warn if you define
|> something in the header file and don't implement it in the source code file.
|> This error is not detected until linking. You can also implement functions
|> from different header files in the source code file and the compiler doesn't
|> say anything. Furthermore, the compiler may have to put some data (e.g.
|> inline function code and virtual tables for classes) in all object files that
|> use the header file of some module. GNU C++ has '#pragma interface' and
|> '#pragma implementation' to handle this problem. This kind of mechanism should
|> be standardized in the language.

|> Other problems are the initialization and destruction code of the module.
|> Is there currently any clean and portable way to implement them?
|> I have used the following:

|>   // source code file
|>   #include "module.h"
|>   ...
|>   class Module
|>   {
|>   public:
|>     Module();  // initialization code goes here
|>     ~Module();  // destruction code goes here
|>   };

|>   static Module module;

|>   // source code file ends
|> Is it sure that this works? Is it guaranteed that the compiler doesn't decide
|> to "optimize" the 'module' variable away because it isn't used anywhere?
|> One problem in this way is that I do not know the initialization/destruction
|> order of the modules.

|> Another odd thing in the C++ module handling is that the header files are
|> ordinary text files; they are usually not precompiled in any way.
|> Precompilation could decrease compilation time considerably especially when
|> using templates or inline functions.

|> The new C++ standard includes namespaces, which solve many problems with
|> modules. But can they include initialization/destruction code?
|> And I still have to use those funny '#ifndef''s in header files.
|> (These could be avoided if there were a different kind of include directive
|> that would automatically check that the header file is included only once.)

I use a variant of the Cheshire cat interface to simulate modules.

For those not familiar with the term, the Cheshire cat interface
refers to putting the private parts of the class in a separate
class/struct, and only having a forward declaration of this class in
the header file, thus:

 class MyClassImpl ;

 class MyClass
 {
     //  ...
 private :
     MyClassImpl* impl ;
 } ;

The constructor new's an impl, and sets the pointer.

The traditional advantage is that changes in the private parts do not
trigger recompilation of all of the users.

A `module' class is similar, except that: 1) the private pointer is
static, and 2) the constructor only initializes the pointer if its
previous value is NULL.

In all other ways, it works like a Cheshire cat class.  In particular,
the functions are *not* static (although the this pointer isn't used
for anything); this ensures that there must be a locally declared
instance of the variable in order to use it (which in term ensures
that the static object is correctly initialized).

In some ways, this is also like the nifty counter trick.  But by
shifting the onus of controling the initialization to the user (hidden
in a variable declaration), one of the major disadvantages of the
nifty counter is avoided.  If the module class instances are declared
class local or in a function, they will not cause the entire program
to be paged in on program start-up.

Note that, at least as I have implemented it, the actual
implementation class is never destructed.  This may cause problems if
some of the class members require finallization.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

The C++ supports grouping source code into classes. However, grouping code
into modules is not so well supported. It's quite odd that you have to use
preprocessor symbols to define modules.
e.g.
  #ifndef MODULE_H
  #define MODULE_H
  ...
  #endif
This way of implementing modules has some problems. The C++ compiler does not
know where the module is implemented. The compiler doesn't warn if you define
something in the header file and don't implement it in the source code file.
This error is not detected until linking. You can also implement functions
from different header files in the source code file and the compiler doesn't
say anything. Furthermore, the compiler may have to put some data (e.g.
inline function code and virtual tables for classes) in all object files that
use the header file of some module. GNU C++ has '#pragma interface' and
'#pragma implementation' to handle this problem. This kind of mechanism should
be standardized in the language.

Other problems are the initialization and destruction code of the module.
Is there currently any clean and portable way to implement them?
I have used the following:

  // source code file
  #include "module.h"
  ...
  class Module
  {
  public:
    Module();  // initialization code goes here
    ~Module();  // destruction code goes here
  };

  static Module module;

  // source code file ends
Is it sure that this works? Is it guaranteed that the compiler doesn't decide
to "optimize" the 'module' variable away because it isn't used anywhere?
One problem in this way is that I do not know the initialization/destruction
order of the modules.

Another odd thing in the C++ module handling is that the header files are
ordinary text files; they are usually not precompiled in any way.
Precompilation could decrease compilation time considerably especially when
using templates or inline functions.

The new C++ standard includes namespaces, which solve many problems with
modules. But can they include initialization/destruction code?
And I still have to use those funny '#ifndef''s in header files.
(These could be avoided if there were a different kind of include directive
that would automatically check that the header file is included only once.)

 Tommi H|yn{l{nmaa

tohoyn@janus.otol.fi (Tommi H|yn{l{nmaa) writes:

>The C++ supports grouping source code into classes. However, grouping code
>into modules is not so well supported.

Yes, you're right, it's not.

>Other problems are the initialization and destruction code of the module.
>Is there currently any clean and portable way to implement them?
>I have used the following:
>
>  // source code file
>  #include "module.h"
>  ...
>  class Module
>  {
>  public:
>    Module();  // initialization code goes here
>    ~Module();  // destruction code goes here
>  };
>
>  static Module module;
>  // source code file ends

That's about as clean and portable as it gets.

>Is it sure that this works?

Basically yes, but I guess it depends on exactly what you mean by "works".

>Is it guaranteed that the compiler doesn't decide
>to "optimize" the 'module' variable away because it isn't used anywhere?

Yes.

>One problem in this way is that I do not know the initialization/destruction
>order of the modules.

Yes, that is a problem.  See the "nifty_counter" trick on ARM pages
19-20 for an (inefficient) work-around.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au