10 October 2007, 00:26 | #1 |
In deep Trouble
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 52
Posts: 841
|
How do I read .h files?
I mean... for example, in the "hello, world" program in C, you need to #include <stdio.h> to gain access to the printf()-function, right?
However, when I look at stdio.h to see the optional components of printf(), I only see *** EQU this and *** EQU that, ifndef such then DEF so, and it makes no sense whatsoever. If I was to make a program using <stupid_doc.h> for the function idiot(), how would I go about do it? |
10 October 2007, 02:03 | #2 |
Mostly Harmless
Join Date: Aug 2004
Location: Northern Ireland
Posts: 1,149
|
The std* headers aren't meant for humans to read - you picked a bad place to start
There's nothing special about .h files at all, they're just C source code files. Typically you will use them to declare constants, types, function prototypes etc. so they may be shared between modules in your program. |
10 October 2007, 02:04 | #3 |
Citizen of Elthesh
Join Date: Sep 2003
Location: UK
Posts: 949
|
Header files (.h files) contain declarations for functions and values that are defined elsewhere. The #include command just copies the contents of the specified file into your source file.
These declarations are required so the compiler knows what you want and can check your syntax and types; and to compute object sizes, and so forth. Since it processes one file at a time and those functions and values are implemented elsewhere, it has no other way of knowing these details. The actual function is later combined with your program by the linker. In the case of printf you will probably not find source code for it anywhere. It is part of the Standard C library, which is typically included with the compiler in binary form. Also note that the linker is typically called implicitly by the compiler (I'm not sure if that has always been the case, but yeah). All that #ifdef stuff and such is just to provide some kind of customization to what functions are used, you don't really have to worry about it all that much. I won't go into detail about that in this post, suffice it to say you don't have to worry about it all that much for now. Say you have written a function foo() and bar() in foobar.c like this: Code:
void foo(const char* text) { prinft("%s", text); } int bar(int x, int y) { return x + y; } Code:
#ifndef FOOBAR_H #define FOOBAR_H void foo(const char* text); int bar(int x, int y); #endif Also note the names in the signatures are optional, the following would work just as well: Code:
... void foo(const char*); int bar(int, int); ... I hope this helps. |
10 October 2007, 02:09 | #4 |
Citizen of Elthesh
Join Date: Sep 2003
Location: UK
Posts: 949
|
Good point, I forgot to mention types.
Also note that a lot of this was oversimplified and I believe linkers actually only check the name, not the signatures (C has no function overloading and in C++ it's done by mixing the signature in with the symbol name; I'm not aware of any common C++ aware linkers). But I'm hoping my lengthy explanation, the typing of which caused me to be beaten by girv , helps you get a basic idea. |
10 October 2007, 10:15 | #5 |
In deep Trouble
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 52
Posts: 841
|
So... to actually see what optional/formatting components the function "printf()" have (I mean, like theescape sequences, \n, \int, \dec and those) I can't use the .h files to get any info at all? I have to goto the autodocs or some other document to see more of what I have available in each function?
printf() is a binary form function, which has it DECLARE values in stdio.h Thanks guys. I've been wondering about this for ages, and it has actually set me back quite a few years because I've wanted to understand what the heck I'm looking at and howto decipher those blasted .h files |
10 October 2007, 10:39 | #6 | |
Citizen of Elthesh
Join Date: Sep 2003
Location: UK
Posts: 949
|
Quote:
Edit: If you want to see the actual implementation of the standard library functions, you may be out of luck. For one thing they might not even be implemented in C at all (although they often are), and for another -- unless you're dealing with an open source compiler -- you probably won't get those sources at all. For instance, on Windows (particularly when using Microsoft's VC compiler, but many others use it as well) the standard library functions are in msvcrt.dll which ships with the OS. I have no clue what it's like on the Amiga. Last edited by eLowar; 10 October 2007 at 10:46. Reason: Bored. Needlessly elaborating. |
|
10 October 2007, 11:32 | #7 |
In deep Trouble
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 52
Posts: 841
|
I found this little piece of code on the 'net.
Code:
A Weight Conversion Program #include <stdio.h> #define KILOS_PER_POUND .45359 main() { int pounds; printf(" US lbs UK st. lbs INT Kg\n"); for(pounds=10; pounds < 250; pounds+=10) { int stones = pounds / 14; int uklbs = pounds % 14; float kilos = pounds * KILOS_PER_POUND; printf(" %d %d %d %f\n", pounds, stones, uklbs, kilos); } } Code:
#define KILOS_PER_POUND .45359 (still trying to get me head around the .h system) If we use AmigaE terms, (snippeted from the source to module Devices/cd.m) Code:
OBJECT cdinfo playspeed:INT -> This is unsigned readspeed:INT -> This is unsigned readxlspeed:INT -> This is unsigned sectorsize:INT -> This is unsigned xlecc:INT -> This is unsigned ejectreset:INT -> This is unsigned reserved1[4]:ARRAY OF INT -> Array is unsigned maxspeed:INT -> This is unsigned audioprecision:INT -> This is unsigned status:INT -> This is unsigned reserved2[4]:ARRAY OF INT -> Array is unsigned ENDOBJECT OH, and btw, eLowar.... after fove posts here, I've got more answers and more information about my first question, than I've got allotgether on several C-programming sites. I guess it's still true, after 14 years of no new Amiga, the Amiga community is STILL the best community there is |
10 October 2007, 12:00 | #8 | ||
Citizen of Elthesh
Join Date: Sep 2003
Location: UK
Posts: 949
|
Quote:
Note the difference between a constant variable like const double kilos_per_pound .45359 and a pre-processor macro like #define KILOS_PER_POUND .45359. The difference is that the former is an actual variable (albeit one that can't be modified) and the latter simply performs text substitution before compilation. For example with GCC you can use the -E parameter to see what your files look like after the preprocessor is done with them (including files, replacing #defined stuff, etc.). Quote:
The rough equivalent of the E code you posted would then be: Code:
struct cdinfo { unsigned int playspeed; unsigned int readspeed; unsigned int readxlspeed; unsigned int sectorsize; unsigned int xlecc; unsigned int ejectreset; unsigned int reserved1[4]; unsigned int maxspeed; unsigned int audioprecision; unsigned int status; unsigned int reserved2[4]; }; Code:
struct cdinfo myCdinfo; ... myCdinfo.playspeed = 5; Code:
class MyClass: public SomeOtherClass { public: MyClass(): SomeOtherClass() { /* inline function code */ } ~MyClass(); // this function and the following are defined elsewhere virtual void foo(); int bar(char* parameter); private: int privateValue_; }; Note that in C++, a struct is really just a class in which everything is public (more or less ). Anyways, if E is an object oriented language and you've worked with it, you might feel more at home with C++ than C. Last edited by eLowar; 10 October 2007 at 13:21. Reason: Corrected minor syntax error and added some comments. |
||
12 October 2007, 13:06 | #9 | |
In deep Trouble
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 52
Posts: 841
|
Thanks again, eLowar
My main reason for bringing E into this subject, is that I started to get a grasp on that back in 1996, but then sadly my HD died and I couldn't afford a new one untill YEARS later (upon which I also had gotten an A1200 and aPC and was surfing the net) and my E-diskettes (registered from Wouter himself) had more or less died already. Anyways, .h files are used in both C and C++, so I just wanted to understand what the heck I was looking at. I guess some people doesn't need to understand what they're doing as long as it works, but for me it's important to grasp the underlying stuff that actually MAKES things work, before continuing my programming learning curve. So, knowing that the standard library works isn't enough for me, I need to know the WHY and the HOW it works too.... otherwise, I just get heavily frustrated because I can't find the (sometimes useless) info I want Quote:
Last edited by Doc Mindie; 12 October 2007 at 13:08. Reason: included info about AmigaE for eLowar's (mis)benefit |
|
12 October 2007, 16:09 | #10 |
Citizen of Elthesh
Join Date: Sep 2003
Location: UK
Posts: 949
|
Well all you really need to know about .h files is that they're typically used with #include, which just dumps them verbatim into the place where the #include line was. Then accept that the standard library typically comes in binary form and as long as you have documentation about its behavior, you don't need to know about its internals (after all that's the whole point of using functions -- and also classes -- to begin with). From there on you should concentrate on understanding how a linker works to actually get the point of .h files and what's written in them.
|
12 October 2007, 21:32 | #11 |
In deep Trouble
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 52
Posts: 841
|
It's the "how" and "why" that sticks in me head, mate.... if I don't understand either, I put the breaks on
Anyways, I've found the full sources for DICE C on the net somewher.... after a nice look into the archive, I found what I've been looking for all these years, namely the actual docs on the stdlib functions (And I've picked up on AmigaE again too :look ) |
13 October 2007, 02:08 | #12 | |
Amiga Enthusiast
Join Date: Oct 2007
Location: USA
Posts: 217
|
Quote:
Only a masochist can operate a C compiler. Scientists have calculated that if masochists continue to write C programs at their current rate then the world will run out of curly braces by the year 2012. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Cant get these files on an adf WB1.3 can read - help :( | AB Positive | support.WinUAE | 2 | 02 June 2010 20:00 |
SWOS - files read from and saved to HD!? | Playaveli | request.Other | 12 | 13 June 2007 17:45 |
lha files read by UAE? | dionisis | New to Emulation or Amiga scene | 3 | 09 April 2007 11:55 |
Amiga program to Read MP3 Files ? | Rich M | Amiga scene | 16 | 09 January 2005 14:17 |
I have 1 CD-ROM With 10 Game ADF Files, Will My Amiga 1200 Tower Read It ? | xamigax | New to Emulation or Amiga scene | 16 | 28 April 2002 05:14 |
|
|