What does "C++ doesn't support modules" mean?

[Steven T. Hatton]

I've seen people here write that C++ doesn't support modules. What does
that mean? 'Module' is a very nebulous term in my book. It probably means
something quite different to me than what it does to people making that
comment about C++. Can someone explain what they mean when they say C++
doesn't support modules?

 

[Ioannis Vranos]

I've seen people here write that C++ doesn't support modules. What does
that mean? 'Module' is a very nebulous term in my book. It probably means
something quite different to me than what it does to people making that
comment about C++. Can someone explain what they mean when they say C++
doesn't support modules?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

C++ supports the modular programming paradigm, which is namespaces.






Ioannis Vranos

 

[Alf P. Steinbach]

I've seen people here write that C++ doesn't support modules. What does
that mean? 'Module' is a very nebulous term in my book. It probably means
something quite different to me than what it does to people making that
comment about C++. Can someone explain what they mean when they say C++
doesn't support modules?

Probably modules as in Modula "module", Ada "package", Pascal "unit",
Java "package", Perl "package", and so on, where the language provides
some form of module import which includes linking information and
preferably also type-checking while suppressing implementation details,
and preferably also some support for module initialization & cleanup.

In C++ logical modules must, as many other things, be implemented by
convention only (using textual includes & separate compilation).

And module initialization & cleanup is not possible to ensure in the
most general case; also that must rely on convention & documentation.
To wit, the standard library's named iostreams must rely on a mechanism
that is unavailable to the C++ programmer. The main problem in solving
this unfortunate situation is to still provide backward compatibility.

 

[Derek]

Alf P. Steinbach wrote:
[...]

And module initialization & cleanup is not possible to
ensure in the most general case; also that must rely
on convention & documentation. To wit, the standard
library's named iostreams must rely on a mechanism that
is unavailable to the C++ programmer. The main problem
in solving this unfortunate situation is to still provide
backward compatibility.

I don't mean to be dense, but how would adding support for
modules compromise backward compatibility? Couldn't such a
mechanism coexist with the current model?

 

[Alf P. Steinbach]

Alf P. Steinbach wrote:
[...]

And module initialization & cleanup is not possible to
ensure in the most general case; also that must rely
on convention & documentation. To wit, the standard
library's named iostreams must rely on a mechanism that
is unavailable to the C++ programmer. The main problem
in solving this unfortunate situation is to still provide
backward compatibility.

I don't mean to be dense, but how would adding support for
modules compromise backward compatibility? Couldn't such a
mechanism coexist with the current model?

Perhaps I am the dense one... ;-)

Thanks.

I just harked up something I learned somewhere, and am unable to support the
statement (although it's always a problem that when something new is
introduced, unanticipated interaction with existing features manifests
itself). I should have qualified that statement with a "seems to be".

Consider e.g. the hypothetical code

#include <old_header>
using package acme::xml;

or

using package acme::xml;
#include <old_header>

What could the problems really be?

On reflection I don't know. E.g. it seems we can disregard C compatibility
issues, and also preprocessor symbol interaction. So I just put the question
forward here; what I think I do know is that this has been debated over and
over several times, but with no clear module alternative emerging, even after
ten or twenty years or so (whatever), which seems to indicate that there are
problems -- but for the life of me I'm unable to not see obvious solutions.

 

[Mark A. Gibbs]

Last I heard (before the C and C++ Kona meetings last year) was that
Pete Becker was proposing adding built in facilities to C++ to support
shared/dynamic libraries.

I don't think Becker's proposal mentioned startup/shutdown code for
dynamic libraries at all. It may have just mentioned global objects and
said they're good enough.

I don't think there were any real concerns about backward compatability
being a problem either - except maybe whether objects have shared
linkage by default (unix) or not (windows).

In fact, I don't remember much in the proposal that was concrete yet -
it may have just been an early draft.

As an aside, nobody mentioned object files as kind of module-like.
Personally, I think they come closer than namespaces to being modules.

mark