standard include files

[Quentin Pope]

By the standards of a desktop PC, these files are relatively tiny: about
3000 lines on lccwin32, and 5000 lines on mingw. By comparison, the
standard Windows headers (excluding optional headers!) are 18000 lines
and 26000 lines respectively. Plus any headers relevant to the
application...

C programs may run on some very small systems, but you would expect a
development host to be reasonably respectable in computer-power.

Although it is true that the headers can contain a lot of long-winded
stuff like this, the longest header line in mingw:

_CRTALIAS long __cdecl __MINGW_NOTHROW _wfindfirsti64 (const wchar_t*
_v1, struct _wfinddatai64_t* _v2) { return(_wfindfirst32i64 (_v1,(struct
_wfinddata32i64_t*)_v2)); }

It seems to be just the nature of the language that it has to partly
define itself by reams of these tedious definitions, and written in an
inefficient text format too.

But even with the headers as they are now, with the highly-advanced
compilers that everyone is always on about, is there really no
alternative to having to read in exactly the same headers, for every
single compilation, over and over again?


Only where thousands of very small source files are used, which itself
is highly inefficient.

But if it is a problem, then there is a very simple solution: replace
stdheaders.h with just the headers that are needed.


Yes, for 1972! Or maybe for an 8-bit system with 64KB.

Sorry, but this is a complete fallacy.

I recently had cause to compile Fire Fox from source, and I only *just*
had enough RAM for the linking phase.

Computers may have become more powerful, but the bloat of software
packages has more than kept pace with it.

And why do you think it's OK to exclude people on an 8-bit system with
64KB anyway?

 

[jacob navia]

Le 23/02/12 19:04, Quentin Pope a écrit :

Sorry, but this is a terrible idea.

Lazy people will use this and then send their source code to someone with
a slow CPU or not much RAM... at best inconvenience, or maybe the compile
fails needlessly because of a lack of memory.

Or people will use this in files that end up as modules in large
projects, where compile time is measured in hours: then reading in all
this useless crap will be a significant drain.

The Standard manages headers very sensibly in my opinion.

//QP

For a 16 bit machine with 64K yes.

You are actually saying:

"... someone with a slow CPU and not much ram..." so ALL OTHERS that
have a CPU not older than 5 years will have to suffers from that.

You are a very good "sample clc guy":

let's live in the past...

"Ahhh how NICE the world was when we programmed those PDP 11"

 

[jacob navia]

Le 23/02/12 19:20, Willem a écrit :

Quentin Pope wrote:
) Sorry, but this is a terrible idea.
)
) Lazy people will use this and then send their source code to someone with
) a slow CPU or not much RAM... at best inconvenience, or maybe the compile
) fails needlessly because of a lack of memory.
)
) Or people will use this in files that end up as modules in large
) projects, where compile time is measured in hours: then reading in all
) this useless crap will be a significant drain.
)
) The Standard manages headers very sensibly in my opinion.

OK, so what we need is a compiler that pre-includes all the standard
headers (AFAIK, not including a header is UB, so the compiler is allowed
to do this) and, with a special tool, inserts the list of headers that is
actually needed for when you distribute the source.

So lazy coders can start off with not including any of the headers, and
then when the time comes to distribute the code, they run a simple tool
which adds all the required headers to each of the source files.


SaSW, Willem

Here is the stdheaders.h file

#ifndef assert
#include <assert.h>
#endif
#include <complex.h>
#include <inttypes.h>
#include <stdbool.h>
#include <stdint.h>
#include <fenv.h>
#include <getopt.h>
#include <errno.h>
#include <ctype.h>
#include <float.h>
#include <limits.h>
#include <locale.h>
#include <math.h>
#include <tgmath.h>
#include <setjmp.h>
#include <signal.h>
#include <stdarg.h>
#include <stddef.h>
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <wchar.h>
#include <wctype.h>


Too complicated for you to customize it?

Just erase some lines and you are all set.

 

[BartC]

Computers may have become more powerful, but the bloat of software
packages has more than kept pace with it.

In that case, the few thousand lines of C headers will make little
difference (and do not affect linking).

And why do you think it's OK to exclude people on an 8-bit system with
64KB anyway?

For many reasons...

But let's go along with this: why should we exclude with those 1KB 8-bit
systems? Why not break the system headers into 250 different files instead
of 25 so that these people can still compile C programs (although they might
still have some trouble with Firefox sources!).

Is it worth making coding much more difficult for everyone else because of a
handful of people who can't afford a proper computer?

 

[Jorgen Grahn]

Sorry, but this is a terrible idea.

Lazy people will use this and then send their source code to someone with
a slow CPU or not much RAM...

Not to mention people who don't have <stdheaders.h>, i.e. the vast
majority of us.

....

The Standard manages headers very sensibly in my opinion.

Yes. This is IMO completely a non-issue. (Especially once you've
learned that your documentation points out which headers you need to
include.)

/Jorgen

 

[jacob navia]

Le 23/02/12 23:08, Gareth Owen a écrit :

I'll go out on a limb, and suggest there's probably not many 8-bit
machines there.

Exactly, at least not used for development.

I am developing a 16 bit version for a customer with an FPGA. The
development system will run in a PC with 8GB RAM at least. The object
code is sent to the FPGA through a serial line, and in the target system
only the monitor and the dedicated software will run.

The point here is that development systems even for 8 or 16 bit targets
are done in a powerful modern PC!

 

[BGB]

Undeniably, but the idea that providing a convenience header for those
that want it - as a QoI issue - is a "stupid idea", is as wrong-headed
as insisting the converse.

granted, however, if a person makes non-trivial apps, it is very likely
they will make custom headers which will include whatever other headers
are needed.

I'd wager that the vast majority of code targeted created for one of
VC++/gcc/lcc-win is never compiled with anything else.

possibly, I have gone as far as seeing some amount of supposedly
"portable" code which made some use of GCC specific extensions, and thus
had to be modified as I was building on Windows with MSVC.

nevermind libraries which would likely require a bit of work to get to
build with MSVC.


my stuff builds with either MSVC or GCC, but occasionally needs fixing
as MSVC and GCC will barf on different things, and every so often things
will leak through which break on one or the other.

personally, I have never used LCC or similar.

there was my own C compiler, but it has anymore mostly become little
more than a code-processing tool (its codegen has fallen into disuse,
and its main output at this point is metadata).

 

[Nick Keighley]

[including all the header files]

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.

ok might be sensible for a small library likes C's runtime but would
you want to do that C++? or Python? or Perl? I'm not even sure it's
clear what /is/ the standard library for some of those. I suppose
referencing a namespace could automatically import the correct
identifiers and do the moral equivalent of linking. presumably you'd
have to obey some sort of convention on where files were kept. or use
a database.

 

[Nick Keighley]

This is not knowledge, but useless trivia.

so's most knowledge when viewed from a particular point of view.

 

[Nick Keighley]

My evil MS Visual Studio insists on adding the line #include
"stdafx.h" to everything, including the standard C core logic files.

there are ways to stop it doing that

 

[BartC]

[including all the header files]

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.

ok might be sensible for a small library likes C's runtime but would
you want to do that C++? or Python? or Perl? I'm not even sure it's
clear what /is/ the standard library for some of those. I suppose
referencing a namespace could automatically import the correct
identifiers and do the moral equivalent of linking. presumably you'd
have to obey some sort of convention on where files were kept. or use
a database.

You'd expect features which are a fundamental part of the language to be
readily available.

The problem with C is that most of these are considered to be optional
extras!

But there might be a case for splitting all the standard headers into two:
all the really basic stuff that everyone is likely to use (such as
printf()), and all the other things that probably no-one ever uses (such as
#define PRIu8 "u").

 

[jacob navia]

Le 24/02/12 11:03, Robert Wessel a écrit :

Nonsense. You're assuming the implementation has DLLs, and has the C
library in a DLL, and organized in a particular way. None of which is
required.

Exactly.

Lcc-win has the library in a static library (no dlls). I eliminated the
dll because of the endless problems in support...

In 16 bit windows, dlls were essential, in 32 bit windows they are less
essential and in 64 bits they are quite unnecessary.

 

[Keith Thompson]

You'd expect features which are a fundamental part of the language to be
readily available.

The problem with C is that most of these are considered to be optional
extras!

They are readily available. For example, if you want to call printf,

But there might be a case for splitting all the standard headers into two:
all the really basic stuff that everyone is likely to use (such as
printf()), and all the other things that probably no-one ever uses (such as
#define PRIu8 "u").

<sarcasm>And I'm sure there'd be no problem getting everyone to agree on
which features should go where.</sarcasm>

When C was initially being invented (or rather, evolved over time),
there were very good reasons for putting declarations for different
parts of the library in separate headers. Over time, those reasons have
become less important. If the language were being designed from scratch
today, things might well be done differently; the entire standard
library might be in a single header, or there might be some mechanism
other than textual inclusion of header files.

But the burden of adding the right #include directives for whatever
functions you're calling is not, in my opinion, serious enough to
justify making such a radical change in the way we use libraries.

And even if we put the entire standard library into, say, <std.h>, most
C programs use a lot of non-standard headers, so it wouldn't really
address the general issue.

 

[Joe keane]

But let's go along with this: why should we exclude with those 1KB 8-bit
systems?

We shouldn't exclude them. But they're very very likely using
cross-compilers. The puter that generates the code isn't the puter that
runs the code. The puters that make the chip isn't the puter that is
the chip, either.

 

[Ian Collins]

Le 24/02/12 11:03, Robert Wessel a écrit :

Exactly.

Lcc-win has the library in a static library (no dlls). I eliminated the
dll because of the endless problems in support...

In 16 bit windows, dlls were essential, in 32 bit windows they are less
essential and in 64 bits they are quite unnecessary.

I'm not a windows developer, but that is untrue on any platform that
offers any form of intra-version guarantee (which may or may not include
windows). The C runtime is a bridge between applications and the
private system interfaces. So if you want your application to run on
multiple OS versions, you really need the C runtime (and any other
public interface libraries) to be dynamically linked. If not, your
application will break if a key private interface is changed.

My usual OS (Solaris) does offer such a guarantee which is why only
dynamic versions of all of the public interface libraries are provided.

 

[Shao Miller]

You'd expect features which are a fundamental part of the language to be
readily available.

The problem with C is that most of these are considered to be optional
extras!

But there might be a case for splitting all the standard headers into
two: all the really basic stuff that everyone is likely to use (such as
printf()), and all the other things that probably no-one ever uses (such
as #define PRIu8 "u").

Isn't there a split for "freestanding" and "hosted"?

 

[Shao Miller]

MS tends to use a similar convention for API functions, albeit
preferring to have an uppercase prefix (for example "WSAGetLastError()"
and similar).

<offtopic>
That one strikes me as exceptional, though I could easily be mistaken.
I'd expect more along the lines of 'WsaGetLastError' to appear in
Windows, but maybe I'm thinking NT-only.
</offtopic>

 

[Shao Miller]

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.

for resolve that problem one has to impose the names of standard .dll
[where are all executable functions as printf malloc and all
standard function]

and rename all functions and variable of that file as
thatStdFile_varibleOrFunctionName as thatStfFile_printf
and nobody can use one file that has name thatStdFile...

Or maybe you could define the types of everything in the standard
headers, then make a 'struct cstd' whose members are pointers to those
types and are capable of pointing to everything in standard C. Then you
could do 'my_cstd->malloc' instead of 'malloc'.

 

[Malcolm McLean]

<sarcasm>And I'm sure there'd be no problem getting everyone to agree on
which features should go where.</sarcasm>

On many platforms printf() isn't available. Much less excusably,
stderr is often vandalised.

On others you don't have a maths library, maybe not even floating
point at all.

In other places malloc() is either unavailable, or frowned upon, or
needs special set up.

Some compilers have deprecated the string library, generating such a
flod of warnings that error messages gwet drowned, and the string
library is effectively unusuable. Then in other places acsii strings
aren't too useful.

Some library writers are so thick that they don't provide qsort() on a
compiler that can't do recursion.

So it's hard to say what is the core of the standard library.

 

[Keith Thompson]

On many platforms printf() isn't available. Much less excusably,
stderr is often vandalised.

On others you don't have a maths library, maybe not even floating
point at all.

In other places malloc() is either unavailable, or frowned upon, or
needs special set up.

Some compilers have deprecated the string library, generating such a
flod of warnings that error messages gwet drowned, and the string
library is effectively unusuable. Then in other places acsii strings
aren't too useful.

Some library writers are so thick that they don't provide qsort() on a
compiler that can't do recursion.

So it's hard to say what is the core of the standard library.

Most of what you describe would apply only to freestanding
implementations. A conforming freestanding implementation is not
required to provide any standard headers other than:

<float.h>
<iso646.h>
<limits.h>
<stdalign.h>
<stdarg.h>
<stdbool.h>
<stddef.h>
<stdint.h>
<stdnoreturn.h>

(Several of these headers are new in C11.)