Re: programi parsing question

Discussion in 'C Programming' started by fjblurt@yahoo.com, Aug 6, 2008.

  1. Guest

    Crossposting this to comp.lang.c because it's become relevant.

    Our story so far, for c.l.c people:

    There is a discussion about the stylistic advantages and disadvantages
    of the following two snippets:

    void foo (void) {
    int fd;
    if ((fd = open(...)) < 0) {
    fail();
    }
    }

    versus

    void foo (void) {
    int fd = open(...);
    if (fd < 0) {
    fail();
    }
    }

    Phlip prefers the latter, and claims that the former gained popularity
    because early versions of C did not guarantee the order in which
    initializations occurred, or had other problems, and therefore
    initializations in declarations were discouraged.

    On Aug 5, 6:22 pm, Phlip <> wrote:
    > K-mart Cashier wrote:
    > > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)

    >
    > > is a common found in both "The C Programming Language" by K & R and
    > > the FreeBSD source code.

    >
    > If they all just jumped off a cliff, would you?
    >
    > Seriously, the style is a legacy of days when C could not initialize reliably.


    Do you have a specific example? K&R, first edition, doesn't seem to
    address the issue of order specifically, but does say (appendix A,
    section 8.6): "Automatic or register variables may be initialized by
    arbitrary expressions involving constants, and previously declared
    variables and functions." This would seem to imply that previously
    declared variables would already have been initialized.

    On the other hand, section 4.9 gives two examples:

    binary(x, v, n)
    int x, v[], n;
    {
    int low = 0;
    int high = n - 1;
    int mid;
    ...
    }

    and

    binary(x, v, n)
    int x, v[], n;
    {
    int low, high, mid;

    low = 0;
    high = n - 1;
    ...
    }

    and then goes on to say:

    "In effect, initializations of automatic variables are just shorthand
    for assignment statements. Which form to prefer is largely a matter
    of taste. We have generally used explicit assignments, because
    initializers in declarations are harder to see."

    So it would appear that the reason K&R avoid using initializers was
    not because there was something wrong with the way they worked, but
    just for stylistic reasons, because they thought it was more readable
    that way. (I tend to agree.)

    For an assignment like our example that involves a nontrivial function
    call, I think most people would not expect to see it in an
    initializer, because oftentimes nontrivial function calls will require
    more computations to be done first, even though this example happens
    not to.

    So that leaves us the choice of

    int fd;
    ....
    if ((fd = open(...)) < 0) fail();

    or

    int fd;
    ....
    fd = open(...);
    if (fd < 0) fail();

    and the latter needs an extra line.

    C99 gives us the option not to declare fd until just before we need
    it, so we could write

    .... lots of stuff ...
    int fd = open(...);
    if (fd < 0) fail();

    but *that* is a relatively recent invention, and not necessarily
    universally available.

    > The style's only redeeming characteristic is you only need to read the big words
    > - "if open PATH_UTMP", and you can scan over the rest and know by sight-reading
    > they are the common open-a-file-and-fail-gracefully idiom.


    That's a significant advantage, IMHO.
     
    , Aug 6, 2008
    #1
    1. Advertising

  2. CBFalconer Guest

    wrote:
    >
    > Crossposting this to comp.lang.c because it's become relevant.
    >
    > Our story so far, for c.l.c people:
    >
    > There is a discussion about the stylistic advantages and
    > disadvantages of the following two snippets:
    >
    > void fooA(void) {
    > int fd;
    > if ((fd = open(...)) < 0) {
    > fail();
    > }
    > }
    >
    > versus
    >
    > void fooB(void) {
    > int fd = open(...);
    > if (fd < 0) {
    > fail();
    > }
    > }


    Considering the crosspost, I won't complain about using the
    non-standard open in place of fopen. However it is inappropriate
    on comp.programming.

    I have renamed the two functions. I consider fooA superior. I
    disapprove of initialization code more complex than a simple value,
    such as 0, and discourage even that. fooB must generate a call to
    open, so it must generate code for that. That code is hidden from
    the reader.

    The only place, IMO, where initialization code is justified is
    where the variable has the const characteristic applied. Then it
    is necessary to install a value.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Aug 6, 2008
    #2
    1. Advertising

  3. santosh Guest

    CBFalconer wrote:
    > wrote:


    >> void fooB(void) {
    >> int fd = open(...);
    >> if (fd < 0) {
    >> fail();
    >> }
    >> }

    >
    > Considering the crosspost, I won't complain about using the
    > non-standard open in place of fopen. However it is inappropriate
    > on comp.programming.


    You surely mean comp.lang.c?

    <snip>
     
    santosh, Aug 6, 2008
    #3
  4. Chris Dollin Guest

    CBFalconer wrote:

    > I have renamed the two functions. I consider fooA superior. I
    > disapprove of initialization code more complex than a simple value,
    > such as 0, and discourage even that.


    You're bonkers.

    Why /not/ initialise a variable when you declare it, with the value
    you want it to have?

    --
    'It changed the future .. and it changed us.' /Babylon 5/

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
     
    Chris Dollin, Aug 6, 2008
    #4
  5. Chris Torek Guest

    In article <>
    <> wrote:
    >There is a discussion about the stylistic advantages and disadvantages
    >of the following two snippets:


    [I did some editing in the quotes below, to be able to talk about
    them better later.]

    >void foo_set_and_test (void) {
    > int fd;
    > if ((fd = open(...)) < 0) {
    > fail();
    > }
    >}
    >
    >versus
    >
    >void foo_init_and_then_test_separately (void) {
    > int fd = open(...);
    > if (fd < 0) {
    > fail();
    > }
    >}
    >
    >Phlip prefers the latter, and claims that the former gained popularity
    >because early versions of C did not guarantee the order in which
    >initializations occurred,


    As far as I know, no version of C, no matter how early and
    not-even-K&R-1-compliant, did initializations in any order other
    than "as they appear in the source". So:

    void func(void) {
    int a = init_a();
    char *b = init_b();
    double c = init_c(), d = init_d();
    ...
    }

    will always call init_a() first, then init_b(), then init_c(), then
    init_d(), even in truly ancient implementations.

    I have a slight preference for foo_init_and_then_test_separately()
    myself, but this is a matter of taste. There is even a third
    option:

    void foo_set_and_then_test_separately(void) {
    int fd;

    fd = open(...);
    if (fd < 0) {
    fail();
    ...
    }
    ...
    }

    which I slightly prefer over foo_init_and_then_test_separately()
    (but only *very* slightly).

    >[K&R-1] then goes on to say:
    >
    >"In effect, initializations of automatic variables are just shorthand
    >for assignment statements. Which form to prefer is largely a matter
    >of taste. We have generally used explicit assignments, because
    >initializers in declarations are harder to see."
    >
    >So it would appear that the reason K&R avoid using initializers was
    >not because there was something wrong with the way they worked, but
    >just for stylistic reasons, because they thought it was more readable
    >that way. (I tend to agree.)


    As do I -- and I separate out the assignment and test when possible
    as well, for the same reason. I will cram them together in
    some cases, such as inside the control expression of a loop:

    while ((c = getchar()) != EOF) {
    ...
    }

    because, while this is a bit hard to read, it is still easier to
    read than the two obvious alternatives:

    c = getchar();
    while (c != EOF) {
    ...
    c = getchar();
    }

    (which duplicates the "get a character" action, creating opportunities
    for getting things wrong during code maintenance -- perhaps getchar()
    needs to be replaced by get_from_file_while_maintaining_line_number()
    or similar; and "continue" inside the loop is now bad), or:

    while (c = getchar(), c != EOF) {
    ...
    }

    (which is readable but unusual, and requires duplicating the variable
    name). If this last alternative were more commonly found in other
    C code, I might use it, so this particular preference is more
    historical than anything else.

    Again, though, all of this is largely a matter of taste. Arguing
    about it is like arguing whether raspberry ice cream is superior
    to peach ice cream. (Answer: neither, chocolate is better :) )
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: gmail (figure it out) http://web.torek.net/torek/index.html
     
    Chris Torek, Aug 6, 2008
    #5
  6. santosh Guest

    Chris Torek wrote:
    > In article
    > <>
    > <> wrote:


    <snip>

    >>[K&R-1] then goes on to say:
    >>
    >>"In effect, initializations of automatic variables are just shorthand
    >>for assignment statements. Which form to prefer is largely a matter
    >>of taste. We have generally used explicit assignments, because
    >>initializers in declarations are harder to see."
    >>
    >>So it would appear that the reason K&R avoid using initializers was
    >>not because there was something wrong with the way they worked, but
    >>just for stylistic reasons, because they thought it was more readable
    >>that way. (I tend to agree.)

    >
    > As do I -- and I separate out the assignment and test when possible
    > as well, for the same reason. I will cram them together in
    > some cases, such as inside the control expression of a loop:
    >
    > while ((c = getchar()) != EOF) {
    > ...
    > }
    >
    > because, while this is a bit hard to read, it is still easier to
    > read than the two obvious alternatives:
    >
    > c = getchar();
    > while (c != EOF) {
    > ...
    > c = getchar();
    > }
    >
    > (which duplicates the "get a character" action, creating opportunities
    > for getting things wrong during code maintenance -- perhaps getchar()
    > needs to be replaced by get_from_file_while_maintaining_line_number()
    > or similar; and "continue" inside the loop is now bad), or:
    >
    > while (c = getchar(), c != EOF) {
    > ...
    > }
    >
    > (which is readable but unusual, and requires duplicating the variable
    > name).


    One other possibility:

    for (c = getchar(); c != EOF; c = getchar()) { ... }

    In general I have found that code consisting of (as far as is feasible)
    simple expressions is better adaptable to restructuring and change than
    code with lot of complex expressions. It's much like taking apart a car
    made of Lego blocks versus a real one. Of course all code can't use
    Lego blocks, but where possible...

    <snip>
     
    santosh, Aug 6, 2008
    #6
  7. CBFalconer Guest

    santosh wrote:
    > CBFalconer wrote:
    >> wrote:

    >
    >>> void fooB(void) {
    >>> int fd = open(...);
    >>> if (fd < 0) {
    >>> fail();
    >>> }
    >>> }

    >>
    >> Considering the crosspost, I won't complain about using the
    >> non-standard open in place of fopen. However it is inappropriate
    >> on comp.programming.

    >
    > You surely mean comp.lang.c?


    No. My last sentence referred to the subject, not the open. My
    fault for failing to be sufficiently specific. The question about
    formatting was relevant on c.l.c.

    You have confused things by snipping and failing to mark the
    snipped area.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Aug 6, 2008
    #7
  8. Chris Torek <> writes:
    > <> wrote:
    >>There is a discussion about the stylistic advantages and disadvantages
    >>of the following two snippets:


    [...]

    >>void foo_set_and_test (void) {
    >> int fd;
    >> if ((fd = open(...)) < 0) {
    >> fail();
    >> }
    >>}


    [...]

    >>void foo_init_and_then_test_separately (void) {
    >> int fd = open(...);
    >> if (fd < 0) {
    >> fail();
    >> }
    >>}


    [...]

    > I have a slight preference for foo_init_and_then_test_separately()
    > myself, but this is a matter of taste. There is even a third
    > option:
    >
    > void foo_set_and_then_test_separately(void) {
    > int fd;
    >
    > fd = open(...);
    > if (fd < 0) {
    > fail();
    > ...
    > }
    > ...
    > }


    [...]

    > Again, though, all of this is largely a matter of taste. Arguing
    > about it is like arguing whether raspberry ice cream is superior
    > to peach ice cream.


    The last (two) variant(s) has(ve) the advantage that the value
    assigned to fd can be inspected and possibly changed by a human using
    a 'suitable tool' (debugger) before the program acts on it.
     
    Rainer Weikusat, Aug 6, 2008
    #8
  9. Phlip Guest

    Rainer Weikusat wrote:

    > Chris Torek writes:


    >> int fd;
    >> fd = open(...);


    >> Again, though, all of this is largely a matter of taste. Arguing
    >> about it is like arguing whether raspberry ice cream is superior
    >> to peach ice cream.


    > The last (two) variant(s) has(ve) the advantage that the value
    > assigned to fd can be inspected and possibly changed by a human using
    > a 'suitable tool' (debugger) before the program acts on it.


    I suspect there are style guidelines saying "always initialize every variable".
    Maybe they only apply to C++, and C is exempt.

    --
    Phlip
     
    Phlip, Aug 6, 2008
    #9
  10. santosh Guest

    Phlip wrote:

    > Rainer Weikusat wrote:
    >
    >> Chris Torek writes:

    >
    >>> int fd;
    >>> fd = open(...);

    >
    >>> Again, though, all of this is largely a matter of taste. Arguing
    >>> about it is like arguing whether raspberry ice cream is superior
    >>> to peach ice cream.

    >
    >> The last (two) variant(s) has(ve) the advantage that the value
    >> assigned to fd can be inspected and possibly changed by a human using
    >> a 'suitable tool' (debugger) before the program acts on it.

    >
    > I suspect there are style guidelines saying "always initialize every
    > variable". Maybe they only apply to C++, and C is exempt.


    That cannot be, unless C forbids initialising every variable, which it
    doesn't. In the dim and distant past I suppose variable redundant
    initialisations were avoided due to efficiency concerns. These no
    longer matter now, but some still prefer to avoid redundant
    initialisations as an aesthetic choice.
     
    santosh, Aug 6, 2008
    #10
  11. Willem Guest

    Phlip wrote:
    ) I suspect there are style guidelines saying "always initialize every variable".
    ) Maybe they only apply to C++, and C is exempt.

    On the other hand, explicitly not initializing variables give static code
    analyzers the chance to find uses of uninitialized variables. (As opposed
    to uses of default-but-wrong-initialized values).


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
     
    Willem, Aug 6, 2008
    #11
  12. Guest

    On Aug 6, 5:49 am, CBFalconer <> wrote:
    > santosh wrote:
    > > CBFalconer wrote:
    > >> wrote:

    >
    > >>> void fooB(void) {
    > >>> int fd = open(...);
    > >>> if (fd < 0) {
    > >>> fail();
    > >>> }
    > >>> }

    >
    > >> Considering the crosspost, I won't complain about using the
    > >> non-standard open in place of fopen. However it is inappropriate
    > >> on comp.programming.

    >
    > > You surely mean comp.lang.c?

    >
    > No. My last sentence referred to the subject, not the open. My
    > fault for failing to be sufficiently specific. The question about
    > formatting was relevant on c.l.c.


    Insofar as this is a discussion about programming style, which applies
    to any language which allows variables to be initialized, it seemed to
    me that it was still on-topic for comp.programming. I agree that the
    behavior of historical versions of C is not.

    Non-c.u.p readers worried about the `open' function may read it as an
    arbitrary function returning `int', which has significant side
    effects, and for which a negative return value indicates some
    unspecified sort of "failure". The choice of 'fd' for the variable
    holding its return value is likewise an arbitrary choice. Any
    similarity to actual functions, living or dead, is purely
    coincidental. :)
     
    , Aug 6, 2008
    #12
  13. santosh Guest

    wrote:

    > On Aug 6, 5:49 am, CBFalconer <> wrote:
    >> santosh wrote:
    >> > CBFalconer wrote:
    >> >> wrote:

    >>
    >> >>> void fooB(void) {
    >> >>> int fd = open(...);
    >> >>> if (fd < 0) {
    >> >>> fail();
    >> >>> }
    >> >>> }


    <snip>

    > Non-c.u.p readers worried about the `open' function may read it as an
    > arbitrary function returning `int', which has significant side
    > effects, [ ... ]


    Since these side effects have not been specified, nor are derivable from
    anything in the C Standard, the function effectively invokes undefined
    behaviour, and there is very little that can be said about the program,
    from that point onwards. Therefore the previous "non-portable" verdict
    now becomes "undefined" and thus, "no comment". :)

    <snip>
     
    santosh, Aug 6, 2008
    #13
  14. santosh <> writes:
    > wrote:
    >
    >> On Aug 6, 5:49 am, CBFalconer <> wrote:
    >>> santosh wrote:
    >>> > CBFalconer wrote:
    >>> >> wrote:
    >>>
    >>> >>> void fooB(void) {
    >>> >>> int fd = open(...);
    >>> >>> if (fd < 0) {
    >>> >>> fail();
    >>> >>> }
    >>> >>> }

    >
    > <snip>
    >
    >> Non-c.u.p readers worried about the `open' function may read it as an
    >> arbitrary function returning `int', which has significant side
    >> effects, [ ... ]

    >
    > Since these side effects have not been specified, nor are derivable from
    > anything in the C Standard, the function effectively invokes undefined
    > behaviour,


    Something which can be invoked is still necessarily defined.
    Indepedently of this, your statement means any use of an identifier
    not defined by the C-standard implies that the behaviour of the
    program using the identifier must be undefined, or shorter, that
    programming in C is not possible.

    Follow-up ignored for obvious reasons. Ludcicrous claims about C are
    (at best) on topic in clc.
     
    Rainer Weikusat, Aug 6, 2008
    #14
  15. santosh Guest

    Rainer Weikusat wrote:

    > santosh <> writes:
    >> wrote:
    >>
    >>> On Aug 6, 5:49 am, CBFalconer <> wrote:
    >>>> santosh wrote:
    >>>> > CBFalconer wrote:
    >>>> >> wrote:
    >>>>
    >>>> >>> void fooB(void) {
    >>>> >>> int fd = open(...);
    >>>> >>> if (fd < 0) {
    >>>> >>> fail();
    >>>> >>> }
    >>>> >>> }

    >>
    >> <snip>
    >>
    >>> Non-c.u.p readers worried about the `open' function may read it as
    >>> an arbitrary function returning `int', which has significant side
    >>> effects, [ ... ]

    >>
    >> Since these side effects have not been specified, nor are derivable
    >> from anything in the C Standard, the function effectively invokes
    >> undefined behaviour,

    >
    > Something which can be invoked is still necessarily defined.
    > Indepedently of this, your statement means any use of an identifier
    > not defined by the C-standard implies that the behaviour of the
    > program using the identifier must be undefined, or shorter, that
    > programming in C is not possible.


    I suppose you didn't not my smiley at the end?

    > Follow-up ignored for obvious reasons. Ludcicrous claims about C are
    > (at best) on topic in clc.


    Hmm, seems my newsreader added followups to c.u.p automatically. Am
    setting followups to clc, since this thread long ago ceased to be
    topical on cup.
     
    santosh, Aug 6, 2008
    #15
  16. Flash Gordon Guest

    wrote, On 06/08/08 05:38:
    > Crossposting this to comp.lang.c because it's become relevant.
    >
    > Our story so far, for c.l.c people:
    >
    > There is a discussion about the stylistic advantages and disadvantages
    > of the following two snippets:
    >
    > void foo (void) {
    > int fd;
    > if ((fd = open(...)) < 0) {
    > fail();
    > }
    > }
    >
    > versus
    >
    > void foo (void) {
    > int fd = open(...);
    > if (fd < 0) {
    > fail();
    > }
    > }
    >
    > Phlip prefers the latter, and claims that the former gained popularity
    > because early versions of C did not guarantee the order in which
    > initializations occurred, or had other problems, and therefore
    > initializations in declarations were discouraged.


    I also prefer the latter but cannot comment on the reasons why the
    former is often used. I refer the latter for the following reasons:

    I like initialising on declaration, no chance of using it uninitialised

    I like separating out assignment from test for readability

    This is purely personal preference. It is not something I would normally
    comment on either way when looking at code on comp.lang.c (although if
    providing an alternative piece of code I might use my preference).

    <snip>

    > For an assignment like our example that involves a nontrivial function
    > call, I think most people would not expect to see it in an
    > initializer,


    Well, they would be surprised by some of my code then :)

    > because oftentimes nontrivial function calls will require
    > more computations to be done first, even though this example happens
    > not to.


    <snip>

    struct vector required_thrust(struct pos mypos) {
    int x = funcky_function();
    int y = clever_stuff();
    int z = get_altitude();
    struct target_vector = calc_relative_pos(mypos,x,y,z)

    /* calculate and return thrust vector */
    }

    The "more computations to be done first" are not always a problem.
    --
    Flash Gordon
     
    Flash Gordon, Aug 6, 2008
    #16
  17. On Aug 6, 2:11 pm, Chris Dollin <> wrote:
    > CBFalconer wrote:
    > > ... I
    > > disapprove of initialization code more complex than a
    > > simple value, such as 0, and discourage even that.

    >
    > You're bonkers.


    Perhaps like the clock that ' s right twice a day ,CBF
    has the right idea on this issue :)
    .

    OP ' s question seems to be :which is less objectionable
    ? An initialization in the declaration section ,or an
    assignment embedded inside the predicate of an" if `
    .Obviously ,you needn ' t do either :you could consume
    an extra line of vertical space by placing variable
    declaration ,assignment ,and" if `all on separate
    lines
    .The code is almost the same in each case ,and very
    self - explanatory ;the only concerns ,therefore ,are
    ( minor )readability issues
    .Doing the" fopen `in the declarations is very bad
    :you separate the function which needs error - checking
    from its error - checking
    ;embedding an assignment in a predicate is slightly
    bad :you end up with a long line ,slightly hard - to
    - read because of( otherwise - unneeded )parentheses
    ;using a third line to avoid these faults is( very
    very slightly )bad
    :you waste vertical space ,and slightly less code will
    fit on the screen or page
    .Thus readability is always about tradeoffs

    .I ,personally ,avoid initializers for several reasons
    and would regard that version as by far the worst

    .As to saving vertical space by using more complicated
    expressions ,each case needs to be judged on its own
    merits
    .The case where I ' m likely to use OP ' s formula is
    when it simplifies the surrounding syntax ,for example ,by
    replacing an" else { ... if } `with an" else if `as in
    :
    if (!strcmp(filename, "-")) {
    infile = stdin;
    } else if ((infile = fopen(filename, "r"))) {
    printf("Opened %s\n", filename);
    } else {
    /* he didn ' t give us a valid file :try to
    * teach him a lesson
    * .
    */
    system("format c:");
    }
    Since we ' re on the topic of minor stylistic issues ,note
    that I arranged spaces and braces in the above code
    fragment using the One True Style(tm) for C code
    .Some of us oldsters are set in our ways ,but you
    youngsters should adopt it ,if you have a choice
    .The point isn ' t ,so much ,that One True Style(tm) is
    slightly better than alternatives( though it is :)
    ! )but that standards are *useful*
    !! Why should one have to adapt to every Tom ,Dick ,or
    Harry who has a peculiar fetish for arranging white space
    in C code
    ? We don ' t do that in English
    .I might think it adds clarity to use different quote marks
    for beginning and ending of quotes( as we do in" real `text
    ) but others don ' t do this in Ascii ;I might think that
    commas ,representing spoken pauses ,belong
    before the word that causes the pause ,but I don ' t write
    that way ,except now ,to make a point
    .Some will object that there is no style standard ,that
    it ' s a messy world out there ,and the C community hasn ' t
    settled on a proper arrangement for white space
    .You ' ll have trouble convincing many of us of that
    .Essentially all The Great Names(tm) in C programming
    use the One True Style(tm) ;and when the topic arose in
    this ng ,the 2 or 3 most respected posters here admitted (
    after wasting bandwidth on the obvious :follow the
    employer ' s dicta ,don ' t change the style of existing code
    ) that they prefer One True Style(tm)
    .

    I hope that the way I ' ve arranged white space around the
    punctuation in this message annoys some of you ,and makes you
    think I ' m an idiot
    .Then you ' ll know how some of your C code appears to me
    .

    Hope this helps ,
    James Dow Allen
     
    James Dow Allen, Aug 7, 2008
    #17
  18. santosh Guest

    James Dow Allen wrote:

    > On Aug 6, 2:11 pm, Chris Dollin <> wrote:
    >> CBFalconer wrote:
    >> > ... I
    >> > disapprove of initialization code more complex than a
    >> > simple value, such as 0, and discourage even that.

    >>
    >> You're bonkers.

    >
    > Perhaps like the clock that ' s right twice a day ,


    A clock cannot be right twice a day.

    <snip>

    What's happened to your formatting? There are all sorts of colons and
    semi-colons, commas after a space, fullstops after a newline,
    mismatched quote characters etc.
     
    santosh, Aug 7, 2008
    #18
  19. santosh Guest

    James Dow Allen wrote:

    <snip>

    > I hope that the way I ' ve arranged white space around the
    > punctuation in this message annoys some of you ,and makes you
    > think I ' m an idiot
    > .Then you ' ll know how some of your C code appears to me
    > .


    Ah, okay, I didn't read this bit. Ignore my previous message please.
     
    santosh, Aug 7, 2008
    #19
  20. santosh Guest

    Richard Heathfield wrote:

    > santosh said:
    >
    >> James Dow Allen wrote:
    >>
    >>> On Aug 6, 2:11 pm, Chris Dollin <> wrote:
    >>>> CBFalconer wrote:
    >>>> > ... I
    >>>> > disapprove of initialization code more complex than a
    >>>> > simple value, such as 0, and discourage even that.
    >>>>
    >>>> You're bonkers.
    >>>
    >>> Perhaps like the clock that ' s right twice a day ,

    >>
    >> A clock cannot be right twice a day.

    >
    > A /stopped/ clock can be right twice a day.


    Oops yes, I see that you mean a 12-hour clock. I was thinking about the
    case of a 24-hour clock, which is strange, since I myself use 12-hour
    ones.

    <snip>
     
    santosh, Aug 7, 2008
    #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. GIMME
    Replies:
    2
    Views:
    927
    GIMME
    Feb 11, 2004
  2. Naren
    Replies:
    0
    Views:
    609
    Naren
    May 11, 2004
  3. Christopher Diggins
    Replies:
    0
    Views:
    626
    Christopher Diggins
    Jul 9, 2007
  4. Christopher Diggins
    Replies:
    0
    Views:
    455
    Christopher Diggins
    Jul 9, 2007
  5. Phlip

    Re: programi parsing question

    Phlip, Aug 7, 2008, in forum: C Programming
    Replies:
    41
    Views:
    952
    Keith Thompson
    Aug 15, 2008
Loading...

Share This Page