Engineering a list container. Part 1.

Discussion in 'C Programming' started by jacob navia, Dec 7, 2013.

  1. A Turing machine can't do IO. It just shuffles bits. That's why I always
    emphasise separating bit shuffling functions from IO. Then everything works
    nicely, you don't have these problems of needing destructors that do anything
    other than free memory, and you don't have any error conditions except out
    of memory.
     
    Malcolm McLean, Dec 24, 2013
    #61
    1. Advertisements

  2. jacob navia

    Ian Collins Guest

    So your applications live in a snow globe?
     
    Ian Collins, Dec 24, 2013
    #62
    1. Advertisements

  3. Basically yes.

    The clever part of the program, which takes all the hard work to write, takes
    one pattern of bits, and shuffles it about. Sometimes it returns a new pattern
    of bits, sometimes it modifies the original one, that's just a minor detail.

    These bit shuffling functions ideally go in separate source files. There's no
    reason ever to use non-portable constructs, except for silly marginal cases
    like expecting eight bits in an unsigned char where the portable version is
    fiddly and provides no practical benefit. There in C. Anything that supports
    call to C can set up one pattern of bits, call them, and get back the resulting
    pattern of bits.
    The patterns are of course human-meaningful in almost all cases. They might
    represent an empty crossword grid and a list of English words, and the output
    is a filled grid with interlocking words. But the computer doesn't know it's
    creating a crossword. All it sees is bits it has to shuffle about until it
    reaches a situation where there are no blank cells and every continuous line
    of more than one cell matches one of the patterns in the list.

    That then has to be hooked up to IO so that you can see the result. This is
    usually pretty trivial if you've got a decent IO library. Writing a decent
    IO library isn't trivial of course, it's difficult in a different way. Baby X
    is an example of an IO library.
     
    Malcolm McLean, Dec 24, 2013
    #63
  4. jacob navia

    Eric Sosman Guest

    ... and when they're not in a state of chaos, they're down. ;-)
     
    Eric Sosman, Dec 24, 2013
    #64
  5. jacob navia

    Ian Collins Guest

    Unfortunately some of us have to write dumb, easy to write programmes
    that interface with the real world. One of these days I might be lucky
    enough to move on to clever snow globe programmes.
     
    Ian Collins, Dec 25, 2013
    #65
  6. As far as I know, many compilers will use FSQRT in place of a
    call to sqrt(). Presumably if no reference to errno is in sight.

    I am not sure how far away you would put a reference to errno
    for the compiler to notice.
    More interesting is to use FSINCOS in place of calls to sin().
    For large enough values, it just leaves the value on the stack,
    which could be surprising to some.

    -- glen
     
    glen herrmannsfeldt, Dec 25, 2013
    #66
  7. jacob navia

    jacob navia Guest

    Le 25/12/2013 03:48, Ian Collins a écrit :
    Obviously C++ is the answer for that.

    I would recommend you then, that you do not visit C related groups and
    stick to the C++ group that is very easy to find.

    Why do you participate in a C language group if C++ is so good?


    Obviously you want to "preach the good word" here. Convince those
    backwards C programmers that they are dead wrong and that C++ is the
    alpha and omega of software engineering.

    Please do that in other groups.

    Can't you go to comp.lang.assembly.x86?

    Try to convince those guys that assembly is OUT :)

    Or to comp.lang.Fortran?

    :)
     
    jacob navia, Dec 25, 2013
    #67
  8. jacob navia

    Ian Collins Guest

    Where did I mention C++ in the message you quoted?
     
    Ian Collins, Dec 25, 2013
    #68
  9. jacob navia

    James Kuyper Guest

    errno acts like a global variable - checking the value of errno could
    occur in a different translation unit from the sqrt() call, so the
    compiler alone does not, in general, have enough information to perform
    such an optimization.
     
    James Kuyper, Dec 26, 2013
    #69
  10. jacob navia

    James Kuyper Guest

    On 12/26/2013 11:58 AM, James Kuyper wrote:
    ....
    Note: as of C2011, it's thread-local, not global - which doesn't affect
    my conclusions.
     
    James Kuyper, Dec 26, 2013
    #70
  11. jacob navia

    Öö Tiib Guest

    Standard has such footnote: "Thus, a program that uses errno for error
    checking should set it to zero before a library function call, then inspect
    it before a subsequent library function call."

    There certainly can be case when it is hard to decide but in common
    code it does not take rocket science to detect that the program does
    not behave like said above between subsequent library function calls.
     
    Öö Tiib, Dec 26, 2013
    #71
  12. jacob navia

    Eric Sosman Guest

    The compiler can (or should) be able to discern many cases
    in which `errno' is clearly not being inspected. My example was

    y = sqrt(x); // might set errno
    // errno not inspected here
    z = log(y); // might set errno

    Any program that's interested in the `errno' output from sqrt()
    and fails to examine it before calling log() is erroneous. The
    implementation is not obliged to set `errno' as part of sqrt()
    only to see it overwritten as part of log().

    Your observation is valid for any `errno' value produced
    by log(), unless the context includes further library calls
    that might contaminate it in turn.

    It appears to be less well known that almost any library
    function may change `errno', even those that don't actually
    encounter any errors. FAQ 12.24 explains one such example.
    Another anti-pattern one occasionally sees goes something like

    stream = fopen(filename, "r");
    if (stream == NULL) {
    perror(filename);
    return errno;
    }

    .... where an `errno' from an fopen() failure (if there is one;
    fopen() is not required to set `errno' though many versions do)
    may have been overwritten during perror(). If the idea is to
    return fopen()'s `errno' value, use something like

    if (stream == NULL) {
    int errno_save = errno;
    perror(filename);
    return errno_save;
    }
     
    Eric Sosman, Dec 26, 2013
    #72
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.