Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > standard include files

Reply
Thread Tools

standard include files

 
 
Stefan Ram
Guest
Posts: n/a
 
      02-23-2012
There was a discussion once about why people do not simply
include all possible standard headers, so that they do not
have to be so careful when choosing the needed ones.

Someone said that not including all possible standard
headers does reduce the possibility of standard names
defined in them colliding with user names. (Also including
future C versions, where a name might be defined by the
standard that is not defined now.)

But aren't all standard identifiers reserved anyway,
independently of whether the corresponding header is
included or not?

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      02-23-2012
On 02/23/12 01:38 PM, Stefan Ram wrote:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)
>
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?


They may be reserved, but that reservation isn't enforced.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-23-2012
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)
>
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?


N1570 7.1.3:

All identifiers with external linkage in any of the following
subclauses (including the future library directions) and errnoare
always reserved for use as identifiers with external linkage.

That covers all the functions declared in standard headers. So you can
define your own "sin" as long as it doesn't have external linkage.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-23-2012
On 2/22/2012 7:38 PM, Stefan Ram wrote:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)
>
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?


Reservations come in different scopes and contexts.

For example, `FILE' is not reserved if <stdio.h> is not
included: You are free to write `int FILE;' at file scope in
one module and `extern int FILE;' in another, and the two names
will both refer to the same `int' variable.

But then, you are *not* free to write `int fopen;' at file
scope in any module, with or without <stdio.h>. The name is of
a different "class," and the rules are different.

7.1.3p1 lists the different realms of "reserved" for different
kinds of names. You will note that the rules in the sub-paragraphs
are not all the same.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      02-23-2012
On 2012-02-23, Stefan Ram <(E-Mail Removed)-berlin.de> wrote:
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?


What if a header that you /need/ to include starts to clash with a name in your
program. Implementations should provide a way by which you can select the
precise standard conformance. E.g. what if someone needs to build a C90
program? It's simpler to have a switch for that in the implmentation than
to update the program.
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      02-23-2012
On 2012-02-23, Stefan Ram <(E-Mail Removed)-berlin.de> wrote:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)


This seems backwards, in fact. The external names exist whether you include the
header or not. So it is actually safer to include the header: you want the
clash to be detected at compile time.

In some environments you can write, say, your own malloc function:

double malloc(char *) { ... }

This is not diagnosed at linkage because it's something that is allowed
as an extension (overriding malloc). The internal C library uses of malloc
go to the right one, but those of the programs and any third party libs
go to the overridden one.

If a declaration were in scope (in spite of <stdlib.h> not being included),
this would be diagnosed as having the wrong type signature.

> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?


Exactly. Some identifiers are not, like typedef names or macro names.
But anything that has linkage is reserved anyway.

Even for names that are not reserved unless a given header is included,
it's usually a bad idea to invade that space.

If a translation unit includes no standard headers at all, should it be
defining ptrdiff_t, et cetera?

There is a case to be made for hosted implementations being free to define all
the standard material even if no header is included at all.
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      02-23-2012
On 2012-02-23, Keith Thompson <(E-Mail Removed)> wrote:
> That covers all the functions declared in standard headers. So you can
> define your own "sin" as long as it doesn't have external linkage.


But this is not necessarily a good idea, so there is a case to be made for
having this diagnosed as if the header were included.
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      02-23-2012
On 2012-02-23, William Ahern <william@wilbur.25thandClement.com> wrote:
> Stefan Ram <(E-Mail Removed)-berlin.de> wrote:
>> There was a discussion once about why people do not simply
>> include all possible standard headers, so that they do not
>> have to be so careful when choosing the needed ones.

>
>> Someone said that not including all possible standard
>> headers does reduce the possibility of standard names
>> defined in them colliding with user names. (Also including
>> future C versions, where a name might be defined by the
>> standard that is not defined now.)

>
>> But aren't all standard identifiers reserved anyway,
>> independently of whether the corresponding header is
>> included or not?

>
> I can't speak for others, but _practicing_ is _learning_. When you include
> only what's needed, you learn how the standard library is organized.


This is not knowledge, but useless trivia.

Including what is needed is done for the sake of faster compilation times,
when headers are implemented vi textual substitution (which is basically
still the "state of the art" in C today).
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-23-2012
On 02/23/12 05:19 PM, William Ahern wrote:
> Kaz Kylheku<(E-Mail Removed)> wrote:
>> On 2012-02-23, William Ahern<william@wilbur.25thandClement.com> wrote:
>>>
>>> I can't speak for others, but _practicing_ is _learning_. When you include
>>> only what's needed, you learn how the standard library is organized.

>
>> This is not knowledge, but useless trivia.

>
>> Including what is needed is done for the sake of faster compilation times,
>> when headers are implemented vi textual substitution (which is basically
>> still the "state of the art" in C today).

>
> I doubt including all the standard C headers would noticebly slow
> compilation, even for small compilation units. The simple textual
> substitution is a performance benefit compared to C++ or Java.


The C++ include mechanism is unfortunately still the same a C.

--
Ian Collins
 
Reply With Quote
 
Nils M Holm
Guest
Posts: n/a
 
      02-23-2012
Kaz Kylheku <(E-Mail Removed)> wrote:
> This is not knowledge, but useless trivia.


Knowledge is useless trivia.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
/* #include <someyhing.h> */ => include it or do not include it?That is the question .... Andreas Bogenberger C Programming 3 02-22-2008 10:53 AM
#include headers that include this header Aguilar, James C++ 2 07-16-2004 05:56 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Elie Nader C++ 1 11-28-2003 03:12 PM
Re: the use of #include <a_file.h> v/s #include"a_file.cpp" Rolf Magnus C++ 2 11-28-2003 12:26 PM
#include "bar" negates #include <string> ; how to fix? Danny Anderson C++ 5 08-15-2003 06:38 PM



Advertisments