In article <8ilh59$nqm$1@nnrp1.deja.com>, wmm@fastdial.net writes
>A bit of historical comparison may shed some light.  If you look
>in the corresponding wording in the ARM, it says, 'Linkage to a
>function written in the C programming language, "C", and linkage
>to a C++ function, "C++", must be provided by every
>implementation.'  This could be read as saying that C++
>programs must actually be linkable with C functions.

As the original implementation of C++ (CFront) was a translator to C
which would then be compiled with a C compiler for the platform being
used, I always assumed that extern "C" really meant 'Do not translate
this, just pass it as is to the native C compiler).  When we moved on to
native C++ compilers something had to be done to preserve the legacy
code.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

(much rearrangement to get some rough priority order)
Greg Comeau <comeau@panix.com> wrote:
> In article <1ecbc6g.1nwhgl81jng872N%jthill@telus.net>,
> Jim Hill <jthill@telus.net> wrote:
> >But I can't for the life of me see how to read
> >"shall provide for" as "may prevent".
> It's not that it may prevent it, it's that it can't guarantee it
> can allow.

Aren't you contradicting yourself? You'd just said

> > if the C implementor and the C++ implementor document it,
> > then it's possible.

which was my point all along: if there is no C implementation at all on
the platform, or at any rate none of the current ones are layout/linkage
compatible - both circumstances beyond the C++ implementor's control -
then the only possible way to make a C implementation that *is*
compatible is if the C++ implementor documents its extern "C" linkage.
If they don't do that, in what sense have they "provided for" it? In
order to achieve it, that's necessary, and only they can do it. So I
think they're required to do it, by the cited language. Nobody has
addressed this.

> >linkage to (at least) machine language, via extern "C++" or any
> >other, can unquestionably be achieved given such documentation.
> The issue is whether it can be achieved... at all,  but more like
> sometimes.  You seem to be saying it always can be achieved, and
> that doesn't seem to be the case to me.
To machine language?!?? That's a side issue at this point - you
convinced me earlier that documentation isn't required - but, Mr.
Comeau, think what you're saying!

> >and a strong argument can be made that the first alternative above isn't
> >what the standard as written means.
> I never likes the words in that section to be honest, but too,
> was never too compelled to see them changed either....

I don't have any desire to change it either, no matter whether it means
what I think it does. I just want to know what it actually means, and
the desire to see my question addressed is beginning to overtake my
curiosity on the question itself. Hm. That makes this my last post on
the subject.

> >I've quoted you presenting two possible meanings of 7.5p3 above.
> Huh?
"You" was Mike Miller in that post. Sorry if I left the attributions
unclear.

I was objecting to
> ><wmm@fastdial.net> wrote:
> >> what is required is that vendor A's implementation accept the linkage
> >> specification 'extern "C"'.
and
> >> It is _not_ required to provide link or runtime compatibility with
> >> _any_ C implementation.
with this:
> >But I cannot go along with the excluded-middle argument presented,
> A "middle argument" was presented by also excluded????

Not quite. I was asking "B?" and getting back "A, not C!" by way of
denying B - at any rate denying B is how I had to read it to make any
sense of it at all.

That's an excluded-middle argument. It's not valid.

> >I, also, have said less in this thread than people often say I have.
> Two point on the above aspects:
> 1) It's not always clear what's being said, so covering all the bases
>    never hurts.
Fair enough, but it's exasperating to have an argument I'm not making
addressed in every reply, while the one I _am_ making hasn't yet been
addressed.

> 2) I don't always post just to the poster, but sometimes to the
>    readership at large too.
<GRUMP> How many times must we sing the "the standard doesn't say X" "I
didn't say it does" refrain before we get to sing a verse? </GRUMP>

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <8ilh59$nqm$1@nnrp1.deja.com>, wmm@fastdial.net writes
> >A bit of historical comparison may shed some light.  If you look
> >in the corresponding wording in the ARM, it says, 'Linkage to a
> >function written in the C programming language, "C", and linkage
> >to a C++ function, "C++", must be provided by every
> >implementation.'  This could be read as saying that C++
> >programs must actually be linkable with C functions.
>
> As the original implementation of C++ (CFront) was a translator to C
> which would then be compiled with a C compiler for the platform being
> used, I always assumed that extern "C" really meant 'Do not translate
> this, just pass it as is to the native C compiler).  When we moved on to
> native C++ compilers something had to be done to preserve the legacy
> code.

It's important to point out that what got put in the final standard is
significantly different from your original assumption. "extern C" on a
function type now indicates the interface method, but not how the body
of that function is to be compiled. The body of an "extern C" function
can be defined in C++ code. If it is, then it must be interpreted as
such. Where C and C++ rules differ in how they interpret the same piece
of code, that code is interpreted according to C++ rules, not C rules.
Even more important, the function body can use features specific to C++,
such as operator overloads, calls to C++ functions with default
parameters, use of the :: operator, and full use of C++ classes.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <8ilh59$nqm$1@nnrp1.deja.com>, wmm@fastdial.net writes
> >A bit of historical comparison may shed some light.  If you look
> >in the corresponding wording in the ARM, it says, 'Linkage to a
> >function written in the C programming language, "C", and linkage
> >to a C++ function, "C++", must be provided by every
> >implementation.'  This could be read as saying that C++
> >programs must actually be linkable with C functions.
>
> As the original implementation of C++ (CFront) was a translator to C
> which would then be compiled with a C compiler for the platform being
> used, I always assumed that extern "C" really meant 'Do not translate
> this, just pass it as is to the native C compiler).  When we moved on to
> native C++ compilers something had to be done to preserve the legacy
> code.

I don't think that is a correct interpretation.

C++ was always intended to be able to interoperate with a companion
C compiler. Originally, you were assured there was a companion C
compiler, because, as Francis points out, the original C++ compilers
translated C++ source code into C source code.

There doesn't seem to be any good way for the C++ standard to require
a companion C compiler, and it could be argued that it should not
require one.  The standard takes the viewpoint, as I interepret it,
that IF there is a companion C compiler, C++ provides a syntax that
will allow C and C++ code to be combined, to the extent that the
implementation documents the compatibility.

Since C++ has features such as function overloading that are not
part of C, the relationship of C++ function source code to object
code will not in general be the same as the relationship of C source
code to object code, even for code that is valid and has the same
meaning in both languages.

For example, the spelling of a given function name as seen in object
code might be different in C and C++. The function calling sequence
might be different. Thus, the C linkage specification tells the
compiler to use the C linkage and calling conventions instead of the
C++ conventions.

This linkage concept transcends any particular implementation, and is
not there just to support legacy code. It has always been a goal to
allow C++ programs to link to C libraries, and to some extent, the
other way around.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <394F7078.D2B76C4C@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>It's important to point out that what got put in the final standard is
>significantly different from your original assumption. "extern C" on a
>function type now indicates the interface method, but not how the body
>of that function is to be compiled. The body of an "extern C" function
>can be defined in C++ code. If it is, then it must be interpreted as
>such. Where C and C++ rules differ in how they interpret the same piece
>of code, that code is interpreted according to C++ rules, not C rules.
>Even more important, the function body can use features specific to C++,
>such as operator overloads, calls to C++ functions with default
>parameters, use of the :: operator, and full use of C++ classes.

Yep, I agree, I was just introducing a bit of history. However there is
absolutely no reason that extern "C" provide something that is
compatible with any C compiler even if the platform has dozens of them:)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <wJmJuKAQr6T5EwDC@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>However there is
>absolutely no reason that extern "C" provide something that is
>compatible with any C compiler even if the platform has dozens of them:)

s/reason/requirement/

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <394F7078.D2B76C4C@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>Francis Glassborow wrote:
>> In article <8ilh59$nqm$1@nnrp1.deja.com>, wmm@fastdial.net writes
>> >in the corresponding wording in the ARM, it says, 'Linkage to a
>> >function written in the C programming language, "C", and linkage
>> >to a C++ function, "C++", must be provided by every
>> >implementation.'  This could be read as saying that C++
>> >programs must actually be linkable with C functions.
>>
>> ...I always assumed that extern "C" really meant 'Do not translate
>> this, just pass it as is to the native C compiler).  When we moved on to
>> native C++ compilers something had to be done to preserve the legacy
>> code.
>
>It's important to point out that what got put in the final standard is
>significantly different from your original assumption.

It's different, yes (I'll leave "significantly" alone :)

>"extern C" on a
>function type now indicates the interface method,

(...Or something like that...)

>but not how the body of that function is to be compiled.

If I understand you, it never indicated how the body was to be compiled.

>The body of an "extern C" function
>can be defined in C++ code.

And always could be.

>If it is, then it must be interpreted as such.

Agreed.

>Where C and C++ rules differ in how they interpret the same piece
>of code, that code is interpreted according to C++ rules, not C rules.

And even where they agree they go accto C++ rules :)
(But let's make it clear you're still talking  about compiling
the body of the function with a C++ compiler, and not a C compiler.)

>Even more important, the function body can use features specific to C++,
>such as operator overloads, calls to C++ functions with default
>parameters, use of the :: operator, and full use of C++ classes.

...so long as compiled with a C++ compiler.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <394FA236.721EF326@sun.com>, Steve Clamage
<stephen.clamage@sun.com> writes
>This linkage concept transcends any particular implementation, and is
>not there just to support legacy code. It has always been a goal to
>allow C++ programs to link to C libraries, and to some extent, the
>other way around.

Are you saying that even if there had been no legacy code that expected
to use extern "C" we would still have provided something so vacuous that
no implementer is required to anything about it. I believe that,
strictly speaking, an implementer can completely ignore extern "C" other
than the requirement that the name carries no scope or overloading
information.  As there exist typesafe C implementation that provide
mangled names (and that is completely allowed by C) the ordinary but
scope free name will do.  IOWs all that is needed to support extern "C"
is to treat code so defined as if it were at global scope. It seems to
me that this adds nothing to C++.  Linkage specifications are very
useful, but the requirement to support extern "C" means little if
anything.  The support is a QoI one, but so is support for extern
"Fortran", the difference being that a compiler can reject the later but
not the former.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ecgvsl.x4qckzffewfqN%jthill@telus.net>,
  jthill@telus.net (Jim Hill) wrote:
> if there is no C implementation at all on
> the platform, or at any rate none of the current ones are
layout/linkage
> compatible - both circumstances beyond the C++ implementor's control -
> then the only possible way to make a C implementation that *is*
> compatible is if the C++ implementor documents its extern "C" linkage.
> If they don't do that, in what sense have they "provided for" it? In
> order to achieve it, that's necessary, and only they can do it. So I
> think they're required to do it, by the cited language. Nobody has
> addressed this.

Sure I did; perhaps you missed my post in reply to your most
recent one before this.  The phrase "provide for" doesn't
mean (or at least isn't intended to say) what you think it
does.  As I pointed out in that post, the ARM wording said
that implementations were required to "provide" linkage to
C functions.  We wanted to make clear that link compatibilty
is _not_ required, so we changed that to "provide for."  In
its context, the phrase is just a transition from 7.5p2,
which is the general description of the string-literal in a
linkage specification, to 7.5p3, which gives two specific
string-literal values that an implementation is required to
accept and the meaning (associated language) for each of
those values.  Perhaps "provide for" was an unfortunate
choice of words for this transition phrase (although I'm not
aware of it having caused confusion before).  In any event,
accepting "C" as the string-literal and not associating it
with any other language is the only "provision for" C
language linkage that was intended by this wording.

> the only possible way to make a C implementation that *is*
> compatible is if the C++ implementor documents its extern "C" linkage.

I think this is the reason we have had difficulty communicating.
The C++ standard (properly) does not address what is required
to "make a C implementation that is compatible."  It's concerned
with what C++ implementations do, not with what C or other
language implementations might or might not be able to do.  See
below in regard to your "excluded middle" argument.

> I don't have any desire to change it either, no matter whether it
means
> what I think it does. I just want to know what it actually means, and
> the desire to see my question addressed is beginning to overtake my
> curiosity on the question itself.

What it actually means is what we've been saying: an
implementation is required to accept "C" in a linkage-
specification and there are no further requirements,
either in terms of actively providing linkage with C
fragments or in terms of assisting a C implementor to
provide such linkage.

> I was objecting to
> > ><wmm@fastdial.net> wrote:
> > >> what is required is that vendor A's implementation accept the
linkage
> > >> specification 'extern "C"'.
> and
> > >> It is _not_ required to provide link or runtime compatibility
with
> > >> _any_ C implementation.
> with this:
> > >But I cannot go along with the excluded-middle argument presented,
>
> I was asking "B?" and getting back "A, not C!" by way of
> denying B - at any rate denying B is how I had to read it to make any
> sense of it at all.
>
> That's an excluded-middle argument. It's not valid.

The difference in understanding the domain of requirements
laid by the Standard, which I mentioned above, is the reason
for this.  (I'm assuming that the "B" in this scenario is
the supposed requirement to document storage layouts to
assist others in achieving linkage with a given C++
implementation.)

I certainly never intended an "excluded middle" argument; it
simply never occurred to me that your B was in the same domain
as A and C.  That is, my presupposition was that the only
things the Standard might possibly require were features of
the C++ implementation (like accepting the syntax -- "A" or
actually providing link compatibility -- "C"), along with a
requirement to document features that are described as
"implementation-defined."  Providing assistance to an outside
party in achieving compatibility is not in the purview of a
language standard, as I understand it, so it took several
messages before I realized that you were viewing that as the
meaning of "provide for."  As a result, I read your arguments
in favor of "something more than A" as being arguments in
favor of "C" and responded accordingly.

> it's exasperating to have an argument I'm not making
> addressed in every reply, while the one I _am_ making hasn't yet been
> addressed.

It's been addressed now, I trust.  Sorry for misunderstanding
what you were saying, but that's what happens when there are
fundamentally different presuppositions involved.

--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Fm301yBWA1T5EwXY@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <8ilh59$nqm$1@nnrp1.deja.com>, wmm@fastdial.net writes
>>A bit of historical comparison may shed some light.  If you look
>>in the corresponding wording in the ARM, it says, 'Linkage to a
>>function written in the C programming language, "C", and linkage
>>to a C++ function, "C++", must be provided by every
>>implementation.'  This could be read as saying that C++
>>programs must actually be linkable with C functions.
>
>As the original implementation of C++ (CFront) was a translator to C
>which would then be compiled with a C compiler for the platform being
>used, I always assumed that extern "C" really meant 'Do not translate
>this, just pass it as is to the native C compiler).  When we moved on to
>native C++ compilers something had to be done to preserve the legacy
>code.

Although compatible with C was foremost in C++ history
("Who didn't want access to sqrt() and printf()"?),
and even some features eased C++ to C translation, I don't
find the above particularly compelling either historically or
technically.

As I recall it (wow, can't believe I ever did this!!!) there used
to be an "overload" keyword, and the first prototype became the
"linkage to C" one.  And as is now, it wasn't a guarantee to link
to C, just that if there were no more uses of that name, then,
as an implementation detail, it was not mangled.  In an odd way,
it became a handy hook to not mangle it.  As I recall:

    void comeau();
    void comeau(int); // error, up to 1.2? spec of cfront

    overload Comeau;
    void Comeau(); // "first overload", not mangles as per impl detail
    void Comeau(int);//Mangled as per impl detail..subsequent Comeau's too

The problem is that the different Comeau's could end up in a
translation unit from two different headers, and so this:

    overload Comeau;
    void Comeau(int);//Now this one's the first overload
    void Comeau();

or even just this:

    void Comeau(int);

and so on and so this ended up in some musical chairs game
though at least something like this gave an error:

    void Comeau(int); overload Comeau; void Comeau();

Anyway, other points include:
* A C compiler could if it wanted to also name mangle, so
  just passing the unadulterated name to a C compiler isn't enough.
* The linker, and not just the C compiler proper, is at issue here too
  for most implementations.
* Last but not least, I never considered this as a legacy issue
  even for native code compilers, although as an implementation
  detail it became a handy way to leverage off of existing technology.
  Few compilers were ever binary compatible with each other.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
>
> In article <394F7078.D2B76C4C@wizard.net>,
> James Kuyper  <kuyper@wizard.net> wrote:
> >Francis Glassborow wrote:
....
> >> ...I always assumed that extern "C" really meant 'Do not translate
> >> this, just pass it as is to the native C compiler).  When we moved on to
> >> native C++ compilers something had to be done to preserve the legacy
> >> code.
> >
> >It's important to point out that what got put in the final standard is
> >significantly different from your original assumption.
>
> It's different, yes (I'll leave "significantly" alone :)
>
> >"extern C" on a
> >function type now indicates the interface method,
>
> (...Or something like that...)
>
> >but not how the body of that function is to be compiled.
>
> If I understand you, it never indicated how the body was to be compiled.

I'm willing to take your word on that; I know fairly little about
pre-standard C++ (if you conclude from this that I know little about
real-world C++, you'd be correct). But Francis describes "always"
assuming that "extern C" meant "pass it on as is to the native C
compiler". He apparantly did not revise that assumption until the
development of native C++ compilers, and it's not entirely clear from
his wording that he revised it even then. I wanted to make it clear that
this is not what it means now, regardless of what it might have meant in
the past.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <395153B6.84B7ACB@sun.com>, Steve Clamage
<stephen.clamage@sun.com> writes
>There doesn't seem to be a good way to say in the standard that using
>extern "C" assures you can link C++ and C code together.  But since
>programmers expect to be able to do such linking, an implementation
>that didn't make it easy would not get much use.  I don't think anyone
>would bother to implement a C++ compiler that couldn't easily link
>to C code.

Well as it isn't even always possible to link object code form different
C compilers I fail to see how C++ can miraculously do more.

>
>In the end, it is as you say, a quality of implementation issue.

Yes, there we can agree.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <394FA236.721EF326@sun.com>, Steve Clamage
> <stephen.clamage@sun.com> writes
> >This linkage concept transcends any particular implementation, and is
> >not there just to support legacy code. It has always been a goal to
> >allow C++ programs to link to C libraries, and to some extent, the
> >other way around.
>
> Are you saying that even if there had been no legacy code that expected
> to use extern "C" we would still have provided something so vacuous that
> no implementer is required to anything about it.

C++ has always allowed linking to C from its earliest days, so I
think the point is moot. It was one of the fundamental design
principles.  Prior to the introduction of type-safe linkage in about
1989, linking to C was not an issue, because a C compiler was (almost)
always used in translating C++ code to machine code, and there was
little reason to mangle names or use other linking conventions.

Once type-safe linkage was introduced into C++, a mechanism was
needed to say, "This function is (masquerading as) a C function".
Linking to C code was still assumed. The linkage specification was
introduced at the same time to solve that problem.

Perhaps we are saying the same thing in different ways.

>  I believe that,
> strictly speaking, an implementer can completely ignore extern "C" other
> than the requirement that the name carries no scope or overloading
> information.  As there exist typesafe C implementation that provide
> mangled names (and that is completely allowed by C) the ordinary but
> scope free name will do.  IOWs all that is needed to support extern "C"
> is to treat code so defined as if it were at global scope. It seems to
> me that this adds nothing to C++.  Linkage specifications are very
> useful, but the requirement to support extern "C" means little if
> anything.  The support is a QoI one, but so is support for extern
> "Fortran", the difference being that a compiler can reject the later but
> not the former.

There doesn't seem to be a good way to say in the standard that using
extern "C" assures you can link C++ and C code together.  But since
programmers expect to be able to do such linking, an implementation
that didn't make it easy would not get much use.  I don't think anyone
would bother to implement a C++ compiler that couldn't easily link
to C code.

In the end, it is as you say, a quality of implementation issue.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <swrewtA6+jU5EwLY@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <395153B6.84B7ACB@sun.com>, Steve Clamage
><stephen.clamage@sun.com> writes
>>There doesn't seem to be a good way to say in the standard that using
>>extern "C" assures you can link C++ and C code together.  But since
>>programmers expect to be able to do such linking, an implementation
>>that didn't make it easy would not get much use.  I don't think anyone
>>would bother to implement a C++ compiler that couldn't easily link
>>to C code.
>
>Well as it isn't even always possible to link object code form different
>C compilers I fail to see how C++ can miraculously do more.

This was a related point I raised to jthill earlier in this thread...
about often C code calling C code compiled from another C compiler
often not possible.  Anyway, what just might be true is that I can
imagine more C++ compilers being able to call more C routines than
other C compilers can! :)

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ecgvsl.x4qckzffewfqN%jthill@telus.net>,
Jim Hill <jthill@telus.net> wrote:
>(much rearrangement to get some rough priority order)
>Greg Comeau <comeau@panix.com> wrote:
>> In article <1ecbc6g.1nwhgl81jng872N%jthill@telus.net>,
>> Jim Hill <jthill@telus.net> wrote:
>> >But I can't for the life of me see how to read
>> >"shall provide for" as "may prevent".
>> It's not that it may prevent it, it's that it can't guarantee it
>> can allow.
>
>Aren't you contradicting yourself? You'd just said
>
>> > if the C implementor and the C++ implementor document it,
>> > then it's possible.
>
>which was my point all along:

Then we agree :)  I don't see any contradiction.
If the C++ vendor documents it'll work "so-and-so", then that's that,
go use it.  If the C++ vendor says they don't know, etc, then that's that
too and you may or may not be able to use it.

> if there is no C implementation at all on
>the platform, or at any rate none of the current ones are layout/linkage
>compatible - both circumstances beyond the C++ implementor's control -

Perhaps.

>then the only possible way to make a C implementation that *is*
>compatible is if the C++ implementor documents its extern "C" linkage.

That documents the C++ scheme, but does not make a C implementation
compatible just miraculously.  How could it?  Sure, it might be so that
a C compiler exists that happens to match it, then fine, you've got
the fighting chanve I keep talking about.  If not, then you have to
wait for such a C compiler.  Again, no guarantee.  They have no
requirement to do so.  On this same note, a C++ compiler might just
say "Our version x.y.z is compatible with so-and-so C version a.b.c"
and that's that.  It satisfies the documentation at least as far
as extern "C" is concerned as I recall it.

>If they don't do that, in what sense have they "provided for" it? In
>order to achieve it, that's necessary, and only they can do it. So I
>think they're required to do it, by the cited language. Nobody has
>addressed this.

I suspect this paragraph above is the core of your rejecting mine and
Mike's conclusions/remarks (at least some of them).  I think Mike has
amply discussed what "provide for" means multiple times.  Nonetheless
I'll dwell here at tad, in the hope of hitting it home.  Let's see.

Well, int's must also be provided for.  But there's implementation
defined aspects to them, they must be at least 32 bits but can be more.
No matter if they are larger or not, they are supposed to be documented.
So, their max size is not guaranteed for a given implementation.
But even if the vendor documents it, that just doesn't automatically
make all C++ compilers compatible with each other.  Yet int
will still be provided for in this manner.

IOWs, int must be "provided" yet aspects about int must also
be "provided for".  To provide is to stipulate and supply something,
and it becomes requirementi'ish, however, to provide for is about
possibilities and opportunities, and becomes allowance'y.

So, like int, extern "C" and extern "C++" must be provided for.
That is, you must be allowed to say them in code. But,
it's implementation defined what's going to go on as a result
of allowing such specifications.  However, the intent is for
it to then link with some C implementation's functions and objects.

>> >linkage to (at least) machine language, via extern "C++" or any
>> >other, can unquestionably be achieved given such documentation.
>> The issue is whether it can be achieved... at all,  but more like
>> sometimes.  You seem to be saying it always can be achieved, and
>> that doesn't seem to be the case to me.
>To machine language?!?? That's a side issue at this point - you
>convinced me earlier that documentation isn't required - but, Mr.
>Comeau, think what you're saying!

Oops, I should have said "This issue isn't whether..." and not
"The issue is whether.." if that helps any.

>> >and a strong argument can be made that the first alternative above isn't
>> >what the standard as written means.
>> I never likes the words in that section to be honest, but too,
>> was never too compelled to see them changed either....
>
>I don't have any desire to change it either, no matter whether it means
>what I think it does. I just want to know what it actually means, and
>the desire to see my question addressed is beginning to overtake my
>curiosity on the question itself. Hm. That makes this my last post on
>the subject.

Probably mine too unless something new from the participants can
reveal something further.  I'm beginning to wonder if this isn't one
of those case where perhaps the two sides are talking past each other
(probably even agreeing all along)?

>I was objecting to
>> ><wmm@fastdial.net> wrote:
>> >> what is required is that vendor A's implementation accept the linkage
>> >> specification 'extern "C"'. and
>> >> It is _not_ required to provide link or runtime compatibility with
>> >> _any_ C implementation.
>with this:
>> >But I cannot go along with the excluded-middle argument presented,
>> A "middle argument" was presented by also excluded????
>
>Not quite. I was asking "B?" and getting back "A, not C!" by way of
>denying B - at any rate denying B is how I had to read it to make any
>sense of it at all.
>
>That's an excluded-middle argument. It's not valid.

It might be worth raising some point from scratch, so I don't
know what A, B or C refer to at this point :)

>> >I, also, have said less in this thread than people often say I have.
>> Two point on the above aspects:
>> 1) It's not always clear what's being said, so covering all the bases
>>    never hurts.
>Fair enough, but it's exasperating to have an argument I'm not making
>addressed in every reply, while the one I _am_ making hasn't yet been
>addressed.

Well, I'm unclear on the aspect your asking which isn't being replied
to, so as mentione dabove, it might be worth reraising the whole
thing is a new thread from scratch.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<wmm@fastdial.net> wrote:>
> I certainly never intended an "excluded middle" argument; it simply never
> occurred to me that your B was in the same domain as A and C.
I very much doubt this is necessary, but just in case: no offense
intended, none taken. "Fundamentally different presuppositions" were
indeed getting in the way. (C'mon, sing along) Been there, done that.

> That is, my presupposition was [...] a requirement to document features
> that are described as "implementation-defined."  Providing assistance to
> an outside party in achieving compatibility is not in the purview of a
> language standard,

And there it is. Francis Glassborow's observation that the requirements
here are vacuous as intended helped me see what's missing: I was trying
to make the wording mean *something*.

Look at it this way: an implementation is certainly free to include any
documentation it likes. No requirement is necessary. Detailed semantics
for extern "C" are given, and the standard already requires it
elsewhere. So what's left that the implementation is required to
document or provide for on its own?

The answer - even _I_ see it now - is "the simple `extern "C"
requirement is redundant, and nothing else is required". I had a very
difficult time even seeing that, let alone accepting it.  Thanks to one
and all for the patience.

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<wmm@fastdial.net> wrote:

> This is the point various ones of us have been making: what is required is
> that vendor A's implementation accept the linkage specification 'extern
> "C"'.

> It is _not_ required to provide link or runtime compatibility with _any_ C
> implementation.

And the standard doesn't say it is required, nor have I said it does. We
are, I suspect, mutually exasperated by our repeated attempts to agree
on this.

Greg Comeau said
> there is much less said in this section of the Standard than people often
> say there is

I, also, have said less in this thread than people often say I have.

I've quoted you presenting two possible meanings of 7.5p3 above. Those
are the two I recall seeing from others here. I agree that the second is
an obviously ludicrous interpretation, not even worth refuting until
someone sufficiently asinine argues it with money at stake.

But I cannot go along with the excluded-middle argument presented, and a
strong argument can be made that the first alternative above isn't what
the standard as written means. It runs roughly like this:
=
`extern "C"` linkage is required numerous places in the standard, and
required semantics for it are given in 7.5. There is no requirement that
the extern "C" Standard C library functions be written in the C
language. There is no requirement that any user-declared extern "C"
function be written in the C language (and at least one example of an
extern "C" function written in C++ is given). If the standard meant to
say "If linkage to user-supplied functions written in the C programming
is provided, it shall be provided via `extern "C"` linkage", it could
have said so. It does not. It doesn't say it shall be provided. It does
say it shall be _provided for_.
=

In our original conversation I wound up asking whether this and 7.5p9
didn't wind up requiring that implementations document their layouts and
linkage conventions in detail, since for instance linkage to (at least)
machine language, via extern "C++" or any other linkage, can
unquestionably be achieved given such documentation.

Greg convinced me that wasn't the case: if the implementation doesn't
document it it's not possible, so the implementation isn't required to
document it if it doesn't document it. Now, I don't feel particularly
embarrassed at not seeing that myself, if you get my drift, but it's a
good joke and I agree it's legitimate argument.

I finished that conversation with a question, which I asked again of Mr.
Pollard. Here's what I said originally:
> "shall provide for" then means "shall not, through action or inaction
> within its responsibility, prevent" - it's not required to provide a C
> compiler, but if it doesn't it is then required not to prevent - even
> through lack of documentation in this case - linkage with some other?

Perhaps my attempts to rule out interpretations I didn't intend hampered
the clarity here. My apologies if so. I meant that to ask whether an
implementation that does not actually provide linkage (through their own
or another implementation) is then required to document its POD layouts,
so that some C implementation can achieve linkage, even none of the
current ones can.

That is the situation of the hypothetical "Vendor A" we're discussing.
No C provided, other C implementations not compatible, ... no docs even
on extern "C" linkage and layout?

Without the docs, here, linkage "to functions written in the C
programming language" is again going to be impossible. But this isn't
the same situation discussed above: the implementation isn't required to
"provide for linkage to functions written in machine language", but it
_is_ required to do so for C. There isn't C implementation for which
that's possible currently, and *again* I say Vendor A isn't required to
ensure that there is. But I can't for the life of me see how to read
"shall provide for" as "may prevent".

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ecbc6g.1nwhgl81jng872N%jthill@telus.net>,
Jim Hill <jthill@telus.net> wrote:
><wmm@fastdial.net> wrote:
>> This is the point various ones of us have been making: what is required is
>> that vendor A's implementation accept the linkage specification 'extern
>> "C"'.
>
>> It is _not_ required to provide link or runtime compatibility with _any_ C
>> implementation.
>
>And the standard doesn't say it is required, nor have I said it does. We
>are, I suspect, mutually exasperated by our repeated attempts to agree
>on this.
>
>Greg Comeau said
>> there is much less said in this section of the Standard than people often
>> say there is
>
>I, also, have said less in this thread than people often say I have.

Two point on the above aspects:
1) It's not always clear what's being said, so covering all the bases
   never hurts.
2) I don't always post just to the poster, but sometimes to the
   readership at large too.

>I've quoted you presenting two possible meanings of 7.5p3 above.

Huh?

>Those
>are the two I recall seeing from others here. I agree that the second is
>an obviously ludicrous interpretation, not even worth refuting until
>someone sufficiently asinine argues it with money at stake.

I guess I'd have to revisit the thread to be clear on this.
I'll just assume the below is the meat for now...

>But I cannot go along with the excluded-middle argument presented,

A "middle argument" was presented by also excluded????

>and a
>strong argument can be made that the first alternative above isn't what
>the standard as written means.

I never likes the words in that section to be honest, but too,
was never too compelled to see them changed either....

>It runs roughly like this:
>=
>`extern "C"` linkage is required numerous places in the standard, and
>required semantics for it are given in 7.5.

"it" being the linkage spec, ok.

>There is no requirement that
>the extern "C" Standard C library functions be written in the C
>language.

Agreed (as I recall it).

>There is no requirement that any user-declared extern "C"
>function be written in the C language (and at least one example
>of an extern "C" function written in C++ is given).

Agreed, ok.

>If the standard meant to
>say "If linkage to user-supplied functions written in the C programming
>is provided, it shall be provided via `extern "C"` linkage", it could
>have said so. It does not. It doesn't say it shall be provided. It does
>say it shall be _provided for_.
>=

Right, it doesn't require it, just provides a fighting chance for it.

>In our original conversation I wound up asking whether this and 7.5p9
>didn't wind up requiring that implementations document their layouts and
>linkage conventions in detail, since for instance linkage to (at least)
>machine language, via extern "C++" or any other linkage, can
>unquestionably be achieved given such documentation.

The issue is whether it can be achieved... at all,  but more like
sometimes.  You seem to be saying it always can be achieved, and
that doesn't seem to be the case to me.

Also, if I recall, even independent of linkage spec, I'm pretty
things like sizeof(SomeBuiltInType) is supposed to be documented,
though I forget how much about it.  Anyway, even if all of it should
be documents, I'm not convinced it helps.

>Greg convinced me that wasn't the case: if the implementation doesn't
>document it it's not possible,

I forget this context but anyway, even if documented, I don't see
how a guarantee can be required.

>so the implementation isn't required to
>document it if it doesn't document it.

This sounds confusing, but yes, I think you got that right.

> Now, I don't feel particularly
>embarrassed at not seeing that myself, if you get my drift, but it's a
>good joke and I agree it's legitimate argument.

Ok, good :)

>I finished that conversation with a question, which I asked again of Mr.
>Pollard. Here's what I said originally:
>> "shall provide for" then means "shall not, through action or inaction
>> within its responsibility, prevent" - it's not required to provide a C
>> compiler, but if it doesn't it is then required not to prevent - even
>> through lack of documentation in this case - linkage with some other?

I'm not clear I follow, but it seems right: It doesn't prevent but
it doesn't guarantee either.

>Perhaps my attempts to rule out interpretations I didn't intend hampered
>the clarity here. My apologies if so. I meant that to ask whether an
>implementation that does not actually provide linkage (through their own
>or another implementation) is then required to document its POD layouts,
>so that some C implementation can achieve linkage, even none of the
>current ones can.

If I understand the Q: The intent is to document them.

>That is the situation of the hypothetical "Vendor A" we're discussing.
>No C provided, other C implementations not compatible, ... no docs even
>on extern "C" linkage and layout?

If I understand you, it's not that there's no docs, it's that
there's no guarantee, just intentions.  Even if say POD layout
are documented, it may not be enough.

>Without the docs, here, linkage "to functions written in the C
>programming language" is again going to be impossible.

And yet the reality of it is that it occurs in many cases.
Which is exactly the fighting chance at work.

>But this isn't
>the same situation discussed above: the implementation isn't required to
>"provide for linkage to functions written in machine language", but it
>_is_ required to do so for C.

Ok.

>There isn't C implementation for which
>that's possible currently,

Why not... if the C implementor and the C++ implementor document it,
then it's possible.

>and *again* I say Vendor A isn't required to
>ensure that there is.

Right, this just seem to come full circle.

>But I can't for the life of me see how to read
>"shall provide for" as "may prevent".

It's not that it may prevent it, it's that it can't guarantee it
can allow.  Heck, it cannot even guarantee extern "C++"
across implementations (and actually you could probably even
argue within implementations either).

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ecbc6g.1nwhgl81jng872N%jthill@telus.net>,
  jthill@telus.net (Jim Hill) wrote:
> `extern "C"` linkage is required numerous places in the standard, and
> required semantics for it are given in 7.5. There is no requirement
that
> the extern "C" Standard C library functions be written in the C
> language. There is no requirement that any user-declared extern "C"
> function be written in the C language (and at least one example of an
> extern "C" function written in C++ is given). If the standard meant to
> say "If linkage to user-supplied functions written in the C
programming
> is provided, it shall be provided via `extern "C"` linkage", it could
> have said so. It does not. It doesn't say it shall be provided. It
does
> say it shall be _provided for_.
> =
>
> In our original conversation I wound up asking whether this and 7.5p9
> didn't wind up requiring that implementations document their layouts
and
> linkage conventions in detail, since for instance linkage to (at
least)
> machine language, via extern "C++" or any other linkage, can
> unquestionably be achieved given such documentation.
>
> Greg convinced me that wasn't the case: if the implementation doesn't
> document it it's not possible, so the implementation isn't required to
> document it if it doesn't document it. Now, I don't feel particularly
> embarrassed at not seeing that myself, if you get my drift, but it's a
> good joke and I agree it's legitimate argument.
>
> I finished that conversation with a question, which I asked again of
Mr.
> Pollard. Here's what I said originally:
> > "shall provide for" then means "shall not, through action or
inaction
> > within its responsibility, prevent" - it's not required to provide
a C
> > compiler, but if it doesn't it is then required not to prevent -
even
> > through lack of documentation in this case - linkage with some
other?
>
> Perhaps my attempts to rule out interpretations I didn't intend
hampered
> the clarity here. My apologies if so. I meant that to ask whether an
> implementation that does not actually provide linkage (through their
own
> or another implementation) is then required to document its POD
layouts,
> so that some C implementation can achieve linkage, even none of the
> current ones can.
>
> That is the situation of the hypothetical "Vendor A" we're discussing.
> No C provided, other C implementations not compatible, ... no docs
even
> on extern "C" linkage and layout?
>
> Without the docs, here, linkage "to functions written in the C
> programming language" is again going to be impossible. But this isn't
> the same situation discussed above: the implementation isn't required
to
> "provide for linkage to functions written in machine language", but it
> _is_ required to do so for C. There isn't C implementation for which
> that's possible currently, and *again* I say Vendor A isn't required
to
> ensure that there is. But I can't for the life of me see how to read
> "shall provide for" as "may prevent".

The idea that the words "provide for" might impose a requirement
for documenting internal storage layouts is a novel interpretation.
I'm sure that none of us had anything like this in mind when
those words were written.

A bit of historical comparison may shed some light.  If you look
in the corresponding wording in the ARM, it says, 'Linkage to a
function written in the C programming language, "C", and linkage
to a C++ function, "C++", must be provided by every
implementation.'  This could be read as saying that C++
programs must actually be linkable with C functions.

Obviously, that was not what we wanted to say, so the wording was
softened to "provide for" -- that is, that linkage specifications
for C and C++ must be accepted, regardless of whether actual C
linkage were available.

It was never our intent that "provide for" might be read as a
requirement on a vendor to assist an outside party to achieve
linkage -- only that the implementation must accept code that
is written as if linkage to C were possible.

Look at the flow of that section: 7.5p2 talks about the syntax
of the linkage specification and the meaning of the contained
string-literal.  7.5p3 is just the extension of that; _all_ it
says is that "C" and "C++" must be accepted as values of the
string-literal, and it gives the meaning (associated language)
for each.  That's it.  Nothing further is intended.

In retrospect, perhaps we should have felt freer in this case
to change the wording inherited from the ARM; something like,
'Every implementation shall accept "C" and "C++" as values of
the string-literal, indicating linkage with program fragments
written in the C and C++ languages, respectively' would have
been less confusing.  That is what we meant.

Oh, well, this whole chapter is a bit of a hodge-podge as a
result of editing over time, so I imagine it will be rewritten
from scratch in the next version of the Standard.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jonathan de Boyne Pollard <J.deBoynePollard@tesco.net> wrote:

> Imagine a platform whose C++ implementation (from vendor A) aligns structure
> members to 1 byte boundaries, but whose C implementation (from vendor B)
> aligns structure members to 8 byte boundaries.  In this case there would be
> certain (POD) structure types that can be defined in the C++ language
> implementation that cannot be described in the C language implementation.

In what sense does vendor A's implementation "provide for linkage to
functions written in the C programming language" as it's required to do?

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Hill wrote:
>
> Jonathan de Boyne Pollard <J.deBoynePollard@tesco.net> wrote:
>
> > Imagine a platform whose C++ implementation (from vendor A) aligns structure
> > members to 1 byte boundaries, but whose C implementation (from vendor B)
> > aligns structure members to 8 byte boundaries.  In this case there would be
> > certain (POD) structure types that can be defined in the C++ language
> > implementation that cannot be described in the C language implementation.
>
> In what sense does vendor A's implementation "provide for linkage to
> functions written in the C programming language" as it's required to do?

In the sense that linkage is provided for functions that don't use
problematic structure types. The standard doesn't require coverage for
all possible function signatures.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ec9qbu.14tx63ssx9zjiN%jthill@telus.net>,
  jthill@telus.net (Jim Hill) wrote:
> Jonathan de Boyne Pollard <J.deBoynePollard@tesco.net> wrote:
>
> > Imagine a platform whose C++ implementation (from vendor A) aligns
structure
> > members to 1 byte boundaries, but whose C implementation (from
vendor B)
> > aligns structure members to 8 byte boundaries.  In this case there
would be
> > certain (POD) structure types that can be defined in the C++
language
> > implementation that cannot be described in the C language
implementation.
>
> In what sense does vendor A's implementation "provide for linkage to
> functions written in the C programming language" as it's required to
do?

This is the point various ones of us have been making: what is
required is that vendor A's implementation accept the linkage
specification 'extern "C"'.  It is _not_ required to provide link
or runtime compatibility with _any_ C implementation.  There is
no way the C++ Standard could make such a requirement.  There
might not even be a C implementation on the platform targeted by
a particular vendor's C++ implementation.  Or the C implementation
might make it unreasonably difficult to accommodate the linkage.
Or there might be several incompatible implementations; the
Standard doesn't impose a requirement in such a case that the
C++ implementation pick one to be compatible with, much less that
it be compatible with all of them.  There's also no requirement
that compatibility, if provided, be a binary function, i.e., that
_every_ declaration be compatible if _any_ declaration is
compatible.

The only thing the Standard requires is that, if such a linkage
is provided, the syntax used to specify that linkage be as
specified and that it be documented.  Because of the historic
circumstances of C++ (derived from C, originally implemented as
a translator to C, and run on Unix systems where the interface
to the operating system was in the form of C function calls),
the Committee felt justified in requiring that 'extern "C"' be
accepted and giving it some required semantics.  But it was
explicitly recognized at the time that the requirements could
only be for the C++ semantics of 'extern "C"' declarations and
that nothing could be required of a C++ implementation beyond
documenting what, if any, degree of compatibility it was
providing with coresident C implementations.

To put it another way, it's entirely up to the C++ implementor
to determine whether compatibility with a given implementation
of a given language is technically and economically feasible
and, if so, the degree of that compatibility.  The requirement
that 'Every implementation shall provide for linkage to functions
written in the C programming linkage,  "C"', simply requires that
the translator not reject programs containing that linkage
specification.  It says nothing about the link- and run-time
effects of such a declaration (outside the C++ part of the program,
I mean); that is beyond the scope of a C++ standard.

Perhaps you're misreading the wording here.  This wording was
intended to mean two things:

1) Every implementation must accept  "C" as the string-literal
in a linkage-specification.

2) The meaning of "C" in a linkage-specification is the C
programming language (as opposed to Pascal, Objective-C, etc.).

That's all it was intended to mean, not that the implementation
actually had to permit calling any/all functions compiled by
any/all C implementations on the particular platform.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau <comeau@panix.com> wrote:

> >What is the "intersection of object types in the two languages such
> >that the types in the intersection have the same layout"?
>
> Whatever the C++ compilers documents it to be.

I see that valid implementation-defined behavior includes "not at all"
except where stricter requirements (e.g. int ranges) are imposed by the
standard.

So, the required documentation here may say only "not possible", or even
nothing at all, even where more substantial documentation is all that's
necessary to make it possible.

That makes
> >>> Every implementation shall provide for linkage to functions
> >>> written in the C programming language, "C",
>
> Indeed it's a requirement, but what's important is what
> the implications of the requirement are/mean.

clearer, too: "shall provide for" then means "shall not, through action
or inaction within its responsibility, prevent" - it's not required to
provide a C compiler, but if it doesn't it is then required not to
prevent - even through lack of documentation in this case - linkage with
some other?

===
> C++ can't dictate "whether" some other language has linkage, nor can it
> document how the other language/its implementation does its linkage.

Please note I never thought or implied it could. The example I gave was
a language that "can implement *all* linkage conventions and layouts".
Such a language is delivered with every machine...

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ebkns8.17zwtl81llz4e8N%jthill@telus.net>,
  jthill@telus.net (Jim Hill) wrote:
> This question came up because someone asked about empty-base layout.
The
> standard doesn't require it, and where it describes the possibility it
> leaves it unspecified, so by a plain reading it is unspecified.
>
> But: 7.5p9 says
> > Linkage from C++ to objects defined in other languages and to
objects
> > defined in C++ from other languages is implementation-defined and
> > language-dependent. Only where the object layout strategies of two
> > language implementations are similar enough can such linkage be
achieved.
>
> Now, all implementations are required to provide C linkage, and C is,
in
> every case I've been able to imagine so far, capable of expressing any
> actual layout a C++ compiler might generate. That's "similar enough"
to
> achieve linkage, in plain English, and the standard doesn't say it
means
> anything different.
>
> By that argument all C++ implementations must document even non-POD
> layouts.

This is a non-sequitur.  There is no requirement that _all_
object types (or even _any_ object types) be compatible across
a given language linkage.  In fact, there's no requirement
that there be any degree of compatibility with functions, only
that you be permitted to use "C" and "C++" as the literals in
a linkage specification.  To state otherwise would be a
requirement that a C++ implementation must come with its own
C implementation or interface with some existing C
implementation on the target platform.  We didn't want to say
that a standalone C++ implementation was ipso facto
nonconforming.

It would be perfectly conforming for an implementation to
document that the storage layout is compatible with the
XYZ C compiler for any declaration that is acceptable to both
compilers and incompatible for every other declaration.

To answer the question in the title, "similar enough" means
that there is a non-empty intersection of the object types
in the two languages such that the types in the intersection
have the same layout.  If there are _some_ types that can be
passed back and forth, a language linkage can make sense.
Otherwise, it does not.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<wmm@fastdial.net> wrote:

> There is no requirement that _all_ object types (or even _any_
> object types) be compatible across a given language linkage.

I didn't say there was. But, since you evidently think I did, that
explains "non sequitur".

> only that you be permitted to use "C" and "C++" as the literals
> in a linkage specification.

This is incorrect, even if we were talking about compatibility:
further requirements include:

>> Every implementation shall provide for linkage to functions
>> written in the C programming language, "C",

and
>> The meaning of the string-literal is implementation-defined
in, for instance, `extern "C" foo bar` and `extern "C++" foo baz`.

> To answer the question in the title, "similar enough" means
> that there is a non-empty intersection of the object types
> in the two languages such that the types in the intersection
> have the same layout.

I may be missing something here, but it seems to me this paragraph
supports an even stronger position than I was worried about:

Let's completely forget extern "C" for the moment and focus on
extern "C++", and consider a simple example to start with:

struct foo { foo(){}; int fooi; }
int bar(foo);

Now: I have some hypothetical language I want to use to call bar().
This language can implement *all* linkage conventions and layouts.

What is the "intersection of object types in the two languages such
that the types in the intersection have the same layout"?

For those object types, "linkage is ... implementation-defined":
every implementation "shall document it". If it said "whether
linkage is supported, and if so how invoked" I wouldn't be worried.
But it says "linkage".

I hope my point is clearer now. I see the committee meant to
require ~unspecified except to the extent required for C linkage~.
I happened to recall 7.5 while thinking about it. I wondered, and
now begin to doubt, whether the standard as written doesn't require
more.

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ebt8e4.1g0zw5v5m4l34N%jthill@telus.net>,
  jthill@telus.net (Jim Hill) wrote:
> <wmm@fastdial.net> wrote:
>
> > There is no requirement that _all_ object types (or even _any_
> > object types) be compatible across a given language linkage.
>
> I didn't say there was. But, since you evidently think I did, that
> explains "non sequitur".

You were arguing, at least as far as I understood, that the
capability to write a declaration in C that reflected the
internal layout of non-POD classes somehow placed a
compatibility requirement on C++ implementations.  That's
not true.  The fact that you can write

        extern "C" X x;

(which is required by the Standard) in no way obligates an
implementation to document the layout of X or to make the
layout of X compatible with any given C implementation.
This is strictly a quality-of-implementation issue, to be
decided by the marketplace.  Presumably, all other things
being equal, people would prefer an implementation in
which a wide range of types "X" are compatible with some
C compiler over one with a narrow -- or nonexistent --
range of compatible types.  As long as the implementation
documents the meaning of "C" linkage (which documentation
might consist of the single line, "Linkage is not supported
for any existing C implementation"), whatever it does with
type compatibility is irrelevant to whether it conforms to
the Standard.

> > only that you be permitted to use "C" and "C++" as the literals
> > in a linkage specification.
>
> This is incorrect, even if we were talking about compatibility:
> further requirements include:
>
> >> Every implementation shall provide for linkage to functions
> >> written in the C programming language, "C",

Which, in context, means that you can use "C" as the literal
in a linkage specification.  Period.  It's true that there
are other implications for entities declared with "C" linkage,
such as only allowing one function of a given name to have
"C" linkage, but these are (of necessity) all requirements of
how those entities are used in C++.  The meaning with respect
to using those entities in conjunction with any given C
implementation (including whether it's possible at all) is
implementation-defined, as you point out:

> and
> >> The meaning of the string-literal is implementation-defined
> in, for instance, `extern "C" foo bar` and `extern "C++" foo baz`.
>
> > To answer the question in the title, "similar enough" means
> > that there is a non-empty intersection of the object types
> > in the two languages such that the types in the intersection
> > have the same layout.
>
> I may be missing something here, but it seems to me this paragraph
> supports an even stronger position than I was worried about:
>
> Let's completely forget extern "C" for the moment and focus on
> extern "C++", and consider a simple example to start with:
>
> struct foo { foo(){}; int fooi; }
> int bar(foo);
>
> Now: I have some hypothetical language I want to use to call bar().
> This language can implement *all* linkage conventions and layouts.
>
> What is the "intersection of object types in the two languages such
> that the types in the intersection have the same layout"?

Whatever the C++ implementation chooses it to be.  The
capabilities of the other language are irrelevant.

To take an extreme example, consider an interpretive C++
implementation.  For reasons of error checking and debugging,
it might choose to represent _all_ data types, including
even built-in types such as integers, as an index into a
non-exported table of descriptor/address pairs, with the
real data elsewhere.  As long as the interpreter correctly
implements all the semantics of C++, there is no requirement
that it document any of this mechanism or allow any given
C implementation access to it, even though it is required
to permit "C" linkage.

The point is that an implementation is free to choose the
representation of data types in any way it sees fit.  If
they choose representations for a reasonable-sized subset
of the data types such that there is a "natural"
correspondence with data types in some other language, it
may make sense for the C++ implementation to support
linkage to that other language.  If so, the implementation
is required to document that correspondence.  It is not
required that the implementation provide the linkage, and
if it is provided, it is not required that every data type
be permitted to cross that linkage.  (It should be noted
also in passing that the linkage is really with some
particular implementation(s) of that other language, not
with the language in general.  For instance, the ABC C
compiler might use IEEE floating point and the XYZ C
compiler might use some other floating point representation.
A C++ implementation might allow "C" linkage with both
of them, but presumably would only support use of floating
point with one or the other.)

> For those object types, "linkage is ... implementation-defined":
> every implementation "shall document it". If it said "whether
> linkage is supported, and if so how invoked" I wouldn't be worried.
> But it says "linkage".
>
> I hope my point is clearer now. I see the committee meant to
> require ~unspecified except to the extent required for C linkage~.
> I happened to recall 7.5 while thinking about it. I wondered, and
> now begin to doubt, whether the standard as written doesn't require
> more.

I'm sorry, but I really don't understand what you're getting
at here.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1ebt8e4.1g0zw5v5m4l34N%jthill@telus.net>,
Jim Hill <jthill@telus.net> wrote:
><wmm@fastdial.net> wrote:
>> There is no requirement that _all_ object types (or even _any_
>> object types) be compatible across a given language linkage.
>...
>> only that you be permitted to use "C" and "C++" as the literals
>> in a linkage specification.
>
>This is incorrect,

As a general statement:  there is much less said in this section
of the Standard than people often say there is.

>even if we were talking about compatibility:
>further requirements include:
>
>>> Every implementation shall provide for linkage to functions
>>> written in the C programming language, "C",

Indeed it's a requirement, but what's important is what
the implications of the requirement are/mean.

>...
>struct foo { foo(){}; int fooi; }
>int bar(foo);
>
>Now: I have some hypothetical language I want to use to call bar().
>This language can implement *all* linkage conventions and layouts.
>
>What is the "intersection of object types in the two languages such
>that the types in the intersection have the same layout"?

Whatever the C++ compilers documents it to be.  Of course, it just
can't make stuff up or force something that can't be possible.

>For those object types, "linkage is ... implementation-defined":
>every implementation "shall document it". If it said "whether
>linkage is supported, and if so how invoked" I wouldn't be worried.
>But it says "linkage".

But C++ does support linkage for some of its names, therefore it's
talking about linkage of those names with other languages.  C++ can't
dictate "whether" some other language has linkage, nor can it
document how the other language/its implementation does its linkage.
It can however say what it's going to do about it for itself
if it knows of any other language.

>I hope my point is clearer now. I see the committee meant to
>require ~unspecified except to the extent required for C linkage~.
>I happened to recall 7.5 while thinking about it. I wondered, and
>now begin to doubt, whether the standard as written doesn't require
>more.

As in my first comment above: It doesn't.
A linkage specification is but a `fighting chance'.
Can't be much else, so nothing more needs to be said or implied
in the standard.  This is so even for C linkage.
Heck, not even everything is said for C++ to C++ linkage.

- Greg
--
Comeau Computing, Producers of Comeau C/C++ 4.2.42 (4.2.43 BETA starting)
Try Comeau C++ online at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This question came up because someone asked about empty-base layout. The
standard doesn't require it, and where it describes the possibility it
leaves it unspecified, so by a plain reading it is unspecified.

But: 7.5p9 says
> Linkage from C++ to objects defined in other languages and to objects
> defined in C++ from other languages is implementation-defined and
> language-dependent. Only where the object layout strategies of two
> language implementations are similar enough can such linkage be achieved.

Now, all implementations are required to provide C linkage, and C is, in
every case I've been able to imagine so far, capable of expressing any
actual layout a C++ compiler might generate. That's "similar enough" to
achieve linkage, in plain English, and the standard doesn't say it means
anything different.

By that argument all C++ implementations must document even non-POD
layouts.

So, which is it?

Jim

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]