C or C++?

[Juha Nieminen]

Private fields are nice, but the fact that private fields have to be
in a public header is irksome to me.

The compiler has to know the size of the class. Do you have any
suggestions about how it can know that if the member variables for
the class are not listed?

As for private member functions, I agree. There just isn't any
technical reason for them to be mandatory in the class definition.

 

[Branimir Maksimovic]

The compiler has to know the size of the class.

Not just size of class. It has to see definition in
order to know exact memory layout.

Do you have any

suggestions about how it can know that if the member variables for
the class are not listed?

C++ class is same thing as struct. Only difference is that
in class everything is private by default and in struct public.
Definitions of class/struct have to be same across all compilation
units. But I think that I have saw in language D that different
definitions work. For example one class with same name just declares
member functions while other defines functions and adds member
variables. This can also work in C++ if implementation always
places vtable pointer first, but I guess this will severely
restrict implementations and I don;t know what will
happen when casting across multiple inheritance bases
or virtual inheritance bases.

As for private member functions, I agree. There just isn't any
technical reason for them to be mandatory in the class definition.

Well it is. What about virtual functions? Compiler can't know
vtable layout without seeing all virtual functions.

Greetings, Branimir.

 

[James Kanze]

Not just size of class. It has to see definition in
order to know exact memory layout.

You're supposing a very classical compiler/linker organization.
There's nothing to prevent a compiler from generating some sort
of abstract code, with actual code generation only taking place
at link time. Most modern compilers already do this anyway, for
optimization purposes. Most still fix things like stack layout
at compile time, but this is mainly because of historical
reasons; there's no real technical justification.

 

[Juha Nieminen]

Well it is. What about virtual functions? Compiler can't know
vtable layout without seeing all virtual functions.

I referred to non-virtual functions.

 

[Gianni Mariani]

You're supposing a very classical compiler/linker organization.
There's nothing to prevent a compiler from generating some sort
of abstract code, with actual code generation only taking place
at link time. Most modern compilers already do this anyway, for
optimization purposes. Most still fix things like stack layout
at compile time, but this is mainly because of historical
reasons; there's no real technical justification.

You're not implying being able to export templates are you ?

 

[James Kanze]

You're not implying being able to export templates are you ?

I'm not implying anything. I'm saying very bluntly and directly
that today (2007), there is no real technical reason not to
implement export. It means a bit of programming work, but the
techniques and the problems are known (thanks to the people at
EDG). That a compiler vendor could have some hesitations in
1999, I can understand; it's not always a bad policy to let
others do the hard work of finding out where the problems might
be. Today, the hard (in the sense of difficult) work has been
done. And while it obviously involves investing some resources,
EDG has made enough information about how they did it available
so that other companies should be able to plan and budget it
with a reasonable degree of assurance of not ending up
completely out of budget. And experience with the EDG
implementation has proved that it does bring the claimed
advantages.

 

[Gianni Mariani]

....

I'm not implying anything. I'm saying very bluntly and directly
that today (2007), there is no real technical reason not to
implement export.

You seem to be sitting on the fence on this one, can you tell us what
you really think ?

... It means a bit of programming work, but the
techniques and the problems are known (thanks to the people at
EDG). ...

A simple matter of programming ?

Maybe you missed the implied smiley on my previous post however, I
think there is a little more to it to do it right. I would not hold
doing it now on my account.

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting. The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation but I suspect that debugging
will need to be worked out as well. It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

 

[Branimir Maksimovic]

A simple matter of programming ?

Maybe you missed the implied smiley on my previous post however, I
think there is a little more to it to do it right. I would not hold
doing it now on my account.

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

No need for kernel support, but run time compiler.
Exports can not be fully created object files.
Both calls and definitions have to be instantiated at run
time in this case. Note that I would like that feature very much
since I'm doing similar work in assembler currently,
but only for value based template functions as then templates
are just binaries with "holes" that are copied into buffer
then patched by constructor functions in run time.
Run time generated templates will be slow first few passes
then they'll work same as ordinary code.
But since export is just user code reorganization, but everything
have to be recompiled anyway, I think that actually there is no
dynamic linking problem regarding exports.
Note that I know nothing about EDG implementation and never
used exports.

Greetings, Branimir.

 

[James Kanze]

You seem to be sitting on the fence on this one, can you tell us what
you really think ?

What I just said: there is no real technical reason for not
implementing export today. It does require a certain amount of
effort (i.e. cost), but nothing a company like Microsoft
couldn't easily afford.

A simple matter of programming ?

Maybe you missed the implied smiley on my previous post however, I
think there is a little more to it to do it right.

That's true of just about anything. It obviously does
require preliminary design, development of tests, etc., as well
as pure programming. And like most non-trivial things, it's
easy to get wrong if you aren't careful. But that's true of a
lot of other things as well---correct implementation of two
phase lookup isn't trivial either, nor is template type
deduction.

I would not hold
doing it now on my account.

I rather suspect that it is more than a one man project. (From
what I understand, it was implemented by a single person at EDG.
But not every company has the chance to have someone that gifted
on their staff.)

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either. I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation

Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream" compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

but I suspect that debugging
will need to be worked out as well.

It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously. It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

 

[Gianni Mariani]

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.

I think your reply indicates I didn't make my point.

... I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.


Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream" compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business. Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

That small implementation detail may very well require recompilation of
the entire applications.

 

[Branimir Maksimovic]

triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

I have found this article that says:
"If either the context of the template's instantiation or the context
of the template's definition changes, both get recompiled. That's why,
if the template definition changes, we have to go back to all the
points of instantiation and rebuild those translation units. (In the
case of the EDG compiler, the compiler recompiles all the calling
translation units needed to recreate every distinct specialization, in
order to recreate all of the instantiation contexts, and for each of
those calling translation units it also recompiles the file containing
the template definition in order to recreate the definition context.)
"

http://www.gotw.ca/publications/mill23-x.htm
and this is also interesting:
http://www.ddj.com/showArticle.jhtml?articleID=184401584#1


Greetings, Branimir

 

[James Kanze]

I think your reply indicates I didn't make my point.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

 

[James Kanze]

I think your reply indicates I didn't make my point.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

 

[James Kanze]

I think your reply indicates I didn't make my point.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

 

[James Kanze]

I think your reply indicates I didn't make my point.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

 

[James Kanze]

I think your reply indicates I didn't make my point.

The coup de grâce for export is dynamic libs where the run time dynamic
linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, à la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.

I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
anything here?

The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
exported template.

Now you've really lost me.

Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

That small implementation detail may very well require recompilation of
the entire applications.

Unless the template in which it changed was exported. That's
exactly my point.

 

[JohnQ]

C++ class is same thing as struct.

It would probably be better to make the two concepts (whatever they are)
separate. If they were different animals, how would you (anyone here)
distinguish the two for the better?

John

 

[JohnQ]

What I just said: there is no real technical reason for not
implementing export today. It does require a certain amount of
effort (i.e. cost), but nothing a company like Microsoft
couldn't easily afford.

And you think that a language spec that only mega-corps can implement is OK?

John

 

[red floyd]

And you think that a language spec that only mega-corps can implement is OK?

Comeau implements export. I'd hardly call Comeau a mega-corp. No
offense intended to Greg.

 

[JohnQ]

Comeau implements export. I'd hardly call Comeau a mega-corp. No offense
intended to Greg.

It's already been noted though that they are "gifted"
(intellectually/technically) over at Comeau. If it's inaccessible to "the
layman", it's probably just as bad. If 'export' has to do with dynamic
linking, it sounds like something I want. If it goes "way overboard" into
binary compatibilty of objects, I can probably do without it.

John