In article <73vemu$1c2$1@engnews2.Eng.Sun.COM>,
Steve Clamage <stephen.clamage@sun.com> wrote:
>
>Here are two simple solutions that require no overhead:
>
>1. Define, for example, the C++-linkage function std::cos to be an
>external symbol that has the same address as function cos in the C
>library. ...
>
>2. If the C library functions are declared to have C linkage, there
>is no problem to solve. ...

I do not think these mechanisms are actually standards conforming.  As I
understand it, the C++ library is not allowed to "pollute" the global
namespace.  That is, a user is allowed to, for example, define a function
::cos, without it interfering with any calls to std::cos elsewhere (especially
elsewhere in the library).  The user's ::cos must be treated as distinct from
std::cos.

Now, I think some sort of "weak" symbols might do the job, but compliance here
certainly is non-trivial if one wants backwards compatibility.



[ 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              ]

stanley@West.sun.com (Stanley Friesen [Contractor]) writes:

>In article <73vemu$1c2$1@engnews2.Eng.Sun.COM>,
>Steve Clamage <stephen.clamage@sun.com> wrote:
>>
>>Here are two simple solutions that require no overhead:
>>
>>1. Define, for example, the C++-linkage function std::cos to be an
>>external symbol that has the same address as function cos in the C
>>library. ...
>>
>>2. If the C library functions are declared to have C linkage, there
>>is no problem to solve. ...

>I do not think these mechanisms are actually standards conforming.  As I
>understand it, the C++ library is not allowed to "pollute" the global
>namespace.

True, but the C library is explcitly incorporated into the C++
standard. See 17.3.1.4.

>That is, a user is allowed to, for example, define a function
>::cos, without it interfering with any calls to std::cos elsewhere (especially
>elsewhere in the library).  The user's ::cos must be treated as distinct from
>std::cos.

No. See 17.4.3.1.3, which says in part:

"Each name from the Standard C library declared with external linkage
is reserved to the implementation for use as a name with extern "C"
linkage, 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <749o8n$8lr@abyss.West.Sun.COM>,
  stanley@West.sun.com (Stanley Friesen [Contractor]) wrote:
>
> In article <73vemu$1c2$1@engnews2.Eng.Sun.COM>,
> Steve Clamage <stephen.clamage@sun.com> wrote:
> >
> >Here are two simple solutions that require no overhead:
> >
> >1. Define, for example, the C++-linkage function std::cos to be an
> >external symbol that has the same address as function cos in the C
> >library. ...
> >
> >2. If the C library functions are declared to have C linkage, there
> >is no problem to solve. ...
>
> I do not think these mechanisms are actually standards conforming.  As I
> understand it, the C++ library is not allowed to "pollute" the global
> namespace.  That is, a user is allowed to, for example, define a function
> ::cos, without it interfering with any calls to std::cos elsewhere
(especially
> elsewhere in the library).  The user's ::cos must be treated as distinct from
> std::cos.
>
> Now, I think some sort of "weak" symbols might do the job, but compliance
here
> certainly is non-trivial if one wants backwards compatibility.

There can be only one extern "C" function with any particular name. For
instance,  namespace abc {  extern "C" double sin(double);  }; namespace def
{  extern "C" void sin(int); // Error, can't overload extern "C" functions
};  namespace ghi {  double sin(double); // Okay, and distinct from
abc::sin(double)  }  namespace jkl {  extern "C" double sin(double); //
jkl::sin is same as abc::sin  };

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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 <hinnant-0112981327200001@isdn3-17.lightlink.com>,
  hinnant@_anti-spam_lightlink.com (Howard Hinnant) wrote:
>
> In article <3663EF43.43A6C7CF@acm.org>, Pete Becker <petebecker@acm.org>
wrote:
>
> > Most implementations mangle names to reflect their heritage, so the sin
> > function that you get from "using std::sin();" has a different name from
> > the ordinary "sin" function. If the C++ library is hosted on a normal C
> > library this difference in names has to be fixed.
>
> extern "C" names are not mangled (at the object code level), even if they
> appear in a namespace.

Name mangling is an implementation detail, not required anywhere in
the standard. The goal was to allow C++ names to work properly with
older linkers. It seems to me that there's no reason a modern linker
couldn't accept the name "std::sin(double)" as a valid name.

It seems to me that the absolute WORST impact this could have on
compiler vendors would be a rewrite of the linker, plus perhaps a
conversion utility or two (old-format OBJ to new-format and
possibly back again.) But even that shouldn't usually be needed;
just make sure that the compiler allows colens in it's external
names. Now bump the object-file version number, and be sure to
UN-mangle names in older object files. Viola!

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

AllanW@my-dejanews.com wrote:
>
> In article <hinnant-0112981327200001@isdn3-17.lightlink.com>,
>   hinnant@_anti-spam_lightlink.com (Howard Hinnant) wrote:
> >
> > In article <3663EF43.43A6C7CF@acm.org>, Pete Becker <petebecker@acm.org>
> wrote:
> >
> > > Most implementations mangle names to reflect their heritage, so the sin
> > > function that you get from "using std::sin();" has a different name from
> > > the ordinary "sin" function. If the C++ library is hosted on a normal C
> > > library this difference in names has to be fixed.
> >
> > extern "C" names are not mangled (at the object code level), even if they
> > appear in a namespace.
>
> Name mangling is an implementation detail, not required anywhere in
> the standard. The goal was to allow C++ names to work properly with
> older linkers. It seems to me that there's no reason a modern linker
> couldn't accept the name "std::sin(double)" as a valid name.

Yes, but this does not answer the question that I was replying to.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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              ]

Howard Hinnant wrote:
>
> In article <3663EF43.43A6C7CF@acm.org>, Pete Becker <petebecker@acm.org> wrote:
>
> > Most implementations mangle names to reflect their heritage, so the sin
> > function that you get from "using std::sin();" has a different name from
> > the ordinary "sin" function. If the C++ library is hosted on a normal C
> > library this difference in names has to be fixed.
>
> extern "C" names are not mangled (at the object code level), even if they
> appear in a namespace.

Yes, that is true. It doesn't answer the question which I was replying
to, however.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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              ]

James Kuyper wrote:
>
> Does this require anything special? Wouldn't "using std::sin();" in the
> global namespace in <math.h> do the job? I rather thought that this was
> the intended implementation.
>

This message raises a question about the difference between using
directives and declarations.  The quote above suggests that math.h could
be written as:
  namespace std {
    double sin(double);
  }
  using std::sin;

On the other hand, Stroustrup (3d ed, p. 203) apparently would write
math.h as:

  namespace std {
    double sin(double);
  }
  using namespace std;

Are these equivalent as far as the name 'sin' is concerned?  My
understanding is that they are subtly different.  In particular, there
would be an observable difference if the program additionally had
declarations:
  namespace Other {
    double sin(double);
  }
  using Other::sin;

Which is the standard-conforming way to write math.h?

Thanks,
Steve Vavasis


[ 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              ]

Stephen Vavasis <vavasis@cs.cornell.edu> writes:

>This message raises a question about the difference between using
>directives and declarations.  The quote above suggests that math.h could
>be written as:
>  namespace std {
>    double sin(double);
>  }
>  using std::sin;

>On the other hand, Stroustrup (3d ed, p. 203) apparently would write
>math.h as:

>  namespace std {
>    double sin(double);
>  }
>  using namespace std;

I hope that was corrected in a later printing, or appears in
his list of corrections. The standard forbids that particular
implementation.  Example:
 #include <stdio> // no ".h"
 #include <math.h>
 // the stdio decls must not be in the global namespace
 int printf = 0;
The sample math.h breaks this valid (if foolish) program.

>Are these equivalent as far as the name 'sin' is concerned?  My
>understanding is that they are subtly different.

The differences are subtle, but don't normally cause a problem.
But if you have the same name in multiple namespaces, you have to
be careful about using-directives vs using-declarations.

The using-directive makes all the names in the namespace visible.
The using-declaration declares the particular name explicily in
the current namespace.

>Which is the standard-conforming way to write math.h?

You need a using-declaration, or something equivalent.
(Compiler magic is allowed; the standard says "as if" via a
using-declaration.)

--
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              ]

Stephen Vavasis wrote:
 >
 > James Kuyper wrote:
 > >
 > > Does this require anything special? Wouldn't "using std::sin();" in the
 > > global namespace in <math.h> do the job? I rather thought that this was
 > > the intended implementation.
 > >
 >
 > This message raises a question about the difference between using
 > directives and declarations.  The quote above suggests that math.h could
 > be written as:
 >   namespace std {
 >     double sin(double);
 >   }
 >   using std::sin;
 >
 > On the other hand, Stroustrup (3d ed, p. 203) apparently would write
 > math.h as:
 >
 >   namespace std {
 >     double sin(double);
 >   }
 >   using namespace std;
 >
 > Are these equivalent as far as the name 'sin' is concerned?  My
 > understanding is that they are subtly different.  In particular, there
 > would be an observable difference if the program additionally had
 > declarations:
 >   namespace Other {
 >     double sin(double);
 >   }
 >   using Other::sin;
 >
 > Which is the standard-conforming way to write math.h?

Annex D, section 5 says that "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."


[ 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              ]

James Kuyper wrote:
>
>
> > This probably requires the compiler to know that the standard
> > library names are special (perhaps because their declarations are
> > tagged with a special #pragma, or perhaps because the 'std::' prefix
> > is handled specially by the compiler/linker).
>
> Does this require anything special? Wouldn't "using std::sin();" in the
> global namespace in <math.h> do the job? I rather thought that this was
> the intended implementation.

Most implementations mangle names to reflect their heritage, so the sin
function that you get from "using std::sin();" has a different name from
the ordinary "sin" function. If the C++ library is hosted on a normal C
library this difference in names has to be fixed.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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 <3663EF43.43A6C7CF@acm.org>, Pete Becker <petebecker@acm.org> wrote:

> Most implementations mangle names to reflect their heritage, so the sin
> function that you get from "using std::sin();" has a different name from
> the ordinary "sin" function. If the C++ library is hosted on a normal C
> library this difference in names has to be fixed.

extern "C" names are not mangled (at the object code level), even if they
appear in a namespace.

-Howard


[ 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 <36632889.3A2C@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> How do/will implementors provide the
> standard library names, usable from both C and C++ programs?
>
> I see a few possibilities (there may be others):
>
> 1. Provide two versions of each library function; thus the runtime
>  library contains ::sin() for C and <math.h>, and std::sin() for
>  C++ and <cmath>.
>
> This has the possible disadvantage of code duplication, unless the
> vendor can manage to provide two entry symbols for the same code
> segment (which can be done easily in assembler, but is impossible
> in C/C++).

No, it isn't impossible in C/C++. It's impossible in portable C/C++,
but it's easy enough for the compiler vendor to allow herself a
hook and/or use non-portable techniques.
    double std::sin(double arg) {
        _asm { label sin } // Additional name for same function
        // ... code to implement sin
    }
OR
    double std::sin(double arg) {
        // ... code to implement sin
    }
    #pragma symbol sin = std::sin

> On the other hand, some vendors may provide two separate
> runtime libraries, one for C and the other for C++, to make other
> linking issues simpler, so this might not be a bad approach.

Two libraries would be a bad idea. We might mix C code that calls
printf() with C++ code that calls std::printf(). We wouldn't want
two copies of printf() in the execuable image!

> 2. Provide two versions of each library function, which both do
>  nothing more than call the "real" function underneath; thus ::sin()
>  and std::sin() are two separate functions in the library that
>  simply call a third function (which could be named something like
>  __sin()).

More specifically, provide two versions of the function; one is the
"real" function, and the other is a jump to the first. But this
requires the compiler vendor to "play favorites." Which one is the
"real" function? The other one is at least marginally slower.

> This suffers from possible performance overhead of an extra function
> call.  In practice, the extra call can be rewritten as a single JUMP
> instruction in assembler, so the overhead wouldn't be too severe
> (except for extra virtual memory page faults).
>
> 3. Provide one version of each library function; thus ::sin() and
>  std::sin() are actually the same function.
>
> This probably requires the compiler to know that the standard
> library names are special (perhaps because their declarations are
> tagged with a special #pragma, or perhaps because the 'std::' prefix
> is handled specially by the compiler/linker).

Unless they are able to provide two symbols for one library function,
as in #1 above.

4. Implement namespaces as non-standard extensions in C. (Conceivably
   these aren't even documented -- the header files aren't guaranteed
   to be readable in C) Then the header files do the same thing in C
   that they do in C++ -- the cXXX versions define it in namespace std
   only, and the XXX.H versions define it in both namespace std and in
   global space. Assuming that the compiler also allows //-style
   comments in C, which is quite common, the standard header files
   might look like:

       // <cmath>
       #ifndef __INCLUDE_CMATH
       #define __INCLUDE_CMATH
       #ifndef __CPLUSPLUS
           #pragma warnings(NamespaceInC,push,off) // Turn off this warning
       #endif
       namespace std {
       #ifndef __CPLUSPLUS
           #pragma warnings(NamespaceInC,pop) // Restore to previous state
       #endif

           double sin(double angle);
           // ... etc ...

       };
       #endif // __INCLUDE_CMATH



       // <math.h>
       #ifndef __INCLUDE_MATH_H
       #define __INCLUDE_MATH_H
       #include <cmath>
       #ifndef __CPLUSPLUS
           #pragma warnings(UsingInC,push,off) // Turn off this warning
       #endif

       using std::sin(double); // Defined for C
       // ... etc ...

       #ifndef __CPLUSPLUS
           #pragma warnings(UsingInC,pop) // Restore to previous state
       #endif
       #endif // __INCLUDE_MATH_H

   Portable C programs will #include <math.h>, which includes cmath
   (to define the symbols in namespace std) and then makes them
   globally visible with using directives. Since the portable C
   programs know nothing about std or any other namespace, there is
   no conflict.

   Portable C++ programs have the usual choice: #include <math.h> and
   get the same results, or #include <cmath> and get the symbols in
   namespace std only.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

Howard Hinnant wrote:

> In article <3663EF43.43A6C7CF@acm.org>, Pete Becker <petebecker@acm.org> wrote:

> > Most implementations mangle names to reflect their heritage, so the sin
> > function that you get from "using std::sin();" has a different name from
> > the ordinary "sin" function. If the C++ library is hosted on a normal C
> > library this difference in names has to be fixed.
>
> extern "C" names are not mangled (at the object code level), even if they
> appear in a namespace.

But implementors are encouraged to make them C++ names, not
extern C names

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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              ]

Valentin Bonnard <bonnardv@pratique.fr> writes:

>Howard Hinnant wrote:
>
>> In article <3663EF43.43A6C7CF@acm.org>, Pete Becker <petebecker@acm.org> wrote:
>
>> > Most implementations mangle names to reflect their heritage, so the sin
>> > function that you get from "using std::sin();" has a different name from
>> > the ordinary "sin" function. If the C++ library is hosted on a normal C
>> > library this difference in names has to be fixed.
>>
>> extern "C" names are not mangled (at the object code level), even if they
>> appear in a namespace.

>But implementors are encouraged to make them C++ names, not
>extern C names

There is no problem here. The C++ header <math> must contain
a declaration for sin in the global namespace and in namespace
std. There are many ways to get from that requirement to an
efficient implementation. Examples:

1. Give both declarations "C" linkage. Both declarations then
refer to the same function.

2. Give one or both of the declarations C++ linkage.
2.1. Provide two implementations, possibly via an inline forwarding
function.
2.2. Use linker magic to get the names to refer to the same function.
2.3  Create multiple entry points to the same function with the
different names.
2.4  Create an entry point that just jumps to the "real" function
for the "extra" declaration.

All of these are simple to do on most systems. The implementer
can choose whatever combination of these or other methods makes
the most sense.

--
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              ]

Valentin Bonnard wrote:

> Francis Glassborow wrote:

> > I have a distinct recollection that at the last London meeting of WG21 &
> > J16 there was a compromise wording to strongly encourage implementors to
> > place C standard library functions in std:: but without actually
> > requiring it.  I cannot find that wording in the Standard.
>
> s/place C standard library functions in std::/make C standard library
> functions extern "C++"

That's a little cryptic: not everyone's familiar with vi-style editing
commands. I'll translate - "s/a/b/" means replace 'a' with 'b'.


[ 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              ]

James Kuyper wrote:
> From Section 17.4.1.2, p4:
> "In the C++ Standard Library, however, the declarations and
> definitions (except for names which are defined as macros in C) are
> within namespace scope (3.3.5) of namespace std."
>
> This only applies to <c*> headers, such as <cmath>. If you #include
> <math.h>, the names should be defined both in the global namespace and
> in namespace std, per appendix D.5.

Which brings up a question: How do/will implementors provide the
standard library names, usable from both C and C++ programs?

I see a few possibilities (there may be others):

1. Provide two versions of each library function; thus the runtime
 library contains ::sin() for C and <math.h>, and std::sin() for
 C++ and <cmath>.

This has the possible disadvantage of code duplication, unless the
vendor can manage to provide two entry symbols for the same code
segment (which can be done easily in assembler, but is impossible
in C/C++).  On the other hand, some vendors may provide two separate
runtime libraries, one for C and the other for C++, to make other
linking issues simpler, so this might not be a bad approach.

2. Provide two versions of each library function, which both do
 nothing more than call the "real" function underneath; thus ::sin()
 and std::sin() are two separate functions in the library that
 simply call a third function (which could be named something like
 __sin()).

This suffers from possible performance overhead of an extra function
call.  In practice, the extra call can be rewritten as a single JUMP
instruction in assembler, so the overhead wouldn't be too severe
(except for extra virtual memory page faults).

3. Provide one version of each library function; thus ::sin() and
 std::sin() are actually the same function.

This probably requires the compiler to know that the standard
library names are special (perhaps because their declarations are
tagged with a special #pragma, or perhaps because the 'std::' prefix
is handled specially by the compiler/linker).

-- David R. Tribble, dtribble@technologist.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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:


>James Kuyper wrote:
>> From Section 17.4.1.2, p4:
>> "In the C++ Standard Library, however, the declarations and
>> definitions (except for names which are defined as macros in C) are
>> within namespace scope (3.3.5) of namespace std."
>>
>> This only applies to <c*> headers, such as <cmath>. If you #include
>> <math.h>, the names should be defined both in the global namespace and
>> in namespace std, per appendix D.5.

>Which brings up a question: How do/will implementors provide the
>standard library names, usable from both C and C++ programs?

Here are two simple solutions that require no overhead:

1. Define, for example, the C++-linkage function std::cos to be an
external symbol that has the same address as function cos in the C
library. Most systems provide some mechanism for aliasing symbols
at link time, and this solution works if C and C++ functions have
the same calling sequence. But solution 2 is even simpler.

2. If the C library functions are declared to have C linkage, there
is no problem to solve. The name of an object or function with
C linkage in namespace scope is defined by the C++ standard to
represent the same entity declared in global scope. Example:

 extern "C" double cos(double);
 extern "C" int errno;
 namespace std {
     extern "C" double cos(double);
     extern "C" int errno;
 }

Whether you call ::cos or std::cos, you get the same function.
Whether you refer to ::errno or std::errno, you get the same object.

--
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              ]

Steve Clamage<stephen.clamage@sun.com> wrote:
 >David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
 >>James Kuyper wrote:
 >>> From Section 17.4.1.2, p4:
 >>> "In the C++ Standard Library, however, the declarations and
 >>> definitions (except for names which are defined as macros in C) are
 >>> within namespace scope (3.3.5) of namespace std."
 >>>
 >>> This only applies to <c*> headers, such as <cmath>. If you #include
 >>> <math.h>, the names should be defined both in the global namespace and
 >>> in namespace std, per appendix D.5.
 >
 >>Which brings up a question: How do/will implementors provide the
 >>standard library names, usable from both C and C++ programs?
 >
 >Here are two simple solutions that require no overhead:
 >
 >1. Define, for example, the C++-linkage function std::cos to be an
 >external symbol that has the same address as function cos in the C
 >library. Most systems provide some mechanism for aliasing symbols
 >at link time, and this solution works if C and C++ functions have
 >the same calling sequence. But solution 2 is even simpler.
 >
 >2. If the C library functions are declared to have C linkage, there
 >is no problem to solve. The name of an object or function with
 >C linkage in namespace scope is defined by the C++ standard to
 >represent the same entity declared in global scope. Example:
 >
 > extern "C" double cos(double);
 > extern "C" int errno;
 > namespace std {
 >     extern "C" double cos(double);
 >     extern "C" int errno;
 > }
 >
 >Whether you call ::cos or std::cos, you get the same function.
 >Whether you refer to ::errno or std::errno, you get the same object.

Of course in the real world it's a bit more complicated, but in
general the ::cos and the std::cos symbols both have to name the
same object.  It's more complicated mainly where C++ overloads
C names, or where the functions take arguments that point to
C library types (e.g. FILE or tm).

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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              ]

David R Tribble wrote:

> James Kuyper wrote:
> > From Section 17.4.1.2, p4:
> > "In the C++ Standard Library, however, the declarations and
> > definitions (except for names which are defined as macros in C) are
> > within namespace scope (3.3.5) of namespace std."

> > This only applies to <c*> headers, such as <cmath>. If you #include
> > <math.h>, the names should be defined both in the global namespace and
> > in namespace std, per appendix D.5.

> Which brings up a question: How do/will implementors provide the
> standard library names, usable from both C and C++ programs?

> I see a few possibilities (there may be others):
....
> 3. Provide one version of each library function; thus ::sin() and
>  std::sin() are actually the same function.

> This probably requires the compiler to know that the standard
> library names are special (perhaps because their declarations are
> tagged with a special #pragma, or perhaps because the 'std::' prefix
> is handled specially by the compiler/linker).

Does this require anything special? Wouldn't "using std::sin();" in the
global namespace in <math.h> do the job? I rather thought that this was
the intended implementation.


[ 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              ]

ncm@nospam.cantrip.org (Nathan Myers) writes:

>Steve Clamage<stephen.clamage@sun.com> wrote:

> >1. Define, for example, the C++-linkage function std::cos to be an
> >external symbol that has the same address as function cos in the C
> >library. Most systems provide some mechanism for aliasing symbols
> >at link time, and this solution works if C and C++ functions have
> >the same calling sequence. But solution 2 is even simpler.
> >
> >2. If the C library functions are declared to have C linkage, there
> >is no problem to solve. The name of an object or function with
> >C linkage in namespace scope is defined by the C++ standard to
> >represent the same entity declared in global scope. Example:
> >
> > extern "C" double cos(double);
> > extern "C" int errno;
> > namespace std {
> >     extern "C" double cos(double);
> >     extern "C" int errno;
> > }
> >
> >Whether you call ::cos or std::cos, you get the same function.
> >Whether you refer to ::errno or std::errno, you get the same object.

>Of course in the real world it's a bit more complicated, but in
>general the ::cos and the std::cos symbols both have to name the
>same object.  It's more complicated mainly where C++ overloads
>C names, or where the functions take arguments that point to
>C library types (e.g. FILE or tm).

It isn't really more complicated.

In Sun C++ we use option 2. If you call std::cos, you get the
ordinary cos function in the C runtime library, the same one
a C program gets when it calls cos. This much just falls out
the the C++ rules for functions and objects declared extern "C".
No extra work is involved.

When C++ overloads C names, as in the two versions of strchr,
there is no problem, because there really are two functions.
You can leave one of them extern "C", and make the other one
an inline C++ function that calls the C function. Or you could
use a linker option to map the mangled name of the C++ function
to the name of the C function.

C types that can get mangled into function names require only
a little extra work.  Taking the FILE type as an example:
 struct __FILE { ... file struct ... };
 namespace std { typedef __FILE FILE; };
 typedef __FILE FILE; // in <stdio.h> only
Any use of FILE or std::FILE refers to __FILE.

The tricky part is trying to use existing C headers as part
of the C++ implementation. Then you have to cope with header
organization that doesn't meet C++ requirements. That's really
a separate subject.

--
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              ]

[posted and mailed]
Stephen Vavasis <vavasis@cs.cornell.edu> wrote:
>Stroustrup (3rd ed., 2nd printing) writes on p. 431:
>
>"A standard header with a name starting with the letter c is equivalent
>to a header in the C standard library.  For every header <cX> defining
>names in the std namespace, there is a header <X.h> defining the same
>names in the global namespace."
>
>These two sentences seem to imply that if I include <cmath>, then
>functions like sqrt, sin, cos, etc. will be in namespace std.  But every
>recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
>these names into the global namespace.  What is the correct behavior?

Stroustrup is correct.  However, these recent compilers have not
yet got their libraries in order, having not yet achieved the
necessary namespace support.

A fully-conforming namespace implementation is only part of the
solution; after that, a way is neeeded to mangle namespaced type
names into function names the same way as the identical global
name.  Some compilers (e.g. the beta Sun & DEC compilers) have a
hack to mangle a handful of specific type names, such as std::tm
and std::lconv, into names of functions that take them as arguments,
as if they were global types.

This isn't a standard requirement, but a practical one.  Users
persist in including C header files in their C++ programs.  C headers
often "forward-declare" standard (as well as non-standard) struct tags
rather than including the defining header.  (C programmers will not
stop this practice on our say-so.)  Without some special support,
a declaration of a function that takes a global tm* might be considered
different from its definition, declared (ultimately) to take a std::tm*.

While there are not many ISO standard types where this is a danger,
there are many other standards that place other types in standard
headers, so the set of such names is not fixed.

A workable solution for implementers would be add a conforming
extension to define a space, akin to 'extern "C"' (and called
perhaps 'extern "C-global"') in which such types could be defined,
where the type names so defined would mangle as if global, but
would scope according to the normal rules of the language, much
like C function names defined in 'namespace "C"'.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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              ]

vavasis@cs.cornell.edu (Stephen Vavasis) wrote:
>
>Stroustrup (3rd ed., 2nd printing) writes on p. 431:
[snip]
>These two sentences seem to imply that if I include <cmath>, then
>functions like sqrt, sin, cos, etc. will be in namespace std.  But every
>recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
>these names into the global namespace.  What is the correct behavior?

Stephen Vavasis wrote:
>
> Stroustrup (3rd ed., 2nd printing) writes on p. 431:
>
> "A standard header with a name starting with the letter c is equivalent
> to a header in the C standard library.  For every header <cX> defining
> names in the std namespace, there is a header <X.h> defining the same
> names in the global namespace."
>
> These two sentences seem to imply that if I include <cmath>, then
> functions like sqrt, sin, cos, etc. will be in namespace std.  But every
> recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
> these names into the global namespace.  What is the correct behavior?

In article <3661CD36.61ED@cs.cornell.edu>, Stephen Vavasis
<vavasis@cs.cornell.edu> writes
>"A standard header with a name starting with the letter c is equivalent
>to a header in the C standard library.  For every header <cX> defining
>names in the std namespace, there is a header <X.h> defining the same
>names in the global namespace."
>
>These two sentences seem to imply that if I include <cmath>, then
>functions like sqrt, sin, cos, etc. will be in namespace std.  But every
>recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
>these names into the global namespace.  What is the correct behavior?

I have a distinct recollection that at the last London meeting of WG21 &
J16 there was a compromise wording to strongly encourage implementors to
place C standard library functions in std:: but without actually
requiring it.  I cannot find that wording in the Standard.

17.4.1.2 para 4 seems to require these names to be in the scope of std::


Francis Glassborow      Chair of 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              ]

>>>>> Stephen Vavasis <vavasis@cs.cornell.edu> wrote:

> Stroustrup (3rd ed., 2nd printing) writes on p. 431:
> "A standard header with a name starting with the letter c is equivalent
> to a header in the C standard library.  For every header <cX> defining
> names in the std namespace, there is a header <X.h> defining the same
> names in the global namespace."

> These two sentences seem to imply that if I include <cmath>, then
> functions like sqrt, sin, cos, etc. will be in namespace std.  But every
> recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
> these names into the global namespace.  What is the correct behavior?

As far as I can tell, EGCS does *not* (yet) put C hearders <cX> (and
the C++ Standard Library) in namespace ::std. Of course, that is not
the correct behaviour according to the Standard.


--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr


[ 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              ]

Metrowerks CodeWarrior (mac, windows) puts the C lib into namespace std
(as is standard).

-Howard


[ 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:

> I have a distinct recollection that at the last London meeting of WG21 &
> J16 there was a compromise wording to strongly encourage implementors to
> place C standard library functions in std:: but without actually
> requiring it.  I cannot find that wording in the Standard.

s/place C standard library functions in std::/make C standard library
functions extern "C++"

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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              ]

Stroustrup (3rd ed., 2nd printing) writes on p. 431:

"A standard header with a name starting with the letter c is equivalent
to a header in the C standard library.  For every header <cX> defining
names in the std namespace, there is a header <X.h> defining the same
names in the global namespace."

These two sentences seem to imply that if I include <cmath>, then
functions like sqrt, sin, cos, etc. will be in namespace std.  But every
recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
these names into the global namespace.  What is the correct behavior?

Thanks,
Steve Vavasis (vavasis@cs.cornell.edu)


[ 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              ]

Stephen Vavasis <vavasis@cs.cornell.edu> writes:

>Stroustrup (3rd ed., 2nd printing) writes on p. 431:

>"A standard header with a name starting with the letter c is equivalent
>to a header in the C standard library.  For every header <cX> defining
>names in the std namespace, there is a header <X.h> defining the same
>names in the global namespace."

>These two sentences seem to imply that if I include <cmath>, then
>functions like sqrt, sin, cos, etc. will be in namespace std.  But every
>recent compiler that I have (egcs 1.1, KCC 3.2f, Visual C++ 5.0) puts
>these names into the global namespace.  What is the correct behavior?

The correct behavior is what you found in Stroustrup. The
question is whether a given implementation has yet chosen to
comply with that provision of the standard.

To pick one of your examples, VC++5.0 was shipped before the
standard was complete, at a time when the exact status of the
headers was still under debate. (Stroustup 3rd edition was also
published before the standard was complete, but happens to be
correct on this point.)

Complying in full with all the new header provisions is quite
challenging on some systems. Some implementations have decided
to put off full compiliance with these provisions. The
difficulties lie in implementing the requirements of the
standard while fitting into an existing system without
causing undue breakage.

--
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              ]