Module Concept For C++
MJ
Any comments are welcome!
Modules in C++:
For a new module concept I suggest to enhance the current namespaces
by a mechanism that eliminates the need to include header files (*).
The compiler shall be enabled to find the required source files and,
in order to speed up the compilation process, a recompilation shall
only be triggerd for those parts where something relevant has changed.
The basic idea to make this work, consists of associating source files
'bi-uniquely' with namespaces. In other words, a certain source file
shall always belong to a certain namespace and vice versa.
To integrate the concept into C++ I suggest to introduce a new file
type, called 'module file' here. A module file could for example have
the file extension '.module'. The file shall be associated with a
namespace which I will call 'module namespace'.
Unlike a usual namespace, a module namespace shall have an interface
part, and an implementation part. Furthermore module namespaces shall
not be open ('expandable').
Importing from a module:
An 'import' from a module is supposed to work as follows: Once the
parser encounters a reference to a module namespace, it will try to
make use of previously compiled, cached data of the interface of that
module - if this is not possible, a compilation of the module
interface will be triggered.
Examples for importing from a module:
The files a, b and c in the following examples could be cpp-files (*)
as well as modules.
a) --- file_a: ---
using namespace Graphics;
b) --- file_b: ---
void b()
{
using Graphics::f;
...
}
c) --- file_c: ---
void c()
{
...
int a = Graphics::f();
}
In either case in the above files, the first appearance of the name
'Graphics' would cause the compiler to (re-)compile the interface of
the graphics module if necessary.
Note that there is no need to write '#include ...'!
Exporting a module:
I suggest the following notation for declaring the module namespace of
a module file:
export namespace QUALIFIED-NAME;
A module namespace shall have an interface part, which can optionally
be followed by an implementation part. The interface part is supposed
to function more or less like a header file (*), whereas the
implementation part contains things that can be usually found in a
cpp-file (*).
The interface part shall start immediately after the namespace
declaration, optionally with a leading 'public:'. The implementation
part shall start with 'private:'.
Examples:
a) --- file 'graphics.module': ---
export namespace Graphics;
public: // optional line
int f();
...
private:
int f()
{
...
}
b) --- file 'collection.module': ---
export namespace Utilities::Collection;
struct s {
int i;
};
...
The prefix 'Utilities::' in the last example is meant to nest the
module namespace 'Collection' into the (usual) namespace 'Utilities'.
Integration of the standard library into the concept:
Each library file shall go to a module, e.g.
--- vector.module: ---
export namespace std::vector;
...
so that instead of ...
--- filex.cpp: ---
#include <vector>
...
using namespace std;
... a call to the library would rather look like:
--- filex.cpp: ---
using namespace std::vector;
For compatibility, a header file <vector> could be provided which
contains the line ...
namespace std { using namespace vector; }
... so that units that already use '#include <vector>' wouldn't have
to be rewritten.
Some benefits of modules:
- accelerated compilation
- no macro leakage (because no #include)
- no need to write include guards
- program design simplified, as not dependent on inclusion order
- improved platform independence because filenames and paths incl.
directory separators do not appear
All can be achieved while keeping backward-compatibility. No
additional keyword is needed.
// - - - - - - - - //
Modified source files:
After a source file has been changed, the dependent units have to be
recompiled. The criterion for a change is usually the
last-changed-time of the source file, but sometimes only whitespace
has been changed or a comment has been added.
I suggest to use a better has-changed-criterion, for example by
comparing the modified with the previous version of a source file,
both in a form where comments have been removed (replaced with
whitespace) and whitespaces contracted. This shall be done
independently for interface and implementation part.
Code exposure:
For preventing code exposure, the module file shall be splittable into
two files (details not described here), so that the code in the
implementation part would not have to be delivered to a customer.
Templates:
It has been pointed out (**), that it is expensive to support a
separation model for templates, and that there is only a marginal, if
any, advantage for the compilation speed.
This is not to present a solution for that. But may be we should draw
the consequences and decide that within modules, only an equivalent
for an inclusion model is supported.
In that case I suggest to separate the module interface into two
sections: A 'public section', optionally followed by a 'protected
section' (leaded with 'protected:'), where the protected section would
have to carry the bodies of template declarations. If so, then bodies
of inline functions should also have to go to that section.
So there would be at least a 'light weight separation model', which
might be a help for organizing the code.
Constraints for module sections:
public: declarations, constants
protected: bodies of templates and inline functions
private: definitions and private declarations, etc.
// - - - - - - - - //
(*) file, header file, cpp-file:
Some platforms don't have files. Nevertheless I am using the word
'file' here, meaning to stand for the general term.
I am using the term 'cpp-file' instead of 'translation-unit' in this
text.
(I am actually not sure about the official terminology, but I was told
'cpp-file' is usually referred to as 'translation-unit'. Someone who
knows better, please tell me!).
(**) See article "Why We Can't Afford Export":
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
--
Michael
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Daveed Vandevoorde
> I would like to present a module concept for C++.
I'm all for true modules in C++, but we'll have to
agree on what that actually means. What you propose
is not actually a module concept in my mind.
For me, a key concept for a module is that it
enforces a strict "one definition rule": _Every_
entity is defined in at most one module. That
includes not only variables, non-inline functions,
and exported templates, but also types and inline
functions.
Without that requirement, the concept of "loading
a cached translation unit" is a tricky endeavour
(not impossible, but _much_ harder and somewhat less
efficient). Unfortunately, a strict ODR means that
you e.g. cannot #include any standard header in two
different modules: In effect, the standard library
would need a "modularizing layer" so you can use it
from modules. That by itself is a challenging task.
(And the same applies to third-party headers.)
I do agree with you that a module definition should
be "closed" (like a class, but unlike a namespace).
Yet I also think it should be able to span multiple
translation units.
>From a practical perspective, you cannot specify this
sort of thing in terms of source files; much less,
file naming conventions.
[...]
> Templates:
>
> It has been pointed out (**), that it is expensive to support a
> separation model for templates, and that there is only a marginal, if
> any, advantage for the compilation speed.
[...]
> (**) See article "Why We Can't Afford Export":
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
That article was thoroughly debunked at the last
committee meeting, IMO.
Daveed
faisal vali
Daveed Vandevoorde wrote:
>
<snip>
> [...]
> > (**) See article "Why We Can't Afford Export":
> > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
>
> That article was thoroughly debunked at the last
> committee meeting, IMO.
>
Can someone please tell us what the arguments were that led to its
debunking?
thanks,
Faisal Vali
Francis Glassborow
<fv...@eecs.ku.edu> writes
>Can someone please tell us what the arguments were that led to its
>debunking?
I would much rather not (not least because I do not think the exist)
Many would agree with the proposition that we should not have introduced
export in the first place, and that having done so implementing it has
revealed some surprises. However the large majority decided they did not
want to consider its removal any further.
That sort of leaves us in a position that there is very little point in
further discussion. You have it for good or evil and must learn to live
with it.
We want to spend our time on other things.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
faisal vali
Francis Glassborow wrote:
>
> In article <3EBD6D34...@eecs.ku.edu>, faisal vali
> <fv...@eecs.ku.edu> writes
> >Can someone please tell us what the arguments were that led to its
> >debunking?
>
> I would much rather not (not least because I do not think the exist)
> Many would agree with the proposition that we should not have introduced
> export in the first place, and that having done so implementing it has
> revealed some surprises. However the large majority decided they did not
> want to consider its removal any further.
>
> That sort of leaves us in a position that there is very little point in
> further discussion. You have it for good or evil and must learn to live
> with it.
>
> We want to spend our time on other things.
>
As expressed above, the committee's conclusion actually seems quite
constructive and appropriate for now - and i agree (from skimming
through the pre/post-meeting mailings) that there are far more important
issues that deserve the committee's time.
thanks for your response,
Faisal Vali
Hyman Rosen
> I do agree with you that a module definition should
> be "closed" (like a class, but unlike a namespace).
> Yet I also think it should be able to span multiple
> translation units.
Ada has a good model here (as usual). One thing to do
is to separate the language concept of module from the
concept of source file. In Ada, you have a package
specification which describes the contents of the
module, and a package body which contains the
implementation, including types needed only by the
implementation and not the interface. You can designate
functions in the implementation as 'is separate' to
indicate that they are defined elsewhere, but even
without that, Ada doesn't define any particular binding
of packages to source files, leaving that up to the
compiler implementation. Ada merely specifies a set of
compilation order dependencies so that you cannot get
a program built with out-of-date compiled pieces.
It also has the concept of 'child packages' which allow
for extensions without having to change parents.
In Ada, you don't '#include "file"'. Instead, you 'with module;'.
This makes the public names of 'module' available for use as
qualified names; a 'use module;' makes the names available for
unqualified use.
Edward Diener
===================================== MODERATOR'S COMMENT:
I know that isn't what Francis meant, but...
===================================== END OF MODERATOR'S COMMENT
Francis Glassborow wrote:
> In article <3EBD6D34...@eecs.ku.edu>, faisal vali
> <fv...@eecs.ku.edu> writes
>> Can someone please tell us what the arguments were that led to its
>> debunking?
>
> I would much rather not (not least because I do not think the exist)
> Many would agree with the proposition that we should not have
> introduced export in the first place, and that having done so
> implementing it has revealed some surprises. However the large
> majority decided they did not want to consider its removal any
> further.
>
> That sort of leaves us in a position that there is very little point
> in further discussion. You have it for good or evil and must learn to
> live with it.
>
> We want to spend our time on other things.
This is a very arrogant reply. I am not referring to "export" in particular,
whose idea I am highly in favor of myself in a better form, but just the
attitude that "us", meaning the C++ Standards Committee, is not answerable
to others but can just say that this is how things are and "we" don't have
to explain anything to others.
I am very disappointed in your attitude and, in general, of the attitude of
other members of the committee, who do not feel that they have to have an
intelligent discussion of C++ issues with anyone outside the committee when
it serves their purpose. This general attitude is inexcusable in any
intellectual area of human endeavor, and would be laughable in any serious
scientific and artistic community in the world. I am sorry to see that the
C++ committee is presenting in any ways this sort of intellectual snobbery
to C++ programmers.
Daveed Vandevoorde
> Daveed Vandevoorde wrote:
> >
> <snip>
>
> > [...]
> > > (**) See article "Why We Can't Afford Export":
> > > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
> >
> > That article was thoroughly debunked at the last
> > committee meeting, IMO.
> >
>
> Can someone please tell us what the arguments were that led to its
> debunking?
Many arguments were made. I can only share some of my own.
Paper's claim:
Lack of demand. No value.
My counterclaim:
There is a very wide demand for hidden template source and
faster build times. Exported templates can help achieve
that (an implementation doesn't have to meet those demanded
features, but with export it can provide the feature with
an a user model that is pleasant, IMO).
Note that one of the most common C++ FAQs is about "link
time" errors due to programmers just assuming that they
can separate definitions into dot-C files. With export,
they can.
Paper's claim:
Difficult to use correctly.
My counterclaim:
It's as easy to use as "put export in front of your
exported template declarations, and place the definition
in a dot-C file." In normal code, I have not run into
surprises. (In code used to test the implementation, I
have seen the hairiest things, but that's true about about
any feature.)
The "surprising examples" that were presented in Oxford,
were unconvincing: They were unrealistic, and after some
examination, the outcome was not surprising at all.
Paper's claim:
Too Expensive to implement.
My counterclaim:
I agree to some extent: It is _really_ hard to implement.
But if the smallest group of implementers could do it,
I suspect the larger companies/groups can too.
There were other arguments (some of which were not based
on this paper), but the above are enough IMO to invalidate
the conclusion of that paper.
Daveed
Dietmar Kuehl
> Francis Glassborow wrote:
> > In article <3EBD6D34...@eecs.ku.edu>, faisal vali
> > <fv...@eecs.ku.edu> writes
> >> Can someone please tell us what the arguments were that led to its
> >> debunking?
> >
> > I would much rather not (not least because I do not think the exist)
> > Many would agree with the proposition that we should not have
> > introduced export in the first place, and that having done so
> > implementing it has revealed some surprises. However the large
> > majority decided they did not want to consider its removal any
> > further.
> >
> > That sort of leaves us in a position that there is very little point
> > in further discussion. You have it for good or evil and must learn to
> > live with it.
> >
> > We want to spend our time on other things.
>
> This is a very arrogant reply. I am not referring to "export" in particular,
> whose idea I am highly in favor of myself in a better form, but just the
> attitude that "us", meaning the C++ Standards Committee, is not answerable
> to others but can just say that this is how things are and "we" don't have
> to explain anything to others.
Well, there was a vote on whether the committee wants to spent more time (at
this meeting) on the issue of export removal. A majority of people simply
didn't want to discuss this issue any further. There were something like 50
people in the room each having a vote and I think there were at least 30
people voting against the discussion (the exact numbers as well as the exact
words we voted on should be available publically in the minutes). The reasons
for each individual vote are very likely just individual and don't necessarily
apply to more than one person. However, since the arguments in favour and
against removal were obviously unconvincing to the respective other side it
was effectively this vote which put an end to the discussion (for now; I guess
this discussion will come up at the next meeting(s), probably until at least
one other implementation support export), not any arguments.
I don't think that anyone in the committee has the attitude you are
describing: in general, you will get explanation on all official descisions.
The export removal discussion has no official descision (well, formally it
even can't be descided that this discussion is closed as long as export stays
in the language at which point the export introduction discussion can be
opened...). Obviously, the arguments in favour or against removal of export
are not agreed upon and Daveed actually quite obviously stated that in his
opinion the article is debunked. Since there is no committee descision on
this issue apart from not discussing it at the last meeting any further what
do expect?
Here is my personal view (note: this is *my* *personal*, *NOT* the view
of the committee) of the discussion: most "technical" arguments turned out to
fall into one of the following categories (I don't have details minutes of
the discussion and I'm just trying to remember what was discusseed):
- Statements made about an incomplete and immature implementation were
misunderstood as being universally true for all possible implementation.
Apparently, these misunderstandings are due to both sides: at the one hand
statements out of frustration were unnecessary pessimistic while on the
other hand opinions were taken as facts.
- Examples about weird corner-cases presented as "look what you can do if you
carefully construct an example" were turned into "look what you will stumble
into if you are not extremely careful".
- The reported effort involved in implementing export was misinterpreted.
Essentially, the only remaining argument in favour of export removal was a
non-technical one: compiler vendors don't want to implement it because nobody
asks for this featurs while it costs money to implement it (ie. it is no
marketing advantage for a compiler to support export). This means that their
compiler stays non-conforming due to an undesired feature. There is no good in
a "standard" feature which is only available in one implementation and we are
better off removing it.
Taken together this *is* debunking, IMO.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
Ken Hagan
>
> This is a very arrogant reply. ... the attitude that "us", meaning
> the C++ Standards Committee, is not answerable to others but can
> just say that this is how things are and "we" don't have to explain
> anything to others.
That wasn't my reading at all. Francis' reply *is* an explanation
of the committee's reasoning. If that reasoning starts from "how
things are" at present, then I'm neither surprised nor disappointed.
He also begins by suggesting that many on the committee now feel
they goofed up with export and have learned from experience.
Edward Diener
> fv...@eecs.ku.edu (faisal vali) wrote:
>> Daveed Vandevoorde wrote:
>>>
>> <snip>
>>
>>> [...]
>>>> (**) See article "Why We Can't Afford Export":
>>>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
>>>
>>> That article was thoroughly debunked at the last
>>> committee meeting, IMO.
>>>
>>
>> Can someone please tell us what the arguments were that led to its
>> debunking?
>
> Many arguments were made. I can only share some of my own.
>
> Paper's claim:
> Lack of demand. No value.
>
> My counterclaim:
> There is a very wide demand for hidden template source and
> faster build times. Exported templates can help achieve
> that (an implementation doesn't have to meet those demanded
> features, but with export it can provide the feature with
> an a user model that is pleasant, IMO).
I agree with you. I see a great need for those implementing templates to not
have to allow the source code of their templates be known to the end-user.
It is the same argument that can be made for those who do not want to
distribute source but just the necessary headers/libraries in order to use
an implementation. This is currently possible with non-template code but is
not with template code unless a compiler vendor implements "export" and
allows the source code for the templates to be distributed in some sort of
obfuscated form which the particular compiler can handle during compile/link
time. If that were done, "export" would be highly useful for library
distributors.
I know that I, when I am a library vendor, am extremely reticent to use
templates in my code because I must then distribute source. If "export"
could be changed so that not only the header and source can be separated, as
it now exists, but also so that the source is "compiled" down into some
intermediate, obfuscated form, ala OBJs and LIBs for normal non-template
code, then "export" would have a great deal of use. I am sure this view has
been reflected by other committee members at one time or another, but if it
has not, please make it known. I would guess that the committee doesn't want
to tell compiler vendors exactly how to implement "export", and I can
understand that, but without a system whereby the source can be hidden, I
believe that many others will be reticent to use templates who distribute
libraries.
>
> Note that one of the most common C++ FAQs is about "link
> time" errors due to programmers just assuming that they
> can separate definitions into dot-C files. With export,
> they can.
>
> Paper's claim:
> Too Expensive to implement.
>
> My counterclaim:
> I agree to some extent: It is _really_ hard to implement.
> But if the smallest group of implementers could do it,
> I suspect the larger companies/groups can too.
Again I agree. It's not the expense that has proved high but the difficulty
of implementation. But even this seems to be because so few have tried. Once
compiler vendors provide "export", it will be little different from vendors
using header and source files.
>
>
> There were other arguments (some of which were not based
> on this paper), but the above are enough IMO to invalidate
> the conclusion of that paper.
Thanks for the brief rundown on the discussion.
Edward Diener
I believe "export" should be discussed by the commitee, but not as a means
of removing it. I see "export" really becoming useful if it is given more
power to be not only a means of separating templates into declarations and
definitions but also as a means of distributing the definitions ( source )
in some form which hides the template source from the end-user. Currently
this is possible with non-template code because source is distributed in the
form of libraries and/or object files. It is not possible with template code
unless "export" is implemented and the source file can be distributed in
some "compiled" form which the end-user can't understand.
I understand that the committee does not want to tell compiler vendors how
they must deal with template definitions. I do know, however, that as a
library developer, I am really reticent in distributing libraries which
contain template code because of the previously cited issue. I don't think I
am the only developer who feels strongly this way, and I like the idea of
templates very much.
Kudos to the C++ committee, OSs, or compiler vendors who can come up with a
way by which the template definitions can be part of libraries or object
files while only the template declarations are seen by the end-user. I know
it is a very difficult problem of how this might be done, but I would really
like to see the C++ commitee bend their efforts to find such a solution. It
is easy to say that there are better things on which to concentrate, but I
believe such a solution, when found, will be vital to C++ and the creative
use of template in C++ programming in the future.
MJ
> c14159...@hotmail.com (MJ) wrote:
> > I would like to present a module concept for C++.
>
> I'm all for true modules in C++, but we'll have to
> agree on what that actually means.
Right. I thought it would be better to introduce
some concrete ideas and think it through to a certain
extent, rather than just demanding modules and leave
the rest to the committee. But that doesn't mean
that I believe there is only one way to do it.
Perhaps we should start to collect ideas for what
we expect from modules. The most important reason
why I would like to have modules are the long
compile times.
My impression is that so many people want to
have modules in C++ that it would be worth making
it an issue for the next standard. So far I
couldn't find any documents about it in the WG21
domain. Is there any discussion going on about
modules in the committee?
> What you propose is not actually a module concept
> in my mind.
>
> For me, a key concept for a module is that it
> enforces a strict "one definition rule": _Every_
> entity is defined in at most one module. That
> includes not only variables, non-inline functions,
> and exported templates, but also types and inline
> functions.
>
> Without that requirement, the concept of "loading
> a cached translation unit" is a tricky endeavour
> (not impossible, but _much_ harder and somewhat less
> efficient). Unfortunately, a strict ODR means that
> you e.g. cannot #include any standard header in two
> different modules: In effect, the standard library
> would need a "modularizing layer" so you can use it
> from modules. That by itself is a challenging task.
> (And the same applies to third-party headers.)
Don't worry about that. I am sure someone from the
Edison Design Group will be able to implement it. ;-)
But seriously, if the result is a cleaner design of
the language, which opens ways for an easier
implementation then I am in favor of it.
I think when you implemented export you had to fight
against a number of ODR related problems. So may be
an improved (i.e. easier to implement) separation model
should only be discussed together with a module concept.
> I do agree with you that a module definition should
> be "closed" (like a class, but unlike a namespace).
> Yet I also think it should be able to span multiple
> translation units.
I thought it would be much easier to resolve dependencies
if there were only one file per module. (My major concern
are the compile times.)
> From a practical perspective, you cannot specify this
> sort of thing in terms of source files; much less,
> file naming conventions.
Where exactly would you see difficulties? Could you go
more into detail here?
Michael
Dietmar Kuehl
> I believe "export" should be discussed by the commitee, but not as a means
> of removing it. I see "export" really becoming useful if it is given more
> power to be not only a means of separating templates into declarations and
> definitions but also as a means of distributing the definitions ( source )
> in some form which hides the template source from the end-user.
There is no need to discuss this stuff in the committee: this was discussed
when export was added to C++ (around 1996). The current discussion is just
there to remove export from the standard because some implementers don't
see the benefits and just the costs. Since there are apparently no user
requests for the feature and its benefits they don't see any value in
implementing this feature.
Personally, I don't think that hiding sources is that important, BTW. Maybe
it is because my ideas are crap but my experience is that no other
implementer wants to use my ideas or even my code in their library: I
discussed several of the approaches I used to implement my IOStreams and
locales library with other implementers of the standard library. I'm very
willing to explain everything in detail because my goal is eventually
getting a good implementation of the standard C++ library and I don't really
care whether I have implemented that one myself (to be honest, I would prefer
if someone else would do the work :-) Actually, where I have seen the code
of people which try to protect them I got the impression that the worst and
most useless code is protected best. As a consequence, I get suspicious if
someone tries to protect his code: either the person is essentially incapable
of writing reasonable code or deliberately does not follow good engineering
principles. ... and in neither case I would want to use such a library! I can
see that some people want to protect their intellectual property but even if
exported templates allow shipping of libraries without sources, it will be
possible to reverse engineer them like eg. Java code can be reverse
engineered. The difference would effectively be that comments are stripped and
useful names are reduced.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
---
Sergey P. Derevyago
> > Can someone please tell us what the arguments were that led to its
> > debunking?
>
> Many arguments were made. I can only share some of my own.
>
> Paper's claim:
> Lack of demand. No value.
>
> Difficult to use correctly.
>
> Too Expensive to implement.
>
Paper's claim:
Export is underspecified.
-----------------------------------8<-----------------------------------
Because export is underspecified in these and other issues not addressed in
the standard, EDG had to make decisions on questions with unspecified answers.
There is a real danger that if there are ever more implementations they will
not be perfectly compatible with EDG’s and each other’s semantics.
-----------------------------------8<-----------------------------------
I.e. the future implementations of export will be standard but mutually
incompatible. Do we need such a standard feature?
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Gabriel Dos Reis
[...]
| I.e. the future implementations of export will be standard but mutually
| incompatible. Do we need such a standard feature?
name lookup (not considering export) is underspecified. Do you think
we need such a standard feature?
--
Gabriel Dos Reis, g...@integrable-solutions.net
Jean-Marc Bourguet
> -----------------------------------8<-----------------------------------
> Because export is underspecified in these and other issues not
> addressed in the standard, EDG had to make decisions on questions
> with unspecified answers. There is a real danger that if there are
> ever more implementations they will not be perfectly compatible with
> EDG’s and each other’s semantics.
> -----------------------------------8<-----------------------------------
>
> I.e. the future implementations of export will be standard but
> mutually incompatible. Do we need such a standard feature?
Is export especially more underspecified than the whole template
chapter?
--
Jean-Marc
Sergey P. Derevyago
> | I.e. the future implementations of export will be standard but mutually
> | incompatible. Do we need such a standard feature?
> name lookup (not considering export) is underspecified. Do you think
> we need such a standard feature?
"We have no way. Even such a standard is better than nothing".
Yes, strictly speaking, name lookup (and many other things), are
underspecified. However,
1. We have several NL implementations. Realworld programs can't be written
without NL.
2. There is only one implementation of export. And export is an optional
feature (in particular the standard library is not required to use export,
neither it uses).
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Gabriel Dos Reis
[...]
| 2. There is only one implementation of export.
There are different compilers BASED on one implementation of export,
just like sometime ago there were many STLish libraries BASED on one
implementation of the STL.
| And export is an optional
| feature (in particular the standard library is not required to use export,
| neither it uses).
And inline is an optional feature (in particular the standard library is
not required to use inline, neither it uses). Do you propose to
remove inline?
Now back to the reality check: there are implementations of the
standard library using export for export-capable compilers.
--
Gabriel Dos Reis, g...@integrable-solutions.net
---
Sergey P. Derevyago
> | 2. There is only one implementation of export.
> There are different compilers BASED on one implementation of export,
> just like sometime ago there were many STLish libraries BASED on one
> implementation of the STL.
You said: There are different compilers BASED on one implementation of
export.
As one can see, it's neither a proof nor a disproof.
> | And export is an optional
> | feature (in particular the standard library is not required to use export,
> | neither it uses).
> And inline is an optional feature (in particular the standard library is
> not required to use inline, neither it uses). Do you propose to
> remove inline?
It's neither a proof nor a disproof, just like as above.
> Now back to the reality check: there are implementations of the
> standard library using export for export-capable compilers.
See above :)
My points are:
1. The paper's claim that "export is underspecified" was missed.
2. Export can be removed from the standard without (relatively) big troubles.
And the removal will also take off certain number of "underspecifications".
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
P.J. Plauger
news:3EC349FB...@iobox.com...
> > Now back to the reality check: there are implementations of the
> > standard library using export for export-capable compilers.
> See above :)
>
> My points are:
> 1. The paper's claim that "export is underspecified" was missed.
> 2. Export can be removed from the standard without (relatively) big troubles.
> And the removal will also take off certain number of "underspecifications".
The removal of export was discussed at length at the last C++ standards
meeting in Oxford. At the end, there was strong support for leaving
export in the language. It's not likely to be removed at this point, so
any underspecifications should be repaired.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Sergey P. Derevyago
> > My points are:
> > 1. The paper's claim that "export is underspecified" was missed.
> > 2. Export can be removed from the standard without (relatively) big troubles.
> > And the removal will also take off certain number of "underspecifications".
> The removal of export was discussed at length at the last C++ standards
> meeting in Oxford. At the end, there was strong support for leaving
> export in the language. It's not likely to be removed at this point, so
> any underspecifications should be repaired.
But the point is whether the thing can _really_ be repaired or we'd better
get a new one.
Daveed Vandevoorde
[...]
> IMHO at least one important claim wasn't mentioned:
I just went through some of the headings, which caused
me to miss this.
> Paper's claim:
> Export is underspecified.
> -----------------------------------8<-----------------------------------
> Because export is underspecified in these and other issues not addressed
> in
> the standard, EDG had to make decisions on questions with unspecified ans
> wers.
> There is a real danger that if there are ever more implementations they w
> ill
> not be perfectly compatible with EDG s and each other s semantics.
> -----------------------------------8<-----------------------------------
>
> I.e. the future implementations of export will be standard but mutually
> incompatible. Do we need such a standard feature?
That claim is at best "a serious exageration."
Note for example, that of the three bullets preceding
your quote, only the third is one concerns
underspecification (the others are not about specification
but about implementation, for which no standard is needed).
So the "these" should be "this" and I'm interested in what
was implied bu "and other issues."
As to the third bullet's "underspecification," it concerns
a rather unusual situation, which I'd be surprised to see
come up as an issue with real code and real compilers.
Now, every feature that was put in the standard before it
was implemented turned out eventually to be underspecified.
The first implementer usually brings up the significant
missing issues and they get handled as needed.
In fact, I was rather surprised at the small number of such
issues EDG ran into. For example, I remember many more
specification problems with explicit template argument lists
for function templates (which is comparatively a much
simpler feature).
Daveed
Daveed Vandevoorde
[...]
> Yes, the repairing is the best possible answer.
> But the point is whether the thing can _really_ be repaired or we'd better
> get a new one.
What exactly do you think is underspecified to the
point it needs to be repaired?
As I mention in another post, I believe "export"
is relatively tightly specified and needs little
or no additional "repair." (Some issues were
already addresses as a result of EDG reporting
them.)
The fact that the paper under discussion claims
"underspecification" doesn't automatically make
the claim true.
Daveed
Sergey P. Derevyago
> > Yes, the repairing is the best possible answer.
> > But the point is whether the thing can _really_ be repaired or we'd better
> > get a new one.
> What exactly do you think is underspecified to the
> point it needs to be repaired?
In fact, the "Herb Sutter" brand :) made me fill that there are certain
number of significant underspecifications. But I'm not a native English
speaker so I could get wrong what Herb has really said.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > | 2. There is only one implementation of export.
| > There are different compilers BASED on one implementation of export,
| > just like sometime ago there were many STLish libraries BASED on one
| > implementation of the STL.
| I said: There is only one implementation of export.
| You said: There are different compilers BASED on one implementation of
| export.
| As one can see, it's neither a proof nor a disproof.
Proof or disproof of what exactly?
| > | And export is an optional
| > | feature (in particular the standard library is not required to use export,
| > | neither it uses).
| > And inline is an optional feature (in particular the standard library is
| > not required to use inline, neither it uses). Do you propose to
| > remove inline?
| It's neither a proof nor a disproof, just like as above.
of what?
| > Now back to the reality check: there are implementations of the
| > standard library using export for export-capable compilers.
| See above :)
|
| My points are:
| 1. The paper's claim that "export is underspecified" was missed.
No, it was not missed. Which is why I gave you the name lookup example.
| 2. Export can be removed from the standard without (relatively) big troubles.
| And the removal will also take off certain number of "underspecifications".
If you think that export is underspecified, then removal is not the
best solution. At least, that was the committee position at last meeting.
--
Gabriel Dos Reis, g...@integrable-solutions.net
---
Gabriel Dos Reis
| Daveed Vandevoorde wrote:
| > > Yes, the repairing is the best possible answer.
| > > But the point is whether the thing can _really_ be repaired or we'd better
| > > get a new one.
| > What exactly do you think is underspecified to the
| > point it needs to be repaired?
| I'd like to hear about this from the author.
Hmm, are you saying you can't tell us what you think would be
underspecified about export?
--
Gabriel Dos Reis, g...@integrable-solutions.net
---
James Kanze
|> Daveed Vandevoorde wrote:
|> > > Yes, the repairing is the best possible answer.
|> > > But the point is whether the thing can _really_ be
|> > > repaired or we'd better get a new one.
|> > What exactly do you think is underspecified to the
|> > point it needs to be repaired?
|> I'd like to hear about this from the author.
Well, you can actually read the paper.
The thing that struck me most about it was that all of the claims were
what I believe in Anglo-Saxon countries is considered heresay
evidence. Herb is repeating things that he thinks people said, adding
only his own interpretation. And from what I know about Anglo-Saxon
jurisdiction, heresay evidence isn't admitted. Probably because of a
phenomena known in French as the "arabic telephone". When A repeats
what B said, the message is distorted. I know that Herb's
characterization of my position and expectations regarding export, for
example, was distorted. From what Daveed has said, I conclude that
this is also the case for his position (which played a much larger
role in the argument).
Knowing Herb, I'm pretty sure that this isn't a case of concious
misrepresentation on his part. But it IS a reality of hearsay
evidence, and it is doubtlessly the reason why courts don't allow it.
|> In fact, the "Herb Sutter" brand :) made me fill that there
|> are certain number of significant underspecifications. But I'm not
|> a native English speaker so I could get wrong what Herb has really
|> said.
What Herb basically said is that he had heard a lot of negative things
from a lot of different people. He claimed no actual experience with
export, nor any experience implementing it. The only real value in
the paper is in indicating who we might as -- the people Herb cites.
Since most of them have now come out as being against removing export,
I'd say that the issue was closed.
--
James Kanze mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
Gabriel Dos Reis
[...]
| Now, every feature that was put in the standard before it
| was implemented turned out eventually to be underspecified.
Exactly! And if we were to remove features from C++ because their
first specifications were labbelled "underspecified", with no further
technical justifications, we would not have C++.
--
Gabriel Dos Reis, g...@integrable-solutions.net
---
Gabriel Dos Reis
| "P.J. Plauger" wrote:
| > > My points are:
| > > 1. The paper's claim that "export is underspecified" was missed.
| > > 2. Export can be removed from the standard without (relatively) big troubles.
| > > And the removal will also take off certain number of "underspecifications".
| > The removal of export was discussed at length at the last C++ standards
| > meeting in Oxford. At the end, there was strong support for leaving
| > export in the language. It's not likely to be removed at this point, so
| > any underspecifications should be repaired.
| Yes, the repairing is the best possible answer.
| But the point is whether the thing can _really_ be repaired or we'd better
| get a new one.
Exactly what about export would you like to repair? Please be specific.
What would the "better new one" look like?
--
Gabriel Dos Reis, g...@integrable-solutions.net
---
Sergey P. Derevyago
> > I.e. the future implementations of export will be standard but mutually
> > incompatible. Do we need such a standard feature?
> That claim is at best "a serious exageration."
facts rather than opinions :).
---
Sergey P. Derevyago
> | > > Yes, the repairing is the best possible answer.
> | > > But the point is whether the thing can _really_ be repaired or we'd better
> | > > get a new one.
> | > What exactly do you think is underspecified to the
> | > point it needs to be repaired?
> | I'd like to hear about this from the author.
> Hmm, are you saying you can't tell us what you think would be
> underspecified about export?
I said that the paper, in particular, contains the following text: "Because
export is underspecified in these and other issues not addressed in the
standard, EDG had to make decisions on questions with unspecified answers.
There is a real danger that if there are ever more implementations they will
one can conclude that certain underspecifications take place.
Sergey P. Derevyago
> | > > Yes, the repairing is the best possible answer.
> | > > But the point is whether the thing can _really_ be repaired or we'd better
> | > > get a new one.
> | > What exactly do you think is underspecified to the
> | > point it needs to be repaired?
> | I'd like to hear about this from the author.
> Hmm, are you saying you can't tell us what you think would be
> underspecified about export?
underspecified.
I said that the paper, in particular, contains the following text: "Because
export is underspecified in these and other issues not addressed in the
standard, EDG had to make decisions on questions with unspecified answers.
There is a real danger that if there are ever more implementations they will
one can conclude that certain underspecifications take place.
---