Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

standard include files

 
 
Quentin Pope
Guest
Posts: n/a
 
      02-23-2012
On Thu, 23 Feb 2012 19:30:51 +0000, BartC wrote:
> "Quentin Pope" <(E-Mail Removed)> wrote in message
> news:ji5v41$qnu$(E-Mail Removed)...
>> On Thu, 23 Feb 2012 13:23:43 +0100, jacob navia wrote:
>>> Le 23/02/12 01:38, Stefan Ram a écrit :

>
>>> As I have already reported in a similar discussion, the lcc-win
>>> compiler does just that: the <stdheaders.h> file includes all standard
>>> include files.

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

>
> 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?
>
>> 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.

>
> 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.
>
>>The Standard manages headers very sensibly in my opinion.

>
> 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?
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      02-23-2012
Le 23/02/12 19:04, Quentin Pope a écrit :
> On Thu, 23 Feb 2012 13:23:43 +0100, jacob navia wrote:
>> Le 23/02/12 01:38, Stefan Ram a écrit :
>>> 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?
>>>
>>>

>> As I have already reported in a similar discussion, the lcc-win compiler
>> does just that: the<stdheaders.h> file includes all standard include
>> files.

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



 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      02-23-2012
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.


 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-23-2012
"Quentin Pope" <(E-Mail Removed)> wrote in message
news:ji64me$9k5$(E-Mail Removed)...
> On Thu, 23 Feb 2012 19:30:51 +0000, BartC wrote:
>> "Quentin Pope" <(E-Mail Removed)> wrote in message



>>>The Standard manages headers very sensibly in my opinion.

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


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

--
Bartc

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-23-2012
On Thu, 2012-02-23, Quentin Pope wrote:
> On Thu, 23 Feb 2012 13:23:43 +0100, jacob navia wrote:

....
>> As I have already reported in a similar discussion, the lcc-win compiler
>> does just that: the <stdheaders.h> file includes all standard include
>> files.

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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      02-23-2012
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!


 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      02-24-2012
On 2/23/2012 11:11 PM, Gareth Owen wrote:
> Jorgen Grahn<(E-Mail Removed)> writes:
>
>>> The Standard manages headers very sensibly in my opinion.

>>
>> Yes. This is IMO completely a non-issue.

>
> 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).

 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      02-24-2012
On Feb 23, 3:10*am, Kaz Kylheku <(E-Mail Removed)> wrote:

[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.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      02-24-2012
On Feb 23, 3:13*am, Kaz Kylheku <(E-Mail Removed)> wrote:
> On 2012-02-23, William Ahern <will...@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.


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

> 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
 
Nick Keighley
Guest
Posts: n/a
 
      02-24-2012
On Feb 23, 9:52*am, Malcolm McLean <(E-Mail Removed)>
wrote:
> On Feb 23, 6:29*am, BGB <(E-Mail Removed)> wrote:
>
> > and there is no "ideal" way to fix it (precompiled header mechanisms
> > tend to be more of a non-standardized finicky kludge, ...).- Hide quoted text -

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