Advanced C

Discussion in 'C Programming' started by pemo, Nov 27, 2005.

  1. pemo

    pemo Guest

    What would expect to be covered?

    Say you'd already attended a course, that had covered stuff like structs,
    pointers, bitwise and logical operators, multi-demensional arrays [and the
    like], *but* hadn't covered other stuff like recursion, unions, bit-fields
    [and the like].

    What topics would /should be covered on a course that takes students
    further?
     
    pemo, Nov 27, 2005
    #1
    1. Advertising

  2. pemo a écrit :
    > What would expect to be covered?
    >
    > Say you'd already attended a course, that had covered stuff like structs,
    > pointers, bitwise and logical operators, multi-demensional arrays [and the
    > like], *but* hadn't covered other stuff like recursion, unions, bit-fields
    > [and the like].
    >
    > What topics would /should be covered on a course that takes students
    > further?
    >
    >

    This book has been written by some of the regulars of this forum. It
    desserves its weight !

    http://users.powernet.co.uk/eton/unleashed/

    --
    A+

    Emmanuel Delahaye
     
    Emmanuel Delahaye, Nov 27, 2005
    #2
    1. Advertising

  3. pemo

    osmium Guest

    "Emmanuel Delahaye" writes:

    >> What would expect to be covered?
    >>
    >> Say you'd already attended a course, that had covered stuff like structs,
    >> pointers, bitwise and logical operators, multi-demensional arrays [and
    >> the like], *but* hadn't covered other stuff like recursion, unions,
    >> bit-fields [and the like].
    >>
    >> What topics would /should be covered on a course that takes students
    >> further?

    > This book has been written by some of the regulars of this forum. It
    > desserves its weight !
    >
    > http://users.powernet.co.uk/eton/unleashed/


    I don't have that book but I've looked at it and it seems a pretty good
    choice to me, too. Here is a link to the table of contents.

    http://www.amazon.com/gp/reader/067...7412145?_encoding=UTF8&p=S008&j=0#reader-page

    -- Osmium
     
    osmium, Nov 27, 2005
    #3
  4. pemo

    Eric Sosman Guest

    pemo wrote:
    > What would expect to be covered?
    >
    > Say you'd already attended a course, that had covered stuff like structs,
    > pointers, bitwise and logical operators, multi-demensional arrays [and the
    > like], *but* hadn't covered other stuff like recursion, unions, bit-fields
    > [and the like].
    >
    > What topics would /should be covered on a course that takes students
    > further?


    (Does a multi-demensional array suffer from both
    schizophrenia and Alzheimer's?)

    There's a qualitative difference among the examples
    you mention: unions and bit-fields are C language constructs,
    while recursion is a general programming technique. Decide
    what you're looking for: a course in advanced C, or a course
    in programming topics some of which are expressed in C. Are
    you trying to learn the tool or its application?

    It's hard for me to imagine a responsibly-taught course
    that omitted unions and bit-fields. Even a very short course
    of half a dozen lectures should at least mention them, even
    if it didn't spend time on them. But the follow-on course
    to "Baby Steps in C" wouldn't be characterized as "advanced,"
    would it?

    Just knowing a tool doesn't make you proficient in its
    use. You may know that one part of the hammer is for driving
    nails and another for pulling them back out again, but without
    practice you'll find that one part of the hammer is for mashing
    your thumb and the other for gouging out your eye. A course
    in advanced hammerology won't help; what you need is experience
    in using the tool. Look for a course that isn't "about" C,
    but that assumes you know C and encourages you to apply it.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Nov 27, 2005
    #4
  5. pemo

    pemo Guest

    "Eric Sosman" <> wrote in message
    news:...
    > pemo wrote:
    >> What would expect to be covered?
    >>
    >> Say you'd already attended a course, that had covered stuff like structs,
    >> pointers, bitwise and logical operators, multi-demensional arrays [and
    >> the like], *but* hadn't covered other stuff like recursion, unions,
    >> bit-fields [and the like].
    >>
    >> What topics would /should be covered on a course that takes students
    >> further?

    >
    > (Does a multi-demensional array suffer from both
    > schizophrenia and Alzheimer's?)


    :) Must invest in spelling checker!

    > There's a qualitative difference among the examples
    > you mention: unions and bit-fields are C language constructs,
    > while recursion is a general programming technique. Decide
    > what you're looking for: a course in advanced C, or a course
    > in programming topics some of which are expressed in C. Are
    > you trying to learn the tool or its application?


    It's not so much as what I'm looking for, as I have to put this course
    together.

    Of course, I realise that recursion is a general programming technique
    (having used Haskell for many years, I find looping any other way a bit
    weird), and I included it here purely as it's something that *some* people
    have a great deal of trouble getting to grips with - as some do unions and
    things like bit-fields.

    > It's hard for me to imagine a responsibly-taught course
    > that omitted unions and bit-fields. Even a very short course
    > of half a dozen lectures should at least mention them, even
    > if it didn't spend time on them. But the follow-on course
    > to "Baby Steps in C" wouldn't be characterized as "advanced,"
    > would it?


    That's interesting, as I've just taught two C courses (for a total of seven
    weeks (7 * 3 hour sessions)) [4 weeks on an intro, 3 on a 'further' course],
    and I haven't introduced unions or bit-fields yet. However, I'm now
    putting together two three hour sessions on some more topics - and thus the
    question as to what to include on this.

    Off the top of my head, here are some other things that are on my general
    candidate list [knowing the audience (mostly Oxford grad students)] - some
    to do with general programming things, others to do more with C ...

    function pointers and signal() etc.

    defensive programming techniques.

    mixing in assembler with C.

    writing modular code, using your own header files effectively.

    data-structures - like linked-lists, trees and graphs.

    keywords like _Bool, restrict, register, ...

    more on manipulating strings (strtok(), etc).

    interacting with the operating system.

    debugging using gdb etc.

    source control.

    lint.

    using thrid party libraries [for stats].

    btw, I'd be happy to provide *some* folks with a pdf of the courses I've
    already put-together/taught - in return for their opinion on their
    quality/correctness. If you're interested, please email me - peet[padding]m
    at cslab.com. But, you have to be kind!
     
    pemo, Nov 27, 2005
    #5
  6. pemo!

    > Of course, I realise that recursion is a general programming technique
    > (having used Haskell for many years, I find looping any other way a bit
    > weird)


    Some C compilers are capable of optimizing tail recursion. Teach your
    students how to write loops in C, using recursion that will be optimized
    away to loops. :)

    > function pointers and signal() etc.


    Function pointers and they don't even know about union yet? Ew.

    > mixing in assembler with C.


    Utterly useless. Your students only need this if they already know
    assembly and if they do, chances are they're capable of looking up
    asm(). Besides, every C compiler they're going to use in their life will
    do it differently.

    > writing modular code, using your own header files effectively.


    Now that's probably something everybody should know about.

    > data-structures - like linked-lists, trees and graphs.


    Are you certain they understand pointers? If they do, linked lists are
    a great way to make them forget, though (sigh... I would know, having
    taught C++ courses myself.)

    > more on manipulating strings (strtok(), etc).


    Be sure to teach them how to use strtok safely, though. It has a number of
    pitfalls.

    > debugging using gdb etc.


    If they don't know about debugging yet, showing them what gdb can do is
    definitely a good idea!

    > source control.


    Different course. Source control applies to many languages.


    Daniel
     
    Daniel Fischer, Nov 27, 2005
    #6
  7. pemo

    pemo Guest

    "Daniel Fischer" <> wrote in message
    news:p...
    > pemo!
    >
    >> Of course, I realise that recursion is a general programming technique
    >> (having used Haskell for many years, I find looping any other way a bit
    >> weird)

    >
    > Some C compilers are capable of optimizing tail recursion. Teach your
    > students how to write loops in C, using recursion that will be optimized
    > away to loops. :)
    >
    >> function pointers and signal() etc.

    >
    > Function pointers and they don't even know about union yet? Ew.
    >
    > ...


    Yeas, the omission thus far of unions has bothered me a bit, and next term
    I'll probably introduce them earlier - although it'll probably mean having
    to farm something out to the adv. course.

    However, I've [these days] rarely encountered unions in live code, or in
    finding I'm using a library that requires them etc. So, are unions
    something that ppl. find they deal with as commonly as, say, structs?
     
    pemo, Nov 27, 2005
    #7
  8. pemo!

    > However, I've [these days] rarely encountered unions in live code, or in
    > finding I'm using a library that requires them etc. So, are unions
    > something that ppl. find they deal with as commonly as, say, structs?


    I guess not, but they're a concept much easier to grasp than function
    pointers ;)


    Daniel
     
    Daniel Fischer, Nov 27, 2005
    #8
  9. pemo

    Michael Mair Guest

    pemo wrote:
    > What would expect to be covered?
    >
    > Say you'd already attended a course, that had covered stuff like structs,
    > pointers, bitwise and logical operators, multi-demensional arrays [and the
    > like], *but* hadn't covered other stuff like recursion, unions, bit-fields
    > [and the like].
    >
    > What topics would /should be covered on a course that takes students
    > further?


    Depends on what the students should be able to do after the
    course. Here is a (roughly translated) table of contents for a
    course I taught last year; <snip> indicates left-out parts.
    Note that the topics are not necessarily mentioned the first time
    when they appear in the ToC:

    ,----
    0 Intro

    I The Language
    1 Program structure and functions
    1.1 Hello, world
    1.2 Comments, possible sources of errors
    2 Control flow
    <snip>
    3 Preprocessor and Compiler
    3.1 Preprocessor
    3.1.1 Macros
    3.1.2 #include
    .....<snip>
    3.2 Compiler
    3.3 Modularisation
    4 Data types
    <snip>
    5 Operators
    6 Function
    6.1 Basic stuff
    6.2 main
    6.3 inline functions
    6.4 variable argument lists
    6.5 Arrays in the parameter list
    6.6 Recursion
    6.7 Modules and Libraries

    II Kür
    7 File I/O
    <snip>
    8 Tools
    8.1 gcc
    8.2 make
    8.3 lint/splint
    8.4 ar
    8.5 cvs
    8.6 gdb and ddd
    8.7 electric fence
    8.8 prof/gprof
    8.9 Editor
    8.10 Overview
    9 Optimisation
    <snip>

    Appendices
    A Intro: Using the shell
    <snip>
    B Joining together Matlab and C
    C Formatted I/O
    <snip>
    D Standard library functions
    Glossary
    Literature
    `----

    I had 12*1.5h courses plus 11*2h attended exercises (this does
    not mean that they did not spend another 3h per week on the
    exercises, though;-).
    About 2/3 of this time focused on C89 and C99 and the other third
    went into tools and optimisation (basic<->algorithmic).
    If I had to teach the course again, I would stress modularisation
    even more (I mentioned it essentially thrice but people did not
    take to structuring their solutions without some force :-( ).


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Nov 27, 2005
    #9
  10. pemo

    Malcolm Guest

    "pemo" <> wrote
    > It's not so much as what I'm looking for, as I have to put this course
    > together.
    >
    > Of course, I realise that recursion is a general programming technique
    > (having used Haskell for many years, I find looping any other way a bit
    > weird), and I included it here purely as it's something that *some* people
    > have a great deal of trouble getting to grips with - as some do unions and
    > things like bit-fields.
    >

    If the students need a course to learn C then they will also be newbies to
    programming. So it makes sense to teach basic algorithms at the same time as
    the language, and not worry too much about the difference. (Just as school
    history is both about a specific period and about the difference between
    primary and secondary evidence).
    >
    >> It's hard for me to imagine a responsibly-taught course
    >> that omitted unions and bit-fields. Even a very short course
    >> of half a dozen lectures should at least mention them, even
    >> if it didn't spend time on them. But the follow-on course
    >> to "Baby Steps in C" wouldn't be characterized as "advanced,"
    >> would it?

    >
    > That's interesting, as I've just taught two C courses (for a total of
    > seven weeks (7 * 3 hour sessions)) [4 weeks on an intro, 3 on a 'further'
    > course], and I haven't introduced unions or bit-fields yet. However, I'm
    > now putting together two three hour sessions on some more topics - and
    > thus the question as to what to include on this.
    >

    You should try to introduce the whole of the language as early as possible,
    and encourage students to explore the quirks themselves. If you removed
    unions and bitfields from C you would still have a perfectly serviceable
    language, and in fact they are relatively rarely used. However students must
    know about them, so that they can read arbitrary C.
    >
    > Off the top of my head, here are some other things that are on my general
    > candidate list [knowing the audience (mostly Oxford grad students)] - some
    > to do with general programming things, others to do more with C ...
    >

    I did a graduate course in programming at Oxford (Snobol). I was actually an
    undergrad at the time.
    >
    > function pointers and signal() etc.
    >

    fair enough. signal() isn't portable.
    >
    > defensive programming techniques.
    >

    The problem with this is that defensive programming easily turns into
    masking errors.
    >
    > mixing in assembler with C.
    >

    fair enough. Do the students know an assembly lanugage, though?
    >
    > writing modular code, using your own header files effectively.
    >

    Very valuable. priority for a second course. Again, hard to teach.
    >
    > data-structures - like linked-lists, trees and graphs.
    >

    Keep it to the simplest structures. Otherwise you go too far down the
    general programming route.
    >
    > keywords like _Bool, restrict, register, ...
    >

    make sure you teach the difference between ANSI and non-ANSI C. I think most
    of these just need a brief mention, except perhaps restrict, but then you
    are going from C to the pointer alias problem and general language design
    issues.
    >
    > more on manipulating strings (strtok(), etc).
    >

    Don't teach these. Set them as exercises (implement strlen(), strtok(), then
    get more ambitious, like a reduced sprintf(), a wildcard globber, natural
    language parser).
    >
    > interacting with the operating system.
    >

    No. Too platform specific (except for loading and saving files, of course).
    >
    > debugging using gdb etc.
    >

    Up to you. personally I hate debuggers, but that is partly because I write
    code for lots of differnet targets, and so learning the debugger means
    starting over each time.
    >
    > source control.
    >

    Too far away from C. Also, you need a really big project before the benfits
    become obvious
    >
    > lint.
    >

    Hate it. Most compilers are so good with warnings now that there is no real
    need.
    >
    > using thrid party libraries [for stats].
    >

    Absolutely essential.
    >
    > btw, I'd be happy to provide *some* folks with a pdf of the courses I've
    > already put-together/taught - in return for their opinion on their
    > quality/correctness. If you're interested, please email me -
    > peet[padding]m at cslab.com. But, you have to be kind!
    >
    >

    Good luck.
     
    Malcolm, Nov 27, 2005
    #10
  11. pemo

    Malcolm Guest

    "pemo" <> wrote
    >
    > However, I've [these days] rarely encountered unions in live code, or in
    > finding I'm using a library that requires them etc. So, are unions
    > something that ppl. find they deal with as commonly as, say, structs?

    Almost never.
    The main use of a union is to define a data "packet" for some type of
    messaging system. However normally you want such messages passed over a
    wire, so they need to be serialised, and unions are not a portable way of
    doing that. So instead you specify the messge format byte byte byte, and
    then unpack.
     
    Malcolm, Nov 27, 2005
    #11
  12. pemo

    Eric Sosman Guest

    pemo wrote:
    > [...]
    >
    > Off the top of my head, here are some other things that are on my general
    > candidate list [knowing the audience (mostly Oxford grad students)] - some
    > to do with general programming things, others to do more with C ...
    >
    > function pointers and signal() etc.
    >
    > defensive programming techniques.
    >
    > mixing in assembler with C.
    >
    > writing modular code, using your own header files effectively.
    >
    > data-structures - like linked-lists, trees and graphs.
    >
    > keywords like _Bool, restrict, register, ...
    >
    > more on manipulating strings (strtok(), etc).
    >
    > interacting with the operating system.
    >
    > debugging using gdb etc.
    >
    > source control.
    >
    > lint.
    >
    > using thrid party libraries [for stats].


    Of these, the only unequivocally "about C" items are
    the first and sixth, with a possible nod to the seventh.
    The other nine or nine and a half are not about C at all
    (no, not even the third). That's not to say it couldn't
    be a useful course, but "Advanced C" isn't the title I'd
    give it.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Nov 27, 2005
    #12
  13. pemo

    Marc Boyer Guest

    Eric Sosman <> wrote:
    > It's hard for me to imagine a responsibly-taught course
    > that omitted unions and bit-fields. Even a very short course
    > of half a dozen lectures should at least mention them, even
    > if it didn't spend time on them.


    Why ?
    What is the benefit of union, except memory saving and
    some advanced POO-like programming technics ?
    And with bit-fields, what is the use except on some
    raw I/O, where endianess, sign encoding, bit padding and
    memory alignements are also needed ?

    Marc Boyer
     
    Marc Boyer, Nov 28, 2005
    #13
  14. pemo

    Ingo Menger Guest

    Marc Boyer schrieb:

    > Eric Sosman <> wrote:
    > > It's hard for me to imagine a responsibly-taught course
    > > that omitted unions and bit-fields. Even a very short course
    > > of half a dozen lectures should at least mention them, even
    > > if it didn't spend time on them.

    >
    > Why ?
    > What is the benefit of union, except memory saving and
    > some advanced POO-like programming technics ?


    They are almost indespensable for implementing sum data types (as
    opposed to product data types which are often implemented using
    structs).
    For example:

    enum literalkind { Float, Int, Char };
    struct literal {
    enum literalkind kind;
    union {
    float u_flt;
    int u_int;
    char u_chr;
    } l_val;
    };
     
    Ingo Menger, Nov 28, 2005
    #14
  15. pemo

    Marc Boyer Guest

    Ingo Menger <> wrote:
    > Marc Boyer schrieb:
    >> Eric Sosman <> wrote:
    >> > It's hard for me to imagine a responsibly-taught course
    >> > that omitted unions and bit-fields. Even a very short course
    >> > of half a dozen lectures should at least mention them, even
    >> > if it didn't spend time on them.

    >>
    >> Why ?
    >> What is the benefit of union, except memory saving and
    >> some advanced POO-like programming technics ?

    >
    > They are almost indespensable for implementing sum data types (as
    > opposed to product data types which are often implemented using
    > structs).
    > For example:
    >
    > enum literalkind { Float, Int, Char };
    > struct literal {
    > enum literalkind kind;
    > union {
    > float u_flt;
    > int u_int;
    > char u_chr;
    > } l_val;
    > };


    Yes, but how often are 'sum data types' usefull ?
    I am in the context of 'a very short course'.
    My opinion (can be discussed) is that, in real life,
    when unions are needed, then so many others also are that
    this is no more for beginners.

    Marc Boyer
     
    Marc Boyer, Nov 28, 2005
    #15
  16. pemo

    Eric Sosman Guest

    Marc Boyer wrote:
    > Eric Sosman <> wrote:
    >
    >> It's hard for me to imagine a responsibly-taught course
    >>that omitted unions and bit-fields. Even a very short course
    >>of half a dozen lectures should at least mention them, even
    >>if it didn't spend time on them.

    >
    >
    > Why ?
    > What is the benefit of union, except memory saving and
    > some advanced POO-like programming technics ?
    > And with bit-fields, what is the use except on some
    > raw I/O, where endianess, sign encoding, bit padding and
    > memory alignements are also needed ?


    IMHO, a responsibly-taught C course would cover gets().
    I do not advocate using gets(), but if the neophyte programmer
    has never been taught to recognize it and warned against it,
    he has not been prepared against a serious peril.

    Similarly with unions: Their legitimate uses are few,
    but their hackish uses are frequent. The programmer will
    certainly encounter unions, and will have been ill-prepared
    if the course never mentioned them.

    Let me turn the question around: If you were preparing
    a course on C, what features would you omit altogether?
    Would you omit `do...while'? It's infrequently used, after
    all. How about `goto'? It's even rarer, yet your students
    will eventually run into it. `longjmp'? I hope you'd at
    least mention that it exists, perhaps with a caution that
    it's tricky to use well. `long double'? `<stdarg.h>'?
    `continue'?

    I'm not saying that an introductory course should cover
    all such matters in great detail. More attention should be
    paid to mundane matters, like how `switch' works or why it's
    a bad idea to return a pointer to an `auto' variable. But
    even an introductory course ought to erect a few signposts
    to describe the unexplored territory, so the graduate will not
    be utterly lost when he parachutes into it.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Nov 28, 2005
    #16
  17. pemo

    Marc Boyer Guest

    Le 28-11-2005, Eric Sosman <> a écrit :
    > Marc Boyer wrote:
    >> Eric Sosman <> wrote:
    >>
    >>> It's hard for me to imagine a responsibly-taught course
    >>>that omitted unions and bit-fields. Even a very short course
    >>>of half a dozen lectures should at least mention them, even
    >>>if it didn't spend time on them.

    >>
    >>
    >> Why ?
    >> What is the benefit of union, except memory saving and
    >> some advanced POO-like programming technics ?
    >> And with bit-fields, what is the use except on some
    >> raw I/O, where endianess, sign encoding, bit padding and
    >> memory alignements are also needed ?

    >
    > IMHO, a responsibly-taught C course would cover gets().
    > I do not advocate using gets(), but if the neophyte programmer
    > has never been taught to recognize it and warned against it,
    > he has not been prepared against a serious peril.


    Why presenting gets() if fgets() is presented ?
    man gets

    > Similarly with unions: Their legitimate uses are few,
    > but their hackish uses are frequent. The programmer will
    > certainly encounter unions, and will have been ill-prepared
    > if the course never mentioned them.


    Yes, but in a limited teaching time, must we spend time
    to describe hacks or good practices ?

    > Let me turn the question around: If you were preparing
    > a course on C, what features would you omit altogether?


    I am teaching C.

    > Would you omit `do...while'? It's infrequently used, after
    > all.


    Yes, but this is a 0-overhead since the notion have been
    presented with Pascal.

    > How about `goto'? It's even rarer, yet your students
    > will eventually run into it.


    Not presented.

    > `longjmp'? I hope you'd at
    > least mention that it exists, perhaps with a caution that
    > it's tricky to use well.


    Neither.

    > `long double'?


    Yes, also a 0 overhead notion (float, double, long-double).

    > `<stdarg.h>'?, `continue'?


    No

    > I'm not saying that an introductory course should cover
    > all such matters in great detail. More attention should be
    > paid to mundane matters, like how `switch' works or why it's
    > a bad idea to return a pointer to an `auto' variable. But
    > even an introductory course ought to erect a few signposts
    > to describe the unexplored territory, so the graduate will not
    > be utterly lost when he parachutes into it.


    My choice is (but can be discussed) is that there is a
    lot of C documentation (and some is given), and I prefer to
    takes time on usefull and hard notions, and rely on the
    adaptation capacity of the students for the others.
    With any C documentation with an index, you can understand
    what 'continue' does. With sizeof, malloc and others,
    this is not the case.

    Marc Boyer
     
    Marc Boyer, Nov 28, 2005
    #17
  18. pemo

    pemo Guest

    "Eric Sosman" <> wrote in message
    news:...
    > Marc Boyer wrote:
    >> Eric Sosman <> wrote:
    >>
    >>> It's hard for me to imagine a responsibly-taught course
    >>>that omitted unions and bit-fields. Even a very short course
    >>>of half a dozen lectures should at least mention them, even
    >>>if it didn't spend time on them.

    >>
    >>
    >> Why ?
    >> What is the benefit of union, except memory saving and
    >> some advanced POO-like programming technics ?
    >> And with bit-fields, what is the use except on some
    >> raw I/O, where endianess, sign encoding, bit padding and memory
    >> alignements are also needed ?

    >
    > IMHO, a responsibly-taught C course would cover gets().
    > I do not advocate using gets(), but if the neophyte programmer
    > has never been taught to recognize it and warned against it,
    > he has not been prepared against a serious peril.
    >
    > Similarly with unions: Their legitimate uses are few,
    > but their hackish uses are frequent. The programmer will
    > certainly encounter unions, and will have been ill-prepared
    > if the course never mentioned them.
    >
    > Let me turn the question around: If you were preparing
    > a course on C, what features would you omit altogether?
    > Would you omit `do...while'? It's infrequently used, after
    > all. How about `goto'? It's even rarer, yet your students
    > will eventually run into it. `longjmp'? I hope you'd at
    > least mention that it exists, perhaps with a caution that
    > it's tricky to use well. `long double'? `<stdarg.h>'?
    > `continue'?
    >
    > I'm not saying that an introductory course should cover
    > all such matters in great detail. More attention should be
    > paid to mundane matters, like how `switch' works or why it's
    > a bad idea to return a pointer to an `auto' variable. But
    > even an introductory course ought to erect a few signposts
    > to describe the unexplored territory, so the graduate will not
    > be utterly lost when he parachutes into it.


    Good points from everyone - thanks for the input/effort so far.

    FYI, I have included gets(), buffer-overruns, fgets(), do ... while and
    goto! However, I'm sure that I ought to have included some things that I've
    recently realised are missing, e.g., I haven't mentioned enums yet, or
    returning the address of a frame variable (or unions, bit-fields ...)!

    However, it's hard to get *everything in* that perhaps ought to be - esp.
    true if you yourself don't frequently use some features. E.g., I rarely use
    enums/unions or *goto* etc BTW, the goto appeared [as an aside] when we
    were looking at loops.

    The difficulty in the development of this course has been slightly
    compounded by the fact that I originally 'inherited' it. I've spent two
    terms re-doing many parts of it (as well as doing my own research stuff),
    but it's very far from perfect. Even further hampered by the fact that my
    serious usage of C predates the latest stuff, esp. c99 - c.l.c has been
    invaluable here!

    Lastly, if every student took both courses, they'd have 21 hours of
    tutorials and practicals - it's rather hard [frightening] to think that
    they'll be let loose on department code after such a short time: so, it's
    even more important to only include useful stuff (maybe goto should go!!)
     
    pemo, Nov 28, 2005
    #18
  19. pemo

    Ingo Menger Guest

    Marc Boyer schrieb:

    > Ingo Menger <> wrote:
    > > Marc Boyer schrieb:
    > >> Eric Sosman <> wrote:
    > >> > It's hard for me to imagine a responsibly-taught course
    > >> > that omitted unions and bit-fields. Even a very short course
    > >> > of half a dozen lectures should at least mention them, even
    > >> > if it didn't spend time on them.
    > >>
    > >> Why ?
    > >> What is the benefit of union, except memory saving and
    > >> some advanced POO-like programming technics ?

    > >
    > > They are almost indespensable for implementing sum data types (as
    > > opposed to product data types which are often implemented using
    > > structs).



    > Yes, but how often are 'sum data types' usefull ?


    Hmmm...
    I'd say, before I learned the concept through Haskell (where they are
    known as algebraic data types), I didn't use them at all. Nowadays I
    find myself cursing the dumb and stupid language I have to work with,
    and that doesn't have them, such as for example java.

    It's quite comparable to class types and object oriented programming.
    How often were objects useful in the seventies and eighties? But today,
    everything ought to be an object. :)

    > My opinion (can be discussed) is that, in real life,
    > when unions are needed, then so many others also are that
    > this is no more for beginners.


    Sure, but the topic is "Advanced C".
    And certainly, unions deserve much more attention than, for example
    bitfields. Whereas the former is an concept that supports advanced
    (altough rarely known) programming paradigms, the latter is just
    another way of storing a bunch of unsigned numbers using less space.
     
    Ingo Menger, Nov 28, 2005
    #19
  20. pemo

    Marc Boyer Guest

    Ingo Menger <> wrote:
    > Marc Boyer schrieb:
    >> Ingo Menger <> wrote:
    >> > Marc Boyer schrieb:
    >> >> Eric Sosman <> wrote:
    >> >> > It's hard for me to imagine a responsibly-taught course
    >> >> > that omitted unions and bit-fields. Even a very short course
    >> >> > of half a dozen lectures should at least mention them, even
    >> >> > if it didn't spend time on them.
    >> >>
    >> >> Why ?
    >> >> What is the benefit of union, except memory saving and
    >> >> some advanced POO-like programming technics ?
    >> >
    >> > They are almost indespensable for implementing sum data types (as
    >> > opposed to product data types which are often implemented using
    >> > structs).

    >> Yes, but how often are 'sum data types' usefull ?

    > Hmmm...
    > I'd say, before I learned the concept through Haskell (where they are
    > known as algebraic data types), I didn't use them at all. Nowadays I
    > find myself cursing the dumb and stupid language I have to work with,
    > and that doesn't have them, such as for example java.


    OK, but can't you do the same with dynamic polymorphism ?

    And, since we are on clc, which use in C ?

    >> My opinion (can be discussed) is that, in real life,
    >> when unions are needed, then so many others also are that
    >> this is no more for beginners.

    >
    > Sure, but the topic is "Advanced C".


    I could have changed the subject, but I was answering
    a post on 'Even a very short course [...] should at least
    mention them'.

    > And certainly, unions deserve much more attention than, for example
    > bitfields. Whereas the former is an concept that supports advanced
    > (altough rarely known) programming paradigms, the latter is just
    > another way of storing a bunch of unsigned numbers using less space.


    Yes

    Marc Boyer
     
    Marc Boyer, Nov 28, 2005
    #20
    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. Eric
    Replies:
    0
    Views:
    2,158
  2. Benjamin Todd

    Advanced Synthesis Techniques

    Benjamin Todd, May 13, 2005, in forum: VHDL
    Replies:
    4
    Views:
    1,063
    Ben Twijnstra
    May 16, 2005
  3. Brandon
    Replies:
    0
    Views:
    437
    Brandon
    Jul 11, 2005
  4. Replies:
    4
    Views:
    544
    Mike Treseler
    Feb 4, 2006
  5. Michele Simionato
    Replies:
    1
    Views:
    607
    Lacrima
    Mar 27, 2010
Loading...

Share This Page