kanze wrote:
> Vladimir Marko wrote:
> > kanze wrote:
> > > No, but they are allowed to declare them 'extern "C"'.  And
> > > while formally not yet allowed, they usually also declare them
> > > in the global namespace.
>
> > According to 17.4.3.1.3/4,
> >     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.
>
> > So it's perfectly legal for an implementation to declare
> >     extern "C" std::size_t strlen(const char*);
> > in the global namespace.
>
> Just not in the <c...> headers.

OK, may be not in <c...> headers. But it doesn't matter at all.
AFAICT the implementation is free to provide the declaration
before you #include any headers whatsoever (just like the
mandatory "::operator new(size_t)"). At least according to _my_
interpretation of the phrase "reserved to the implementation".

Then again, does it really matter if the declaration is visible
before you #include anything or only after some #include?
Programs which do not depend on implementation details won't
care anyway.

Vladimir Marko

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

The dangers and inadequacies of macros are well known.

Viable substitutes like "typedef", "enum", templates and global const
variables are preferable.

Namespaces also give us more freedom as to what names we can use
ourselves.


The C++ Standard explicitly lists all of its keywords. However, I think
it would be helpful if it also gave a list of all the macros it
defines... thus providing an exhaustive list of "names" which we simply
can't use in C++.


For instance, the following program won't compile for me:

    #include <climits>

    void Func( int CHAR_BIT ) {}

    int main(){}



I have another example, reproduced below. If memory serves me right, I
did at one time have a compiler which wouldn't compile it. Do you think
it should compile? It's based on creating our own function called
"strlen".

#include <cstddef>

#include <cstring>

std::size_t strlen( const char* p )
{
    std::size_t len = -1; /* Max value */

    while ( ++len, *p++ );

    return len;
}

#include <iostream>
using std::cout;

#include <cstdlib>

int main()
{
    cout << strlen("Hello") << '\n';

    cout << std::strlen("Hello") << '\n';

    system("PAUSE");
}


We're in trouble with the above code if the STL version of strlen is a
macro.

So... to summarise, I think it would be helpful to have an exhaustive
list of all the macros which a compliant C++ compiler may define (except
of course for the ones with leading underscores).


--

Frederick Gotham

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
news:Xns97E8BFFB8B436fgothamNOSPAM@194.125.133.14...

> The dangers and inadequacies of macros are well known.

As are their uses.

> Viable substitutes like "typedef", "enum", templates and global const
> variables are preferable.

When possible, yes.

> Namespaces also give us more freedom as to what names we can use
> ourselves.

Except for library defined macros, yes. So don't try to reuse setjmp
or errno 'cause they're still macros.

> The C++ Standard explicitly lists all of its keywords. However, I think
> it would be helpful if it also gave a list of all the macros it
> defines... thus providing an exhaustive list of "names" which we simply
> can't use in C++.

See the index page of the Dinkum Compleat Libraries Reference
at our web site. It shows *all* the names defined in Standard C,
Standard C++, and the four TRs (including TR1). Prudence dictates
that you avoid all these.

> For instance, the following program won't compile for me:
>
>    #include <climits>
>
>    void Func( int CHAR_BIT ) {}
>
>    int main(){}

And it is *extremely* foolish of you to use a name written in all
caps that begins with CHAR_, knowing the propensity of the C and
C++ Standards to define such names. (If nothing else, you mislead
future readers.) It is also moderately foolish to use all caps for
anything but a macro name.

> I have another example, reproduced below. If memory serves me right, I
> did at one time have a compiler which wouldn't compile it. Do you think
> it should compile? It's based on creating our own function called
> "strlen".
>
> #include <cstddef>
>
> #include <cstring>
>
> std::size_t strlen( const char* p )
> {
>    std::size_t len = -1; /* Max value */
>
>    while ( ++len, *p++ );
>
>    return len;
> }
>
> #include <iostream>
> using std::cout;
>
> #include <cstdlib>
>
> int main()
> {
>    cout << strlen("Hello") << '\n';
>
>    cout << std::strlen("Hello") << '\n';
>
>    system("PAUSE");
> }
>
>
> We're in trouble with the above code if the STL version of strlen is a
> macro.

Well, that's not supposed to happen, because the C++ Standard disallows
the use of masking macros for library function names. Nevertheless,
many implementations still supply those macros. Even absent any masking
macro, many implementations define strlen in the global namespace even
when you include a <c*> header. (That's so commonplace it'll likely
be blessed as conforming in the next revision of the C++ Standard.) But
on top of all that, you still don't know the linkage of the strlen defined
by the Standard C++ library. So your program is trebly foolish to push its
luck in this area.

> So... to summarise, I think it would be helpful to have an exhaustive
> list of all the macros which a compliant C++ compiler may define (except
> of course for the ones with leading underscores).

Why omit those? _IOFBF, _IOLBF, and _IONBF are part of the external
interface to both the Standard C and C++ libraries.

P.J. Plauger
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://www.comeaucomputing.com/csc/faq.html                      ]

"Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
news:Xns97E8BFFB8B436fgothamNOSPAM@194.125.133.14...
[...]
>
> The C++ Standard explicitly lists all of its keywords. However, I think
> it would be helpful if it also gave a list of all the macros it
> defines... thus providing an exhaustive list of "names" which we simply
> can't use in C++.

C++ Standard does identify reserved names in 17.4.3.1, and many other macros are
included from C by reference.

[...]
>
> I have another example, reproduced below. If memory serves me right, I
> did at one time have a compiler which wouldn't compile it. Do you think
> it should compile? It's based on creating our own function called
> "strlen".
>
> #include <cstddef>
>
> #include <cstring>
>
> std::size_t strlen( const char* p )
> {
>    std::size_t len = -1; /* Max value */
>
>    while ( ++len, *p++ );
>
>    return len;
> }

It should compile, the two functions are in different namespaces. Just need to
remember that ADL may create unexpected customization points when parameters are
UDTs. Also if your functions are exposed in the libraries it may create problems
for some users that have a nasty habit of opening all namespaces with "using
directive."

>
> We're in trouble with the above code if the STL version of strlen is a
> macro.

Standard library is not allowed to redefine standard C functions as macros.

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Gene Bushuyev" wrote:
> "Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
> news:Xns97E8BFFB8B436fgothamNOSPAM@194.125.133.14...

> [...]

> > I have another example, reproduced below. If memory serves
> > me right, I did at one time have a compiler which wouldn't
> > compile it.  Do you think it should compile?  It's based on
> > creating our own function called "strlen".

> > #include <cstddef>
> > #include <cstring>

> > std::size_t strlen( const char* p )
> > {
> >    std::size_t len = -1; /* Max value */
> >    while ( ++len, *p++ );
> >    return len;
> > }

> It should compile, the two functions are in different
> namespaces.

That's the theory.  In most implementations, they aren't, and I
think that C++0x will no longer require that they be.

I think it should compile.  Linking it with an application isn't
guaranteed to work, however.  And if the link succeeds, the
program might not have the behavior you want.

> Just need to remember that ADL may create unexpected
> customization points when parameters are UDTs. Also if your
> functions are exposed in the libraries it may create problems
> for some users that have a nasty habit of opening all
> namespaces with "using directive."

It's trickier than that here.  <cstring> very likely contains
something like:

    extern "C" std::size_t strlen( const char* p ) ;

In which case, if the implementation has actually declared
strlen in the global namespace (usually the case), his
definition is the definition of the "C" function.  (See    7.5/6.)
Given the way most linkers work, his definition will be used
instead of the one in the standard library.

Now modify the code to return len - 1, and watch the fun
begin:-).

> > We're in trouble with the above code if the STL version of
> > strlen is a macro.

> Standard library is not allowed to redefine standard C
> functions as macros.

No, but they are allowed to declare them 'extern "C"'.  And
while formally not yet allowed, they usually also declare them
in the global namespace.

As a matter of principle, I would avoid any global function with
a name starting with either str or is, followed by a small
letter.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> "Gene Bushuyev" wrote:
> > "Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
> [...]
> > > We're in trouble with the above code if the STL version of
> > > strlen is a macro.
>
> > Standard library is not allowed to redefine standard C
> > functions as macros.
>
> No, but they are allowed to declare them 'extern "C"'.  And
> while formally not yet allowed, they usually also declare them
> in the global namespace.

According to 17.4.3.1.3/4,
    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.

So it's perfectly legal for an implementation to declare
    extern "C" std::size_t strlen(const char*);
in the global namespace.

Vladimir Marko

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Vladimir Marko wrote:
> kanze wrote:
> > "Gene Bushuyev" wrote:
> > > "Frederick Gotham" <fgothamNO@SPAM.com> wrote in message
> > [...]
> > > > We're in trouble with the above code if the STL version of
> > > > strlen is a macro.

> > > Standard library is not allowed to redefine standard C
> > > functions as macros.

> > No, but they are allowed to declare them 'extern "C"'.  And
> > while formally not yet allowed, they usually also declare them
> > in the global namespace.

> According to 17.4.3.1.3/4,
>     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.

> So it's perfectly legal for an implementation to declare
>     extern "C" std::size_t strlen(const char*);
> in the global namespace.

Just not in the <c...> headers.

In practice, I think it will be allowed to do so in the <c...>
headers.  And in practice, even now, the fact that an
implementation is allowed to declare them as 'extern "C"' means
that in practice, at least at the link level, std::strcpy and
::strcpy refer in fact to the same function.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]