Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

standard include files

 
 
BartC
Guest
Posts: n/a
 
      02-24-2012


"Nick Keighley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.


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

--
Bartc



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

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-24-2012
"BartC" <(E-Mail Removed)> writes:
[...]
> 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,
you just have to add "#include <stdio.h>" to the top of your source
file. I don't think that's a huge burden.

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

--
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
 
Joe keane
Guest
Posts: n/a
 
      02-24-2012
In article <ji664f$i31$(E-Mail Removed)>, BartC <(E-Mail Removed)> wrote:
>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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-25-2012
On 02/25/12 03:35 AM, jacob navia wrote:
> 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.


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.

--
Ian Collins
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-25-2012
On 2/24/2012 08:20, BartC wrote:
>
> 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"?
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-25-2012
On 2/23/2012 13:52, BGB wrote:
>
> 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>
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-25-2012
On 2/24/2012 02:18, io_x wrote:
> "Kaz Kylheku"<(E-Mail Removed)> ha scritto nel messaggio
> news:(E-Mail Removed)...
>> 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'.
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-25-2012
On Feb 24, 8:03*pm, Keith Thompson <(E-Mail Removed)> wrote:
>
> > 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>
>

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.


--
Basic Algorithms - a great book to get as your second book of C, after
you've worked through an introduction to C.
http://www.malcolmmclean.site11.com/www
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-25-2012
Malcolm McLean <(E-Mail Removed)> writes:
> On Feb 24, 8:03Â*pm, Keith Thompson <(E-Mail Removed)> wrote:
>> > 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>
>>

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

--
Keith Thompson (The_Other_Keith) (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
 
 
 
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