Stefan Schwarzer wrote:
>
> I am having trouble to figure out what the standard's rationale is
> by providing .h headers from the C library environment.

Many people on the C++ committee felt that since the non-C features in
the C++ standard library were in namespace std, that the portion of
the library inherited from C should also be in namespace std. Otherwise,
you'd have some library names that must be qualified with std::
and some that must not. (I'm ignoring macros in this discussion.)
Hypothetical example:
 #include <iostream>
 #include <stdio.h>
 cout << "hello";      // error
 printf("hello");      // ok
 std::cout << "hello"; // ok
 std::printf("hello"); // error (hypothetical)
 using std::cout;      // ok
 using std::printf;    // error (hypothetical)

Putting all the names in namespace std provides uniformity, and
also allows the programmer to get all the declarations in the
standard headers out of the global namespace.

You don't have to agree with these arguments, but they are the
primary reasons for what was adopted.

But that change would break every C++ program, since every nontrivial
program uses C headers. It would also be a substantial incompatibility
with C. You would not be able to write a non-trivial C program that
would compile as C++; not even the trivial "hello world" program.
(You would need to use conditional spelling of include directives.)

Consequently, the <name.h> form of the C headers continues to be
recognized in C++ with the same effect as before. If you write
 #include <stdio.h>
you have the same effect in standard C++ as in old C++, and the same
effect as in C. If you like, you can in addition access the identifiers
in the header by qualifying them with "std::". Example:
 #include <stdio.h>
 ...
 printf("hello, ");       // ok
 std::printf("world!\n"); // ok
 using std::printf;       // ok

If you want to move the C library names out of the global namespace, you
can instead use the <cname> version of the C headers. Example:
 #include <cstdio>
 ...
 printf("hello"); // does not refer to std::printf

<digression>
Moving the C library names out of the global namespace is of value
primarily for the names that you DON'T intend to use. The names are still
reserved in the global namespace. But you can avoid accidently finding
a name from the C library when you didn't intend to.
</digression>

The <name.h> form of the C++ headers are listed as "deprecated" features.
That doesn't mean you can't use them. It means only that some future
C++ standard might not contain them. (Note the word "might".) But even
if that day comes to pass, vendors would still yield to the wishes of
their clients and continue to provide the <name.h> forms. So far, no one
has suggested removing the <name.h> form of headers from the next C++
standard.

--
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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <913dfo$4mn$1@infosun2.rus.uni-stuttgart.de>,
Stefan Schwarzer  <sts@boa.ica1.uni-stuttgart.de> wrote:
>I am having trouble to figure out what the standard's rationale is
>by providing .h headers from the C library environment.

1.  There are places where the C function signatures are not (cannot be)
    const correct and/or having multiple flavors of a function would be useful.

    For example, the 'C' strstr

     char *strstr(const char *, const char *)

    can return a char * pointing somewhere within a const char *.

    Both of these options

 char *strstr(char *, const char *);
 const char *strstr(const char *, const char *);

    are const correct and serve useful purposes.

2.  The <name> headers put everything in the std namespace, while
    <name.h> ends up in the global namespace.  Given compiler/platform
    specific extensions in the 'C' <name.h>, using the global namespace
    opens up possibilities for name collisions.  Using the std namespace
    doesn't have this drawback.

3.  The <name.h> form is deprecated.  Eventually, some compilers may
    stop supporting it.

--
<a href="http://www.poohsticks.org/drew/">Home Page</a>
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Stefan Schwarzer" <sts@boa.ica1.uni-stuttgart.de> wrote in message
news:913dfo$4mn$1@infosun2.rus.uni-stuttgart.de...
> I am having trouble to figure out what the standard's rationale is
> by providing .h headers from the C library environment.

Others, with more knowledge than I, have addressed the general philosophical
question.  However you raised some details which are important.

> I'd like to test for error conditions of C library functions.

Because C++ introduces exceptions, there are no guarantees that the library
routines which appear to have the same name as in C, when included into C++,
will set errno in the same way, or at all, except where specifically noted
in the C++ standard.  A problem which should be reported by exception may
only be reported by exception, with errno not being set.  The problems with
errno are well documented.

> Then, again 19.3, says that 'the contents (of cerrno) are the same as
> the Standard C library header <errno.h>'. Shall I thus expect the macro
> definitions present in, say in the platform specific
> /usr/include/errno.h, in <cerrno> as well? And then of course also in
> <errno.h>?

This will depend upon how pedantic your compiler is.  One purpose of C++ is
to do a better job at detecting programming errors than C can, thereby
making programmers more efficient, since the earlier in a development cycle
that errors are detected, the cheaper they are to correct.  Many C++
compilers therefore default to being pedantic, whereas many C compilers
default to ignoring problems, because they need to accept old source code
that was written before standards were introduced.  I know of at least some
implementations which will, by default, exclude everything which is not
defined in the C++ standard from the <cname> headers.  So the answer to your
specific question is "Don't bet on it."

Another philosophical issue is exactly what can be put into the std
namespace.  My belief, although it is not enforced by all compiler vendors,
is that only those names which are defined by the C++ standard as being in
the std namespace should be put into that namespace.  After all it would be
a contradiction in terms to have a non-standard name inside the "standard"
namespace.  On a more detail level future issues of the C++ standard reserve
the right to add additional names into the std namespace, and if your vendor
has previously added something that conflicts then you, the customer, have a
problem.  So if a compiler vendor decided to, for example, add the POSIX
definitions to a <name.h> header, as specified in the POSIX standard, then
those same definitions technically should not be added to the std namespace,
and should not be in the <cname> header.

If you actually look into the headers you will generally find a lot of
#ifdef statements checking for macro names which have been defined by
various standards, or by the compiler vendor.  Defining those macros in your
program will control which definitions are actually included.


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Jim Cobban wrote:
...
> Because C++ introduces exceptions, there are no guarantees that the library
> routines which appear to have the same name as in C, when included into C++,
> will set errno in the same way, or at all, except where specifically noted
> in the C++ standard.  A problem which should be reported by exception may
> only be reported by exception, with errno not being set.  The problems with
> errno are well documented.

17.4.4.8p2: "None of the functions from the Standard C library shall
report an error by throwing an exception, 176) unless it calls a
program-supplied functions that throws an exception. 177)"

Offhand, the only C standard library functions which I can think of
which call a user-supplied function are qsort(), bsearch(), signal(),
and exit() (through atexit()). Note that 18.7p3 makes it undefined
behavior for a signal handler to throw an exception. However, the
standard provides defined behavior for exceptions thrown by that
mechanism from any of the other three functions.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I am having trouble to figure out what the standard's rationale is
by providing .h headers from the C library environment. Example:
I'd like to test for error conditions of C library functions,

#include <errno.h>

// ...
if ( errno == EBUSY ) // do something
// ...

Now, according to D.5 [depr.c.headers], there is a header errno.h supplied
by the C++ standard library, which basically pulls the contents of <cerrno>
into the global namespace. So fine so good: according to 19.3, the only
things that seem to be required to be in cerrno are the 3 macros
EDOM, ERANGE and errno. Thus, conversely, these are also the only
things required in errno.h.

Then, again 19.3, says that 'the contents (of cerrno) are the same as
the Standard C library header <errno.h>'. Shall I thus expect the macro
definitions present in, say in the platform specific
/usr/include/errno.h, in <cerrno> as well? And then of course also in
<errno.h>?

I understand that the standard will not require more for <cerrno>
as what is given in 19.3, because more might be platform
specific. However, I would have expected that a C++ compiler vendor
continues to provide the 'old' <errno.h> from C times to allow me to do
system 'near' programming in C++. Am I supposed to change all
occurances of <errno.h> into "errno.h" and modifying the include search
path? If so, why does the standard actually provide a 'new' <errno.h>
beyond a 'new' and 'clean' <cerrno> - certainly it cannot be meant as
a 'compatibility' feature with C...

Thanks for your enlightenment!
Stefan.

--
Stefan Schwarzer                       office: +49-(0)711-685-7606 fax: x-3658
Uni Stuttgart, ICA 1         (?-
Pfaffenwaldring 27           //\                     sts@ica1.uni-stuttgart.de
70569 Stuttgart, Germany    -V_/----     http://www.ica1.uni-stuttgart.de/~sts

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]