In article <873f7ae8.0106110058.4e17be5d@posting.google.com>, Kiril
Avdeiv <kavdeiv@mail.ru> writes
>void qsort(void* base, size_t nelem, size_t size,
>  int (*cmp)(const void* e1, const void* e2));
>
>cmp -- should the argument corresponding to this parameter be a
>pointer to a "C++" or "C" function? The answer is, I guess, it is
>unspecified. How can I then portably partake of such functions?

Not at all, it is fully specified. If I write

extern "C" void qsort(void* base, size_t nelem, size_t size,
int (*cmp)(void const *, void const * ));

cmp is a pointer to a C linkage function. If I want it to be a pointer
to a C++ linkage function I have to write something like this (I am
sleep deprived at the moment so do not promise the code is exactly
right)


extern "C++" {
typedef int (*cmpcpp)(void const *, void const *);
}

now cmp is a typename for a C++ linkage pointer to C++ linkage function

now:

extern "C" void qsort(void* base, size_t nelem, size_t size,
int (*cmpcpp)(void const *, void const * ));


qsort takes a pointer to a c++ linkage function

As it is possible to overload on the linkage of a function pointer there
are quite a few variations available.



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

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

Michael Rubenstein <mike@mrubenstein.com> wrote in message news:<ur3aitkblepqfuoc6stjgh3p7ousgorn2l@4ax.com>...
> On Mon, 11 Jun 2001 17:12:35 GMT, kavdeiv@mail.ru (Kiril Avdeiv)
> wrote:
>
> >"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B21538B.375EC02D@wizard.net>...
> >> Kiril Avdeiv wrote:
> >> ...
> >> > James, can you please also explain if there should be any difference
> >> > in the language linkage for names introduced by <cstdlib> and
> >> > <stdlib.h> like headers? Chapter 17 touches on that, but the
> >> > explanation is not intelligible.
> >>
> >> 17.4.2.2: "It is unspecified whether a name from the Standard library
> >> declared with external linkage has either extern "C" or extern "C++"
> >> linkage."
> >>
> >> Therefore, we can't know which linkage any such name has. However, at
> >> least the use of the term "unspecified" clues us in that these two
> >> linkages are the only possibility - neither atoi() nor std::atoi() may
> >> have extern "FORTRAN" linkage, for instance. However, that still leaves
> >> open the question of whether the unknown linkage must be the same for
> >> each of the two different ways of accessing the function.
> >>
> >> Per Annex D.5p2: "Each C header, whose name has the form name.h, behaves
> >> as if each name placed in the Standard library namespace by the
> >> corresponding cname header is also placed within the namespace scope of
> >> the name-space std and is followed by an explicit using-declaration
> >> (7.3.3)."
> >>
> >> 7.3.3p1: "A _using-declaration_ introduces a name into the declarative
> >> region in which the _using-declaration_ appears. That name is a synonym
> >> for the name of some entity declared elsewhere."
> >>
> >> Since it's supposed to be a synonym, as a practical matter it must have
> >> the same language linkage, because the language linkage of a function
> >> determines how that name is passed to the linker, and the language
> >> linkage of a function type determines the calling convention to be used
> >> when calling it. Discrepancies of either type would cause serious
> >> problems. So, is it possible for such a discrepancy to even be created?
> >>
> >> The syntax for a using-declaration provides no way to directly specify a
> >> new language linkage for the name being declared. However, an
> >> implementation could do the following:
> >>
> >> namespace std {
> >>  int atoi(const char*); // defaults to extern "C++"
> >> }
> >>
> >> extern "C" {
> >>  using std::atoi; // Linkage changed ?!
> >> }
> >>
> >> 7.5p4: "... In a _linkage-specification_, the specified language linkage
> >> applies to the function types of all function declarators, function
> >> names, and variable name introduced by the declaration(s)."
> >>
> >> Since the using-directive introduces a function name into the
> >> linkage-specification, such a using-declaration woulds indeed change the
> >> linkage. However,
> >>
> >> 7.5p5: "If two declarations of the same function or object specify
> >> different _linkage-specification_s ... the program is ill-formed if the
> >> declarations appear in the same translation unit...". Since the two
> >> names must be synonyms, they're declarations of the same function.
> >> Therefore, it would not be legal for such a using-declaration to be
> >> created. Since these headers must behave as if a using-declaration was
> >> used, they can't create a situation such as this that could not be
> >> created with a legal using-declaration.
> >>
> >> Conclusion: they must both have the same unknown linkage. You can find
> >> out which one by specializing a template for function pointer types of
> >> different linkages.
> >
> >James, a very big thank you for your exhaustive explanation!
> >
> >I, however, see a shortcoming in the lattitude granted by the Standard
> >and explained in your article. Given that function types also have a
> >languaged linkage, and the fact that the C standard library has quite
> >a number of functions that take pointers to functions as their
> >arguments, it becomes unclear as to a pointer to function with which
> >linkage ("C" or "C++") is, for example, qsort supposed to take.
> >
> >void qsort(void* base, size_t nelem, size_t size,
> >  int (*cmp)(const void* e1, const void* e2));
> >
> >cmp -- should the argument corresponding to this parameter be a
> >pointer to a "C++" or "C" function? The answer is, I guess, it is
> >unspecified. How can I then portably partake of such functions?
>
> Not unspecified.  The stnadard requires (25.4) that both extern
> "C" and extern "C++" versions of qsort and bsearch be provided in
> the library.

Thanks a lot. Now it is clear.

Kiril

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

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message news:<pax$ajBnoZJ7EwJ5@ntlworld.com>...
> In article <873f7ae8.0106110058.4e17be5d@posting.google.com>, Kiril
> Avdeiv <kavdeiv@mail.ru> writes
> >void qsort(void* base, size_t nelem, size_t size,
> >  int (*cmp)(const void* e1, const void* e2));
> >
> >cmp -- should the argument corresponding to this parameter be a
> >pointer to a "C++" or "C" function? The answer is, I guess, it is
> >unspecified. How can I then portably partake of such functions?
>
> Not at all, it is fully specified. If I write
>
> extern "C" void qsort(void* base, size_t nelem, size_t size,
> int (*cmp)(void const *, void const * ));
>
> cmp is a pointer to a C linkage function. If I want it to be a pointer
> to a C++ linkage function I have to write something like this (I am
> sleep deprived at the moment so do not promise the code is exactly
> right)
>
>
> extern "C++" {
> typedef int (*cmpcpp)(void const *, void const *);
> }
>
> now cmp is a typename for a C++ linkage pointer to C++ linkage function
>
> now:
>
> extern "C" void qsort(void* base, size_t nelem, size_t size,
> int (*cmpcpp)(void const *, void const * ));
>
>
> qsort takes a pointer to a c++ linkage function
>
> As it is possible to overload on the linkage of a function pointer there
> are quite a few variations available.

Francis, thank you.

I did know it is possible to overload on the language linkage of a pointer to function.

Kiril

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

In article <remove.haberg-1006011135150001@du128-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>If furthermore, one can achieve that effect without adding new keywords
>(as you suggest), that would be to be preferred.

Actually, I view these as new keywords, just ones that cannot possibly
conflict with anything in existing code.


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

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

In article <dk4SFhAGM3I7EwkD@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>If furthermore, one can achieve that effect without adding new keywords
>>(as you suggest), that would be to be preferred.
>
>Actually, I view these as new keywords, just ones that cannot possibly
>conflict with anything in existing code.

It depends: If you suggest "~using", and it is not possible to write "~
using", then I figure that would be a new keyword. But your suggestion
"!using" would not be a new keyword if one is allowed to write "! using",
as both "!" and "using" are recognized tokens.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

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

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B21538B.375EC02D@wizard.net>...
> Kiril Avdeiv wrote:
> ...
> > James, can you please also explain if there should be any difference
> > in the language linkage for names introduced by <cstdlib> and
> > <stdlib.h> like headers? Chapter 17 touches on that, but the
> > explanation is not intelligible.
>
> 17.4.2.2: "It is unspecified whether a name from the Standard library
> declared with external linkage has either extern "C" or extern "C++"
> linkage."
>
> Therefore, we can't know which linkage any such name has. However, at
> least the use of the term "unspecified" clues us in that these two
> linkages are the only possibility - neither atoi() nor std::atoi() may
> have extern "FORTRAN" linkage, for instance. However, that still leaves
> open the question of whether the unknown linkage must be the same for
> each of the two different ways of accessing the function.
>
> Per Annex D.5p2: "Each C header, whose name has the form name.h, behaves
> as if each name placed in the Standard library namespace by the
> corresponding cname header is also placed within the namespace scope of
> the name-space std and is followed by an explicit using-declaration
> (7.3.3)."
>
> 7.3.3p1: "A _using-declaration_ introduces a name into the declarative
> region in which the _using-declaration_ appears. That name is a synonym
> for the name of some entity declared elsewhere."
>
> Since it's supposed to be a synonym, as a practical matter it must have
> the same language linkage, because the language linkage of a function
> determines how that name is passed to the linker, and the language
> linkage of a function type determines the calling convention to be used
> when calling it. Discrepancies of either type would cause serious
> problems. So, is it possible for such a discrepancy to even be created?
>
> The syntax for a using-declaration provides no way to directly specify a
> new language linkage for the name being declared. However, an
> implementation could do the following:
>
> namespace std {
>  int atoi(const char*); // defaults to extern "C++"
> }
>
> extern "C" {
>  using std::atoi; // Linkage changed ?!
> }
>
> 7.5p4: "... In a _linkage-specification_, the specified language linkage
> applies to the function types of all function declarators, function
> names, and variable name introduced by the declaration(s)."
>
> Since the using-directive introduces a function name into the
> linkage-specification, such a using-declaration woulds indeed change the
> linkage. However,
>
> 7.5p5: "If two declarations of the same function or object specify
> different _linkage-specification_s ... the program is ill-formed if the
> declarations appear in the same translation unit...". Since the two
> names must be synonyms, they're declarations of the same function.
> Therefore, it would not be legal for such a using-declaration to be
> created. Since these headers must behave as if a using-declaration was
> used, they can't create a situation such as this that could not be
> created with a legal using-declaration.
>
> Conclusion: they must both have the same unknown linkage. You can find
> out which one by specializing a template for function pointer types of
> different linkages.

James, a very big thank you for your exhaustive explanation!

I, however, see a shortcoming in the lattitude granted by the Standard
and explained in your article. Given that function types also have a
languaged linkage, and the fact that the C standard library has quite
a number of functions that take pointers to functions as their
arguments, it becomes unclear as to a pointer to function with which
linkage ("C" or "C++") is, for example, qsort supposed to take.

void qsort(void* base, size_t nelem, size_t size,
  int (*cmp)(const void* e1, const void* e2));

cmp -- should the argument corresponding to this parameter be a
pointer to a "C++" or "C" function? The answer is, I guess, it is
unspecified. How can I then portably partake of such functions?


Many Thanks
Kiril

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

On Mon, 11 Jun 2001 17:12:35 GMT, kavdeiv@mail.ru (Kiril Avdeiv)
wrote:

>"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B21538B.375EC02D@wizard.net>...
>> Kiril Avdeiv wrote:
>> ...
>> > James, can you please also explain if there should be any difference
>> > in the language linkage for names introduced by <cstdlib> and
>> > <stdlib.h> like headers? Chapter 17 touches on that, but the
>> > explanation is not intelligible.
>>
>> 17.4.2.2: "It is unspecified whether a name from the Standard library
>> declared with external linkage has either extern "C" or extern "C++"
>> linkage."
>>
>> Therefore, we can't know which linkage any such name has. However, at
>> least the use of the term "unspecified" clues us in that these two
>> linkages are the only possibility - neither atoi() nor std::atoi() may
>> have extern "FORTRAN" linkage, for instance. However, that still leaves
>> open the question of whether the unknown linkage must be the same for
>> each of the two different ways of accessing the function.
>>
>> Per Annex D.5p2: "Each C header, whose name has the form name.h, behaves
>> as if each name placed in the Standard library namespace by the
>> corresponding cname header is also placed within the namespace scope of
>> the name-space std and is followed by an explicit using-declaration
>> (7.3.3)."
>>
>> 7.3.3p1: "A _using-declaration_ introduces a name into the declarative
>> region in which the _using-declaration_ appears. That name is a synonym
>> for the name of some entity declared elsewhere."
>>
>> Since it's supposed to be a synonym, as a practical matter it must have
>> the same language linkage, because the language linkage of a function
>> determines how that name is passed to the linker, and the language
>> linkage of a function type determines the calling convention to be used
>> when calling it. Discrepancies of either type would cause serious
>> problems. So, is it possible for such a discrepancy to even be created?
>>
>> The syntax for a using-declaration provides no way to directly specify a
>> new language linkage for the name being declared. However, an
>> implementation could do the following:
>>
>> namespace std {
>>  int atoi(const char*); // defaults to extern "C++"
>> }
>>
>> extern "C" {
>>  using std::atoi; // Linkage changed ?!
>> }
>>
>> 7.5p4: "... In a _linkage-specification_, the specified language linkage
>> applies to the function types of all function declarators, function
>> names, and variable name introduced by the declaration(s)."
>>
>> Since the using-directive introduces a function name into the
>> linkage-specification, such a using-declaration woulds indeed change the
>> linkage. However,
>>
>> 7.5p5: "If two declarations of the same function or object specify
>> different _linkage-specification_s ... the program is ill-formed if the
>> declarations appear in the same translation unit...". Since the two
>> names must be synonyms, they're declarations of the same function.
>> Therefore, it would not be legal for such a using-declaration to be
>> created. Since these headers must behave as if a using-declaration was
>> used, they can't create a situation such as this that could not be
>> created with a legal using-declaration.
>>
>> Conclusion: they must both have the same unknown linkage. You can find
>> out which one by specializing a template for function pointer types of
>> different linkages.
>
>James, a very big thank you for your exhaustive explanation!
>
>I, however, see a shortcoming in the lattitude granted by the Standard
>and explained in your article. Given that function types also have a
>languaged linkage, and the fact that the C standard library has quite
>a number of functions that take pointers to functions as their
>arguments, it becomes unclear as to a pointer to function with which
>linkage ("C" or "C++") is, for example, qsort supposed to take.
>
>void qsort(void* base, size_t nelem, size_t size,
>  int (*cmp)(const void* e1, const void* e2));
>
>cmp -- should the argument corresponding to this parameter be a
>pointer to a "C++" or "C" function? The answer is, I guess, it is
>unspecified. How can I then portably partake of such functions?

Not unspecified.  The stnadard requires (25.4) that both extern
"C" and extern "C++" versions of qsort and bsearch be provided in
the library.
--
Michael M Rubenstein


======================================= MODERATOR'S COMMENT:
 Please don't overquote.

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

In article <873f7ae8.0106120700.7092a4a1@posting.google.com>, Kiril
Avdeiv <kavdeiv@mail.ru> writes
>Francis, thank you.
>
>I did know it is possible to overload on the language linkage of a pointer to
>function.

Well you can blame me and Josee Lajoie (when she represented IBM)
because we were the main protagonists in making that change to the
language in 1995-6


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

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

On Thu, 7 Jun 2001, Bjarne Stroustrup wrote:
>
> > What is the "correct" way to implement the
> > C subset of C++ in regard to namespaces?
>
> The correct way (note the absence of quotes) is for <cstdio> to put names
> in namespace std (only) and for <stdio.h> to put names in the global
> namespace (only). Similar for the other C standard library headers.

But that's not what the C++ standard says in section D.5:

"Each C header, whose name has the form name.h, behaves as if each
name placed in the Standard library namespace by the corresponding
cname header is also placed within the namespace scope of the
namespace std and is followed by an explicit using-declaration."

The example that follows this paragraph makes it clear that
<stdio.h> (for example) must put all the standard non-macro names
in <cstdio> both in namespace std and in the global namespace.

---
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://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> In article <GEKLCz.88C@research.att.com>, bs@research.att.com (Bjarne
> Stroustrup) wrote:
> >> What is the "correct" way to implement the
> >> C subset of C++ in regard to namespaces?
> >
> >The correct way (note the absence of quotes) is for <cstdio> to put names
> >in namespace std (only) and for <stdio.h> to put names in the global
> >namespace (only). Similar for the other C standard library headers.
>
> Are you sure about this? -- The standard D.5:2 says:
>   Each C header, whose name has the form name.h, behaves as if each name placed
>   in the Standard library namespace by the corresponding cname header is also
>   placed within the namespace scope of the name-space std and is followed by an
>   explicit using-declaration (7.3.3).
>
> And 7.3.3 describes how apply a "using" to each name, and not the whole
> namespace std.
>
> So it looks as though the .h header should merely add a "using" to every
> C++ name in the corresponding C compatibility header without a ".h".

Just recently I wrote "However, with no disparagement intended, the
standard
itself now supersedes him [Stroustrup] as a trusted source. If he says
one thing, and the standard says another, it's the standard that's
right, by definition." I didn't expect to see an example so soon,
however :-).

> "Matthew Darwin" <mattsjunkemail@yahoo.com> wrote:
> >> I've been using predominantly Metrowerks C
> >> (MSL C) and it wraps the C subset in namespace
> >> std along with the standard C++ library.  This means
> >> that if you don't want to introduce namespace std
>
> With respect to this, the Metrowerks copy I have does the first part
> correctly (putting all names within namespace std), but adds a "using
> namespace std" in the .h header instead of one for each name, which should
> be wrong according to the quote above.

That's a fairly common but mistaken implementation. It has the advantage
of being a lot simpler than what's actually required.

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

In article <3B20009B.AF754DDC@wizard.net>, James Kuyper Jr.
<kuyper@wizard.net> wrote:

| > With respect to this, the Metrowerks copy I have does the first part
| > correctly (putting all names within namespace std), but adds a "using
| > namespace std" in the .h header instead of one for each name, which should
| > be wrong according to the quote above.
|
| That's a fairly common but mistaken implementation. It has the advantage
| of being a lot simpler than what's actually required.

Metrowerks CodeWarrior Pro 6 (shipped Sep' 2000) no longer uses the
using directive, but individual using directives.

--
Howard Hinnant
Metrowerks

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

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B20009B.AF754DDC@wizard.net>...
> Hans Aberg wrote:
> >
> > In article <GEKLCz.88C@research.att.com>, bs@research.att.com (Bjarne
> > Stroustrup) wrote:
> > >> What is the "correct" way to implement the
> > >> C subset of C++ in regard to namespaces?
> > >
> > >The correct way (note the absence of quotes) is for <cstdio> to put names
> > >in namespace std (only) and for <stdio.h> to put names in the global
> > >namespace (only). Similar for the other C standard library headers.
> >
> > Are you sure about this? -- The standard D.5:2 says:
> >   Each C header, whose name has the form name.h, behaves as if each name placed
> >   in the Standard library namespace by the corresponding cname header is also
> >   placed within the namespace scope of the name-space std and is followed by an
> >   explicit using-declaration (7.3.3).
> >
> > And 7.3.3 describes how apply a "using" to each name, and not the whole
> > namespace std.
> >
> > So it looks as though the .h header should merely add a "using" to every
> > C++ name in the corresponding C compatibility header without a ".h".
>
> Just recently I wrote "However, with no disparagement intended, the
> standard
> itself now supersedes him [Stroustrup] as a trusted source. If he says
> one thing, and the standard says another, it's the standard that's
> right, by definition." I didn't expect to see an example so soon,
> however :-).

James, can you please also explain if there should be any difference
in the language linkage for names introduced by <cstdlib> and
<stdlib.h> like headers? Chapter 17 touches on that, but the
explanation is not intelligible.

Thank you
Kiril

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

Kiril Avdeiv wrote:
...
> James, can you please also explain if there should be any difference
> in the language linkage for names introduced by <cstdlib> and
> <stdlib.h> like headers? Chapter 17 touches on that, but the
> explanation is not intelligible.

17.4.2.2: "It is unspecified whether a name from the Standard library
declared with external linkage has either extern "C" or extern "C++"
linkage."

Therefore, we can't know which linkage any such name has. However, at
least the use of the term "unspecified" clues us in that these two
linkages are the only possibility - neither atoi() nor std::atoi() may
have extern "FORTRAN" linkage, for instance. However, that still leaves
open the question of whether the unknown linkage must be the same for
each of the two different ways of accessing the function.

Per Annex D.5p2: "Each C header, whose name has the form name.h, behaves
as if each name placed in the Standard library namespace by the
corresponding cname header is also placed within the namespace scope of
the name-space std and is followed by an explicit using-declaration
(7.3.3)."

7.3.3p1: "A _using-declaration_ introduces a name into the declarative
region in which the _using-declaration_ appears. That name is a synonym
for the name of some entity declared elsewhere."

Since it's supposed to be a synonym, as a practical matter it must have
the same language linkage, because the language linkage of a function
determines how that name is passed to the linker, and the language
linkage of a function type determines the calling convention to be used
when calling it. Discrepancies of either type would cause serious
problems. So, is it possible for such a discrepancy to even be created?

The syntax for a using-declaration provides no way to directly specify a
new language linkage for the name being declared. However, an
implementation could do the following:

namespace std {
 int atoi(const char*); // defaults to extern "C++"
}

extern "C" {
 using std::atoi; // Linkage changed ?!
}

7.5p4: "... In a _linkage-specification_, the specified language linkage
applies to the function types of all function declarators, function
names, and variable name introduced by the declaration(s)."

Since the using-directive introduces a function name into the
linkage-specification, such a using-declaration woulds indeed change the
linkage. However,

7.5p5: "If two declarations of the same function or object specify
different _linkage-specification_s ... the program is ill-formed if the
declarations appear in the same translation unit...". Since the two
names must be synonyms, they're declarations of the same function.
Therefore, it would not be legal for such a using-declaration to be
created. Since these headers must behave as if a using-declaration was
used, they can't create a situation such as this that could not be
created with a legal using-declaration.

Conclusion: they must both have the same unknown linkage. You can find
out which one by specializing a template for function pointer types of
different linkages.

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

In article <3B20009B.AF754DDC@wizard.net>, "James Kuyper Jr."
<kuyper@wizard.net> wrote:
>Just recently I wrote "However, with no disparagement intended, the
>standard
>itself now supersedes him [Stroustrup] as a trusted source. If he says
>one thing, and the standard says another, it's the standard that's
>right, by definition." I didn't expect to see an example so soon,
>however :-).

C++ is a tricky language. :-)

The reason I happened to bother about the silly little detail :-) at hand,
was as follows:

The GMP (GNU Multi-Precision numerical library) has a header gmp.h that
even though written for include from C++, it also includes itself a C
compatibility  .h header.

Thus one gets stuck with global "using" directives on std names that
cannot be removed.

This seems to be a flaw of C++: One would want to be able to add say
  not_using namespace std;
at the end of the gmp.h header, cancelling all "using" directives on std
names that earlier were added globally. Then when including the gmp.h
header, it will appears as not adding any "using" directives to any std
names.

Another construct that might be added to might be say
  rename <name1> = <name2>;
introducing the name <name1> but cancelling the name <name2>. The compiler
could sort out that the name that should be passed to the linker is still
<name2>.

Then one might start eliminating the need for the preprocessor.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

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

In article <873f7ae8.0106080128.16ca2630@posting.google.com>, Kiril
Avdeiv <kavdeiv@mail.ru> writes
>James, can you please also explain if there should be any difference
>in the language linkage for names introduced by <cstdlib> and
><stdlib.h> like headers? Chapter 17 touches on that, but the
>explanation is not intelligible.

No there should be no difference. IOWs I should be able to use
<stdlib.h> in one TU and <cstdlib> in another and the same items will be
used from the library.

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

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

Bjarne Stroustrup wrote:
...
> Someone took the opportunity to lecture on the topic of only the standard
> being authoritative (and not I). Please note that I have never, after the
> formation of the C++ standards committee, claimed that my writings take
> priority over the standard drafts.

I plead Guilty.

It was someone else, not you, who cited you as the C++ authority in
another thread. I responded to that claim. I was only talking
theoretically, and I'd thought that an example was unlikely to occur. If
one did occcur, I'd expected that it would be about some very obscure or
controversial topic, not something like this. So I was amused that it
did happen that way, and so soon after my earlier message, and couldn't
resist saying "I told you so". I'm sorry - I meant no offense or
criticism of you. We all make such silly mistakes from time to time,
myself at least as often as anyone else.

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

In article <remove.haberg-0906010014220001@du129-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>he GMP (GNU Multi-Precision numerical library) has a header gmp.h that
>even though written for include from C++, it also includes itself a C
>compatibility  .h header.
>
>Thus one gets stuck with global "using" directives on std names that
>cannot be removed.
>
>This seems to be a flaw of C++: One would want to be able to add say
>  not_using namespace std;
>at the end of the gmp.h header, cancelling all "using" directives on std
>names that earlier were added globally. Then when including the gmp.h
>header, it will appears as not adding any "using" directives to any std
>names.

The only difference I have with you is in the spelling of the implicitly
proposed new keyword. I am increasingly of the belief that adding either
~using or !using to the language would add benefits, not least in being
able to undo such awkward decisions as the one you quote.


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

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

In article <m8AcDLAl9fI7EwDK@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>This seems to be a flaw of C++: One would want to be able to add say
>>  not_using namespace std;
>>at the end of the gmp.h header, cancelling all "using" directives on std
>>names that earlier were added globally. Then when including the gmp.h
>>header, it will appears as not adding any "using" directives to any std
>>names.
>
>The only difference I have with you is in the spelling of the implicitly
>proposed new keyword. I am increasingly of the belief that adding either
>~using or !using to the language would add benefits, not least in being
>able to undo such awkward decisions as the one you quote.

Of course, I do not care about the actual spelling -- only that one should
be able to cancel such an effect.

If furthermore, one can achieve that effect without adding new keywords
(as you suggest), that would be to be preferred.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

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

What is the "correct" way to implement the
C subset of C++ in regard to namespaces?

I've been using predominantly Metrowerks C
(MSL C) and it wraps the C subset in namespace
std along with the standard C++ library.  This means
that if you don't want to introduce namespace std
you can do things like
   std::memcpy(...)
or
   std::fabs(...)
or even
   typedef stdtime std::time_t;

Microsoft's compilers don't seem to allow this -
C stuff has to be plain C, especially for things that
MSVC++ implements as macro's such as min(), max(), and
abs().  (Unfortunately this seems to also mean that
some standard <algorithm> facilities are completely
stepped on in MSVC++).

Having recently ported some code from MSL C to gcc-compatable
headers in MacOS X I found that the latter also does _not_
support wrapping C functions and types in namespace std,
though at least it doesn't step on std algorithm methods.

Does the C++ standard specify whether or not the C subset
is supposed to be in the std namespace?  I didn't see
mention of this in Stroustrup or any FAQ.

Thanks,
Christopher

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

Christopher Corbell wrote:
>
> What is the "correct" way to implement the
> C subset of C++ in regard to namespaces?
>
> I've been using predominantly Metrowerks C
> (MSL C) and it wraps the C subset in namespace
> std along with the standard C++ library.  This means
> that if you don't want to introduce namespace std
> you can do things like
>    std::memcpy(...)
> or
>    std::fabs(...)
> or even
>    typedef stdtime std::time_t;
>
> Microsoft's compilers don't seem to allow this -
> C stuff has to be plain C, especially for things that
> MSVC++ implements as macro's such as min(), max(), and
> abs().  (Unfortunately this seems to also mean that
> some standard <algorithm> facilities are completely
> stepped on in MSVC++).

If you #include <cstdio.h> most of the symbols it defines are in
namespace std (the macros are the main exception, since macros don't
respect name spaces). If you #include <stdio.h>, those symbols are
placed in namespace std::, but are also made available in the global
namespace, as-if by a using-directive. If that's not how MSVC++ does
things, then it's non-conforming (which isn't exactly news).

> Having recently ported some code from MSL C to gcc-compatable
> headers in MacOS X I found that the latter also does _not_
> support wrapping C functions and types in namespace std,
> though at least it doesn't step on std algorithm methods.

User code isn't supposed to intrude on namespace std, except by
specializing standard templates for cases where at least one template
parameter depends upon a user-defined type.

> Does the C++ standard specify whether or not the C subset
> is supposed to be in the std namespace?  I didn't see
> mention of this in Stroustrup or any FAQ.

Yes. For <cname> headers, it's covered in section 17.4.1.2p4; for
<name.h> headers it's covered inAnnex D.5p2.

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

"James Kuyper Jr." wrote:
>
> If you #include <cstdio.h> most of the symbols it defines are in
> namespace std (the macros are the main exception, since macros don't
> respect name spaces).

There's a mostly harmless typo above: James means <cstdio>,
not <cstdio.h>.

-- James Dennett

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

In article <GEKLCz.88C@research.att.com>, bs@research.att.com (Bjarne
Stroustrup) wrote:
>> What is the "correct" way to implement the
>> C subset of C++ in regard to namespaces?
>
>The correct way (note the absence of quotes) is for <cstdio> to put names
>in namespace std (only) and for <stdio.h> to put names in the global
>namespace (only). Similar for the other C standard library headers.

Are you sure about this? -- The standard D.5:2 says:
  Each C header, whose name has the form name.h, behaves as if each name placed
  in the Standard library namespace by the corresponding cname header is also
  placed within the namespace scope of the name-space std and is followed by an
  explicit using-declaration (7.3.3).

And 7.3.3 describes how apply a "using" to each name, and not the whole
namespace std.

So it looks as though the .h header should merely add a "using" to every
C++ name in the corresponding C compatibility header without a ".h".

"Matthew Darwin" <mattsjunkemail@yahoo.com> wrote:
>> I've been using predominantly Metrowerks C
>> (MSL C) and it wraps the C subset in namespace
>> std along with the standard C++ library.  This means
>> that if you don't want to introduce namespace std

With respect to this, the Metrowerks copy I have does the first part
correctly (putting all names within namespace std), but adds a "using
namespace std" in the .h header instead of one for each name, which should
be wrong according to the quote above.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

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