Learning process

Discussion in 'C Programming' started by Karsten Kvistad, Jan 3, 2004.

  1. Hi!
    I'm currently teaching myself the C programming language. The problem is
    I don't know what to do next. I know file I/O, pointers, functions and
    the like. I do not know how to make .h files, Makefiles or anything else
    required for large projects. Should I learn how to do this, sockets,
    GTK, curses or what?

    --
    (o_ Confused,
    (/)_ Karsten Kvistad
     
    Karsten Kvistad, Jan 3, 2004
    #1
    1. Advertising

  2. Karsten Kvistad <karsten-k.broadpark@no> scribbled the following:
    > Hi!
    > I'm currently teaching myself the C programming language. The problem is
    > I don't know what to do next. I know file I/O, pointers, functions and
    > the like. I do not know how to make .h files, Makefiles or anything else
    > required for large projects. Should I learn how to do this, sockets,
    > GTK, curses or what?


    Well, .h files are syntactically identical to .c files. The only thing
    that is usually different is that .h files should not contain any actual
    executable code, only definitions.
    Makefiles are not really a C concept. Make is a tool for compiling or
    building just about anything. I've used it to make LaTeX documents. You
    don't have to use make to compile C. Especially single source file
    programs can be compiled just fine with one compiler call.
    If I were you I'd look into .h files and makefiles first. Sockets, GTK
    and curses are not part of C, they're platform-specific add-ons. It's
    important to understand the language itself before tackling those.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "I am lying."
    - Anon
     
    Joona I Palaste, Jan 3, 2004
    #2
    1. Advertising

  3. Karsten Kvistad wrote:

    > Hi!
    > I'm currently teaching myself the C programming language. The problem is
    > I don't know what to do next.


    One thing you might want to do before too long is to check that your teacher
    knew what he was talking about. :)

    This newsgroup can help you do that.

    > I know file I/O, pointers, functions and
    > the like. I do not know how to make .h files,


    Most people use a text editor for this. More importantly for you to
    discover: what /is/ a header?

    Answer: a header is an interface description for a module. Now that you know
    that, what do you think belongs in a header?

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jan 3, 2004
    #3
  4. Richard Heathfield wrote:
    > Karsten Kvistad wrote:
    >>I know file I/O, pointers, functions and
    >>the like. I do not know how to make .h files,

    >
    > Most people use a text editor for this.


    I figured so... I meant that I don't know what should go into them.

    If this was a joke, I apologise for my lack of insight :p
    --
    (o_ Karsten Kvistad
    (/)_
     
    Karsten Kvistad, Jan 3, 2004
    #4
  5. Karsten Kvistad <karsten-k.broadpark@no> scribbled the following:
    > Richard Heathfield wrote:
    >> Karsten Kvistad wrote:
    >>>I know file I/O, pointers, functions and
    >>>the like. I do not know how to make .h files,

    >>
    >> Most people use a text editor for this.


    > I figured so... I meant that I don't know what should go into them.


    > If this was a joke, I apologise for my lack of insight :p


    You figured correctly, they are made with a text editor. See my previous
    post for an answer to your additional question. Basically, put the
    following in .h files:

    * Macro definitions
    * Structure and union definitions
    * Typedefs
    * Extern function or variable declarations

    ....and *very* little else. Especially, do NOT put any real definition
    of a variable or function, that would actually take up space in the
    object file. That would only cause linking problems if you happen to
    #include the same .h file from two .c files.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "I am looking for myself. Have you seen me somewhere?"
    - Anon
     
    Joona I Palaste, Jan 3, 2004
    #5
  6. Karsten Kvistad

    Morris Dovey Guest

    Karsten Kvistad wrote:
    > Hi!
    > I'm currently teaching myself the C programming language. The problem is
    > I don't know what to do next. I know file I/O, pointers, functions and
    > the like. I do not know how to make .h files, Makefiles or anything else
    > required for large projects. Should I learn how to do this, sockets,
    > GTK, curses or what?


    Karsten...

    In brief, header (.h) files are repositories for information
    about code and data in your translation unit that you choose to
    make available to other translation units.

    Generally this information consists of declarations (not
    definitions!) and descriptive comments to help others understand
    what and why you've included in the header.

    Makefiles, sockets, GTK, curses, and any 'what' that aren't
    actual elements of the C language can and should be addressed in
    other newsgroups. My <off-topic> suggestion would be to learn to
    use the make utility as early as possible - doing so may
    facilitate your efforts with all of the subjects you seem
    interested in investigating. </off topic>

    The "what to do next" answer will be highly dependent on your
    personal interests. You're on a voyage of discovery - look
    around, explore, investigate, take time to play, tinker, and
    experiment...

    --
    Morris Dovey
    West Des Moines, Iowa USA
    C links at http://www.iedu.com/c
    Read my lips: The apple doesn't fall far from the tree.
     
    Morris Dovey, Jan 3, 2004
    #6
  7. Karsten Kvistad

    CBFalconer Guest

    osmium wrote:
    > Richard Heathfield writes:
    >
    > > Answer: a header is an interface description for a module. Now
    > > that you know that, what do you think belongs in a header?

    >
    > I think it would be more accurate to say "A header often contains
    > an interface description for a module".


    IMO if it contains anything more it is being misused.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jan 3, 2004
    #7
  8. Karsten Kvistad

    osmium Guest

    Richard Heathfield writes:

    > Answer: a header is an interface description for a module. Now that you

    know
    > that, what do you think belongs in a header?


    I think it would be more accurate to say "A header often contains an
    interface description for a module".
     
    osmium, Jan 3, 2004
    #8
  9. Karsten Kvistad

    Ben Pfaff Guest

    CBFalconer <> writes:

    > osmium wrote:
    > > Richard Heathfield writes:
    > >
    > > > Answer: a header is an interface description for a module. Now
    > > > that you know that, what do you think belongs in a header?

    > >
    > > I think it would be more accurate to say "A header often contains
    > > an interface description for a module".

    >
    > IMO if it contains anything more it is being misused.


    What do you think of inline functions?
    --
    "I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
     
    Ben Pfaff, Jan 3, 2004
    #9
  10. Karsten Kvistad wrote:

    > Richard Heathfield wrote:
    >> Karsten Kvistad wrote:
    >>>I know file I/O, pointers, functions and
    >>>the like. I do not know how to make .h files,

    >>
    >> Most people use a text editor for this.

    >
    > I figured so... I meant that I don't know what should go into them.
    >
    > If this was a joke, I apologise for my lack of insight :p


    Er, yes, it was, but the rest of my article was intended seriously.

    Just to give you a simple idea of what might go into a header, take a look
    at:

    http://users.powernet.co.uk/eton/c/fgetdata.h
    http://users.powernet.co.uk/eton/c/fgetword.c
    http://users.powernet.co.uk/eton/c/fgetline.c

    (fgetword() reads an entire word of text, no matter how large, into a
    buffer, resizing the buffer as necessary. fgetline() does the same for
    lines.)

    To use these functions, the programmer must #include "fgetdata.h" - but what
    is /in/ fgetdata.h? Let's see...

    Well, okay, there's a huge comment at the beginning. We'll skip over that,
    and then we find this:

    #ifndef FGETDATA_H_ /* See Note A */
    #define FGETDATA_H_ 1 /* See Note A */
    #include <stdio.h> /* See Note B */

    /* Next three lines: See Note C */
    #define FGDATA_BUFSIZ BUFSIZ /* adjust to taste */
    #define FGDATA_WRDSIZ sizeof("floccinaucinihilipilification")
    #define FGDATA_REDUCE 1

    /* This space intentionally left blank -
    See Note D */

    int fgetline(char **line, size_t *size, size_t maxrecsize, FILE *fp,
    unsigned int flags); /* See Note E */
    int fgetword(char **word, size_t *size, const char *delimiters, size_t
    maxrecsize, FILE *fp, unsigned int flags); /* See Note E */

    #endif /* See Note A */

    Note A: the header is protected by "inclusion guards". These stop the
    header's main contents from being copied ad nauseam into a translation unit
    if it happens to have been #included a bit too enthusiastically. Working
    out how it works is diverting, and shouldn't take you more than 2 minutes.

    Note B: Since the header refers to the FILE type, it's a good idea to
    include the necessary header for that type. This means your calling code
    doesn't have to remember to #include <stdio.h> before #including /this/
    header.

    Note C: Symbolic constants that you want to make available to the caller can
    go here, as shown.

    Note D: This module didn't need any new types. If you had any, you'd want to
    define them here.

    Note E: Function prototypes. These are perhaps the most easily-recognised
    constituents of a header. :)

    That's pretty much all I put in headers, really - comments, preprocessing
    directives, typedefs, and function prototypes. I see no reason to clutter
    them up with other stuff (on the whole). If you're heavily into global
    data, though, you'll want to put your external declarations (NOT the
    definitions) in a header too. (I'm /not/ heavily into global data.)

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jan 3, 2004
    #10
  11. Karsten Kvistad

    Servé Lau Guest

    "Karsten Kvistad" <karsten-k.broadpark@no> wrote in message
    news:...
    > Hi!
    > I'm currently teaching myself the C programming language. The problem is
    > I don't know what to do next. I know file I/O, pointers, functions and
    > the like. I do not know how to make .h files, Makefiles or anything else
    > required for large projects. Should I learn how to do this, sockets,
    > GTK, curses or what?


    It's very useful to familiarize yourself with standard C library functions
    in math.h, stdlib.h, string.h etc. These headers are also good examples of
    how header files work :)
     
    Servé Lau, Jan 3, 2004
    #11
  12. Karsten Kvistad

    CBFalconer Guest

    Joona I Palaste wrote:
    >

    .... snip ...
    >
    > You figured correctly, they are made with a text editor. See my
    > previous post for an answer to your additional question. Basically,
    > put the following in .h files:
    >
    > * Macro definitions


    Only if they are to be visible outside the .c file

    > * Structure and union definitions


    Only if they are to be visible outside the .c file

    > * Typedefs


    Only if they are to be visible outside the .c file

    > * Extern function or variable declarations


    Only if they are to be visible outside the .c file

    >
    > ...and *very* little else. Especially, do NOT put any real
    > definition of a variable or function, that would actually take
    > up space in the object file. That would only cause linking
    > problems if you happen to #include the same .h file from two
    > .c files.


    "Header" is a misnomer. They would be better called interface
    specifications. However, all is grist to the #include mill.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jan 3, 2004
    #12
  13. Karsten Kvistad

    CBFalconer Guest

    Ben Pfaff wrote:
    > CBFalconer <> writes:
    > > osmium wrote:
    > > > Richard Heathfield writes:
    > > >
    > > > > Answer: a header is an interface description for a module. Now
    > > > > that you know that, what do you think belongs in a header?
    > > >
    > > > I think it would be more accurate to say "A header often contains
    > > > an interface description for a module".

    > >
    > > IMO if it contains anything more it is being misused.

    >
    > What do you think of inline functions?


    Didn't think of them, largely because I don't use them other than
    locally. KISS principle.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jan 3, 2004
    #13
  14. Karsten Kvistad wrote:
    > Hi!
    > I'm currently teaching myself the C programming language. The problem is
    > I don't know what to do next. I know file I/O, pointers, functions and
    > the like. I do not know how to make .h files, Makefiles or anything else
    > required for large projects. Should I learn how to do this, sockets,
    > GTK, curses or what?
    >


    I think Richard's advice is particularly good - once you think you've
    learned C, it's a very good idea to assume your teacher/book/whatever
    was completely wrong, and you need to verify basically everything you
    think you know. I know I was taught a number of things that were
    incorrect, and I also misunderstood a number of things.

    Other than that, you should consider that knowing the mechanics of a
    language is only the first step to being able to use the language well.
    The next part - learning idioms, good design & code organization,
    security and portability issues, etc. - is much more difficult.

    I suggest that the very next thing you do should be to read this group's
    FAQ. It has a lot of great information and can help you gain a better
    understanding of the language as a whole, as well as answering questions
    you may have had while you were learning, and making you aware of many
    issues that you may not have considered before. The URL is:

    http://www.eskimo.com/~scs/C-faq/top.html

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Jan 3, 2004
    #14
  15. Karsten Kvistad

    osmium Guest

    CBFalconer writes:

    > osmium wrote:
    > > Richard Heathfield writes:
    > >
    > > > Answer: a header is an interface description for a module. Now
    > > > that you know that, what do you think belongs in a header?

    > >
    > > I think it would be more accurate to say "A header often contains
    > > an interface description for a module".

    >
    > IMO if it contains anything more it is being misused.


    So be it. My compiler includes other header files, which makes things much
    more convenient for me, as a user. YMMV.

    I can also see where including macros in a header file might be a good idea.
     
    osmium, Jan 3, 2004
    #15
  16. Karsten Kvistad

    Malcolm Guest

    "Servé Lau" <> wrote in message
    > It's very useful to familiarize yourself with standard C library functions
    > in math.h, stdlib.h, string.h etc. These headers are also good examples >

    of how header files work :)
    >

    The problem is that stdlib headers are often not designed to be
    human-readable.

    A typical header looks like this

    #ifndef strsup_h
    #define strsup_h

    #define myisoperator(ch) ( (ch) == '+' || (ch) == '-' || (ch) == '/' | (ch)
    == '*') ? 1 : 0

    int mystrcount(const char *str, char ch);
    char *mystrdup(const char *str);
    int mystrreplace(char *dest, size_t len, const char *src, const char
    *search, const char *replace);

    #endif
     
    Malcolm, Jan 3, 2004
    #16
  17. "CBFalconer" <> wrote in message
    news:...
    > osmium wrote:
    > >
    > > I think it would be more accurate to say "A header often contains
    > > an interface description for a module".

    >
    > IMO if it contains anything more it is being misused.


    True, but it may contain less ;-)

    Not that such a design would be excessively useful.

    Peter
     
    Peter Pichler, Jan 3, 2004
    #17
  18. "Malcolm" <> wrote in message
    news:bt7c9q$6q0$...
    >
    > A typical header looks like this
    >
    > #ifndef strsup_h
    > #define strsup_h
    >
    > #define myisoperator(ch) ( (ch) == '+' || (ch) == '-' || (ch) == '/' |

    (ch)
    > == '*') ? 1 : 0

    ^
    Move this to the end of the line.

    >
    > int mystrcount(const char *str, char ch);
    > char *mystrdup(const char *str);
    > int mystrreplace(char *dest, size_t len, const char *src, const char
    > *search, const char *replace);
    >
    > #endif
     
    Peter Pichler, Jan 3, 2004
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rithesh Pai
    Replies:
    1
    Views:
    5,628
  2. Ryan Walker

    language learning vs. process

    Ryan Walker, Dec 2, 2003, in forum: Python
    Replies:
    7
    Views:
    325
  3. Hal Vaughan
    Replies:
    7
    Views:
    522
  4. somenath

    process of learning C language

    somenath, Sep 25, 2007, in forum: C Programming
    Replies:
    5
    Views:
    560
    David Thompson
    Oct 8, 2007
  5. Andrey Popp

    [I'm learning C]: Learning to use ucontext

    Andrey Popp, Jan 29, 2012, in forum: C Programming
    Replies:
    5
    Views:
    806
    Keith Thompson
    Jan 31, 2012
Loading...

Share This Page