455,906 Members | 1,387 Online
Need help? Post your question and get tips & solutions from a community of 455,906 IT Pros & Developers. It's quick & easy.

 P: n/a Given the expression: while (isaspace(c = *s++)) x+1; (s is an array) Does the increment to 's' occur after "x+1" is evaluated, or after the content of s is assigned to c? Is there a general rule as to when this type of increment occurs? ( I understand that the increment in "c = ++*s" occurs immediately before assignment, so my guess is the same would apply in the "after" scenerio, but not sure). thank you. May 30 '07 #1
25 Replies

 P: n/a mdh said: Given the expression: while (isaspace(c = *s++)) x+1; (s is an array) Does the increment to 's' occur after "x+1" is evaluated, No, before. or after the content of s is assigned to c? Maybe. Here is one possible ordering: (1) assign *s to c (2) increment s Here's another: (1) assign *s to a temp (2) increment s (3) assign the temp to c Here's another: (1) increment s (2) assign *(s - 1) to c In any event, all is definitely done and dusted before x+1 happens. Between one sequence point and the next, the compiler has considerable freedom with regard to what it does when. (Across sequence points, it has rather less freedom - it can only mess about if a strictly conforming program can't tell that it has done so.) -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. May 30 '07 #2

 P: n/a On May 29, 6:41 pm, Richard Heathfield while (isaspace(c = *s++)) x+1; > Does the increment to 's' occur after "x+1" is evaluated, No, before. or after the content of s is assigned to c? Maybe. Here is one possible ordering: In any event, all is definitely done and dusted before x+1 happens. thank you Richard. That explains a "bug" I had with s incrementing before I wanted it to. May 30 '07 #3

 P: n/a On May 30, 1:32 pm, mdh

 P: n/a Old Wolf said: On May 30, 1:32 pm, mdh Given the expression:while (isaspace(c = *s++))x+1;(s is an array) If s is an array then this code has a constraint violation, as arrays cannot be incremented. Did you mean (*s)++ ? At a guess, he meant that s points to an element within an array. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. May 30 '07 #5

 P: n/a On May 30, 2:09 pm, Richard Heathfield

 P: n/a On May 30, 10:28 am, Old Wolf

 P: n/a On May 29, 7:09 pm, Richard Heathfield

 P: n/a mdh said: On May 29, 7:09 pm, Richard Heathfield Old Wolf said: Did you mean (*s)++ ? At a guess, he meant that s points to an element within an array. Good guess :-) Beware. *s++ and (*s)++ mean different things. int zog[2] = { 6, 42 }; int *s; s = zog; *s++ = 12; /* zog is now { 12, 42 }, *s = 42 */ s = zog; (*s)++; /* zog is now { 13, 42 }, *s = 13 */ s = zog; *++s; /* zog is now { 13, 42 }, *s is 42 */ s = zog; ++*s; /* zog is now { 14, 42 }, *s is 14 */ -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. May 30 '07 #9

 P: n/a On May 30, 12:50 am, Richard Heathfield Beware. *s++ and (*s)++ mean different things. int zog[2] = { 6, 42 }; int *s; s = zog; *s++ = 12; /* zog is now { 12, 42 }, *s = 42 */ At the risk of showing total ignorance...( except by now I suppose a lot of people who answer my queries are used to this !!! :-)) So, s is initialized to point at the address of zog[0]. On the face of it, 12 is assigned to zog[0], then the pointer is incremented by one and dereferenced. This makes sense, but then I looked at P53 of K&R and am confused. If I read this correctly, the assignment should occur last, as it is the lowest order of precedence. Then if * and ++ are of equal precedence ( line 2, same page) and the associativity is right to left, why am I incorrect ( and I must be ) in saying that *s+ + = 12 should first increment the pointer, then dereference it, then assign 12 to that index, and give zog { 6, 12} /** wrong **/ but why? I will leave the others for now, as I am sure the answer to this will help with those examples. Thank you as usual. > s = zog; (*s)++; /* zog is now { 13, 42 }, *s = 13 */ s = zog; *++s; /* zog is now { 13, 42 }, *s is 42 */ s = zog; ++*s; /* zog is now { 14, 42 }, *s is 14 */ -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999http://www.cpax.org.uk email: rjh at the above domain, - www. May 31 '07 #10

 P: n/a mdh wrote: On May 30, 12:50 am, Richard Heathfield >Beware. *s++ and (*s)++ mean different things.int zog[2] = { 6, 42 };int *s;s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ At the risk of showing total ignorance...( except by now I suppose a lot of people who answer my queries are used to this !!! :-)) So, s is initialized to point at the address of zog[0]. Yes. On the face of it, 12 is assigned to zog[0], Yes, via `s`. then the pointer is incremented by one and dereferenced. No. The deference happens as part of the assignment; the increment happens sometime between the beginning of the statement and the end. This makes sense, but then I looked at P53 of K&R and am confused. If I read this correctly, the assignment should occur last, as it is the lowest order of precedence. Be warned. /Precedence/ and /order of evaluation/ are not the same thing. Precedence says what things are operands of what operators; order of evaluation says what orders of things happening are allowable. In `*s++ = 12`, the order of the assignment and the incrementing /is not specified/; either can happen before the other. Then if * and ++ are of equal precedence ( line 2, same page) and the associativity is right to left, why am I incorrect ( and I must be ) in saying that *s++ = 12 should first increment the pointer, then dereference it, The binding in `*s++` is `*(s++)`. The thing that is dereferenced is the /value of `s++`/, which is the /original/, unincremented, value of `s`. Contrast with `++s`, which yeilds the /incremented/ value of `s`. Note that the increment of `s` doesn't have to take place immediately, either. It's legal to evaluate `*s++ = 12` as *s = 12; s += 1 if we can ignore the value of the expression. -- "If there is a problem, you must confess it, Mr Chaplin"/The Beiderbeck Affair/ Hewlett-Packard Limited registered no: registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England May 31 '07 #11

 P: n/a On May 31, 3:45 am, Chris Dollin Be warned. /Precedence/ and /order of evaluation/ are not the same thing. Precedence says what things are operands of what operators; order of evaluation says what orders of things happening are allowable. Aha...so are you saying that the table on page 53 ( Table 2-1) has nothing to do with the order of evaluation? ( You say this is essentially undefined?) Could you please clarify what the term "associativity" then means? > May 31 '07 #12

 P: n/a mdh wrote: On May 31, 3:45 am, Chris Dollin >Be warned. /Precedence/ and /order of evaluation/ are not the same thing. Precedence says what things are operands of whatoperators; order of evaluation says what orders of things happeningare allowable. Aha...so are you saying that the table on page 53 ( Table 2-1) has nothing to do with the order of evaluation? My copy of K&R II is at home, but if it's the "usual" table of precedences, yes. ( You say this is essentially undefined?) Unspecified. ("Undefined" has a specific meaning here; "all bets are off, anything could happen, demons could fly out of your nose"; the latter is a Bad Thing even if you have a very heavy cold.) There are some exceptions: && || ?: and ,-operator have defined order-of-evaluation rules. And typically an expression `L op R` can't be evaluated without first evaluating `L` and `R`. (Exceptions again: || and &&, which may not need to evaluate `R` at all, and `X ? Y : Z`, which will evaluate `X` first then exactly one of `Y` or `Z`.) Could you please clarify what the term "associativity" then means? When precedence won't tell you what the operands are, associativity will. In `A + B + C` it says that it's structured as `(A + B) + C`; stuff groups to the left. -- "He could not weigh up which was worse and so tried not to think about either." /The Spellgrinder's Apprentice/ Hewlett-Packard Limited registered office: Cain Road, Bracknell, registered no: 690597 England Berks RG12 1HN May 31 '07 #13

 P: n/a On May 31, 4:28 am, Chris Dollin Be warned. /Precedence/ and /order of evaluation/ are not the same thing. Aha...so are you saying that the table on page 53 ( Table 2-1) has nothing to do with the order of evaluation? >Unspecified. Meaning that things that will happen will be as expected,( versus undefined) except that "my" anticipated order ( with exceptions you mentioned) can not be relied upon? Could you please clarify what the term "associativity" then means? ......... So it sounds like "associativity" and "binding" is synonymous? So, may I try and summarize what you have told me? Precedence "asscociates" an operand with an operator ( unary operator), or 2 operands with and operator. This is very different from evaluating an expression. (I looked for a definition of evaluation, and did not find one, but I suppose conceptually it is the act of "resolving"? an expression.) What you have said is that with exceptions, the language does not specify an order in which this is to occur..and I guess, one has to be careful in crafting code to be unambiguous, in this regard. So, to go back where this all started: >int zog[2] = { 6, 42 };int *s; >s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ >The deference happens as part of the assignment; the incrementhappens sometime between the beginning of the statement and theend. means: ( (*(s++)) = 12 ); /** in terms of precedence **/ Now...I hope I don't get you pulling your hair out ....but...does the 's++' imply that s will only increment AFTER something has happened to it, which in this case is to have the '12' assigned to that which it points at, now it is incremented, then it is dereferenced? I think that I am still a little fuzzy as to the exact meaning of "evaluation" and "precedence/assocition"..or it may just be too damn late/early in the morning? :-) In other words, is 's++' an evaluation or an 'association'? Is it obvious to you what I am perhaps missing? May 31 '07 #14

 P: n/a mdh wrote: On May 31, 4:28 am, Chris Dollin > Be warned. /Precedence/ and /order of evaluation/ are not the >same thing. Aha...so are you saying that the table on page 53 ( Table 2-1) has nothing to do with the order of evaluation? >>Unspecified. Meaning that things that will happen will be as expected,( versus undefined) except that "my" anticipated order ( with exceptions you mentioned) can not be relied upon? It means that the Standard doesn't say what order things happen in (except when it does), and programs that try to find out risk falling into Undefined Behaviour. Could you please clarify what the term "associativity" then means? ........ So it sounds like "associativity" and "binding" is synonymous? Associativity is a way of describing how to get the binding (of operands to operators). Note that the Standard doesn't talk about precedence and doesn't talk about associativity: it just has grammar rules. They Are In Charge. Precedence "asscociates" an operand with an operator ( unary operator), or 2 operands with and operator. This is very different from evaluating an expression. (I looked for a definition of evaluation, and did not find one, but I suppose conceptually it is the act of "resolving"? an expression.) What you have said is that with exceptions, the language does not specify an order in which this is to occur..and I guess, one has to be careful in crafting code to be unambiguous, in this regard. Unambiguous or indifferent. So, to go back where this all started: >>int zog[2] = { 6, 42 };int *s; >>s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ means: ( (*(s++)) = 12 ); /** in terms of precedence **/ Now...I hope I don't get you pulling your hair out ....but...does the 's++' imply that s will only increment AFTER something has happened to it, No. It's an expression whose result is the original value of `s`. At some point (here, sometime before the semicolon; the Standard talks in terms of "sequence points" which cover those && and ?: etc cases) `s` will be incremented. That may happen before, after, or during the delivery of `s`s original value. which in this case is to have the '12' assigned to that which it points at, now it is incremented, then it is dereferenced? Well, really `s` isn't dereferenced; it's original value is. It's because `s` may be incremented any time before the `;` that you have to be very careful about the language you use. I think that I am still a little fuzzy as to the exact meaning of "evaluation" and "precedence/assocition"..or it may just be too damn late/early in the morning? :-) In other words, is 's++' an evaluation or an 'association'? Is it obvious to you what I am perhaps missing? `s++` is an expression; it has operator `postfix ++` and operand `variable s`. To evaluate it, deliver the value `s` had before the (entire) expression was evaluated and arrange for `s` to be incremented by the time the (entire) expression has finished evaluating. -- "Go not to the Drazi for counsel, Unsaid /Babylon 5/ for they will answer both 'green' and 'purple'." Hewlett-Packard Limited Cain Road, Bracknell, registered no: registered office: Berks RG12 1HN 690597 England May 31 '07 #15

 P: n/a mdh said: On May 30, 12:50 am, Richard Heathfield >Beware. *s++ and (*s)++ mean different things.int zog[2] = { 6, 42 };int *s;s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ At the risk of showing total ignorance...( except by now I suppose a lot of people who answer my queries are used to this !!! :-)) So, s is initialized to point at the address of zog[0]. On the face of it, 12 is assigned to zog[0], then the pointer is incremented by one and dereferenced. No. As a result of *s++ = 12; there are two changes to the values stored in objects: * The object zog[0] gets the new value 12 * The object s gets the new value &zog[1] The order in which these values are given is unspecified. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. May 31 '07 #16

 P: n/a Richard Heathfield On May 30, 12:50 am, Richard Heathfield >>Beware. *s++ and (*s)++ mean different things.int zog[2] = { 6, 42 };int *s;s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ At the risk of showing total ignorance...( except by now I suppose alot of people who answer my queries are used to this !!! :-))So, s is initialized to point at the address of zog[0]. On the face ofit, 12 is assigned to zog[0], then the pointer is incremented by oneand dereferenced. No. As a result of *s++ = 12; there are two changes to the values stored in objects: * The object zog[0] gets the new value 12 * The object s gets the new value &zog[1] The order in which these values are given is unspecified. In the context if single threaded programs dont you think this is slightly unnecessary complication? It is playing with the english language. It is perfectly "normal" so say "the value 12 is stored at the address held in s, s is then incremented to point to the next element" Its why "++" is called increment, Yes, I know what you are saying, I fail, however, to see the reason why in the context of a beginner learning post increment and reference/dereference. May 31 '07 #17

 P: n/a Richard said: Richard Heathfield mdh said: >>>So, s is initialized to point at the address of zog[0]. On the faceof it, 12 is assigned to zog[0], then the pointer is incremented byone and dereferenced. No. As a result of *s++ = 12; there are two changes to the valuesstored in objects:* The object zog[0] gets the new value 12* The object s gets the new value &zog[1]The order in which these values are given is unspecified. In the context if single threaded programs dont you think this is slightly unnecessary complication? Not at all. Getting "order of evaluation", "precedence", and "associativity" separated out is a key step in the journey from accident to design. It is playing with the english language. It is perfectly "normal" so say "the value 12 is stored at the address held in s, s is then incremented to point to the next element" Yes, and that's (roughly) how I'd choose to say it, were it not for the fact that it is *misleading*, given that this is the very point about which the O.P. is confused and seeks clarification. Its why "++" is called increment, Yes, I know what you are saying, I fail, however, to see the reason why in the context of a beginner learning post increment and reference/dereference. The fact that you fail to see a reason for something does not mean that no reason exists. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. May 31 '07 #18

 P: n/a mdh >Beware. *s++ and (*s)++ mean different things.int zog[2] = { 6, 42 };int *s;s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ At the risk of showing total ignorance...( except by now I suppose a lot of people who answer my queries are used to this !!! :-)) So, s is initialized to point at the address of zog[0]. On the face of it, 12 is assigned to zog[0], then the pointer is incremented by one and dereferenced. At the risk of labouring the point, imagine executing a C program on a computer consisting of room full of people. The C standard states that we can only be sure of what has and has not happened at certain points. These are the "sequence points" you may have heard about and we may only open the door of the room at these sequence points. The program starts: int zog[2] = { 6, 42 }; We open the door (the ; is a sequence point) and we see two people standing in a row called zog[0] and zog[1]. They have 6 and 42 pounds in their pockets respectively. We close the door. s = zog; We open it, and see a person, s, pointing at zog[0]. We close the door. *s++ = 12; Upon opening the door we know that the person s was pointing at when we last looked will now have 12 pounds in his/her pocket, and that s will now be pointing at the next person in the zog line (zog[1]). *s++ means "the person s was pointing at (oh, and make sure you are pointing at their neighbour when we next get to look)". You are not allowed to know, or even care, exactly what happened in the room while you were not looking. Did the 12 pounds go into the pocket before, after, or during s's arm movement? You can't tell and you should not care. The *reason* the standard is like this, is to allow compilers (which issue much more detailed instructions to the people in the room) a lot of flexibility so they can arrange thing as efficiently as possible. The compiler might have told s to give zog[0] an extra six pounds while moving her arm -- no assignment of 12 and no absolute ordering of the events either. -- Ben. May 31 '07 #19

 P: n/a mdh wrote: On May 31, 4:28 am, Chris Dollin > Be warned. /Precedence/ and /order of evaluation/ are not the >same thing. Aha...so are you saying that the table on page 53 ( Table 2-1) has nothing to do with the order of evaluation? >>Unspecified. Meaning that things that will happen will be as expected,( versus undefined) except that "my" anticipated order ( with exceptions you mentioned) can not be relied upon? No. Meaning that the compiler can use any order it likes, as long as the correct operands are used for each operator. > Could you please clarify what the term "associativity" then means? ........ So it sounds like "associativity" and "binding" is synonymous? So, may I try and summarize what you have told me? Precedence "asscociates" an operand with an operator ( unary operator), or 2 operands with and operator. Almost. The combination of precedence and associativity can tell you (in most cases) which operands an operator works on. Basically, precedence and associativity tell you how to create a fully parenthesised expression that is equivalent to the original expression. As an example, we take the expression *s++ = 12 Precedence tells us that = has low precedence, and ++ and * have the same, higher, precedence. This leads to the parenthesised form (*s++) = 12 Because * and ++ have the same precedence, we can't use that to place further parentheses. Now associativity comes into play. The associativity of these operators is 'right to left', so that is the order in which we should place our next parentheses: (*(s++)) = 12 Now it is clear that the * operates on the result of the expression s++. This is very different from evaluating an expression. (I looked for a definition of evaluation, and did not find one, but I suppose conceptually it is the act of "resolving"? an expression.) What you have said is that with exceptions, the language does not specify an order in which this is to occur..and I guess, one has to be careful in crafting code to be unambiguous, in this regard. Or even better, write code that does not care about the order of evaluation. > So, to go back where this all started: >>int zog[2] = { 6, 42 };int *s; >>s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ >>The deference happens as part of the assignment; the incrementhappens sometime between the beginning of the statement and theend. means: ( (*(s++)) = 12 ); /** in terms of precedence **/ In terms of the combination of precedence and associativity. (or more correct: in terms of the language grammar). > Now...I hope I don't get you pulling your hair out ....but...does the 's++' imply that s will only increment AFTER something has happened to it, which in this case is to have the '12' assigned to that which it points at, now it is incremented, then it is dereferenced? Not exactly. You can interpret 's++' best as: Schedule an increment of s and continue working with the old value. In the same way, ++s can be read as: Schedule an increment of s and continue working with the new value. For a well-formed program, it does not matter when the compiler finally gets around to perform the scheduled increment. I think that I am still a little fuzzy as to the exact meaning of "evaluation" and "precedence/assocition"..or it may just be too damn late/early in the morning? :-) In other words, is 's++' an evaluation or an 'association'? Is it obvious to you what I am perhaps missing? I would call it both. To me, association is the process of determining which operands an operator works on, so the operator++ is associated with the operand s. Evaluation is more a runtime thing, where the actual calculation is performed. Bart v Ingen Schenau -- a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/ May 31 '07 #20

 P: n/a On May 31, 10:34 am, Bart van Ingen Schenau wrote: mdh wrote: Thanks Bart for that nice explanation and thanks all for the help in trying to understand this. It really did take time to understand the concept of "ordering", or more specifically, the lack thereof to the compiler. The explanation of sequence points finally cemented this for me. (I am not sure if "2" thank-you s will appear as once again, Google is on the Fritz....which seems to be happening just about weekly now. ) thanks all again. Jun 1 '07 #21

 P: n/a On 31 May 2007 03:35:27 -0700, mdh On May 30, 12:50 am, Richard Heathfield >Beware. *s++ and (*s)++ mean different things.int zog[2] = { 6, 42 };int *s;s = zog; *s++ = 12;/* zog is now { 12, 42 }, *s = 42 */ At the risk of showing total ignorance...( except by now I suppose alot of people who answer my queries are used to this !!! :-))So, s is initialized to point at the address of zog[0]. On the face ofit, 12 is assigned to zog[0], then the pointer is incremented by oneand dereferenced. This makes sense, but then I looked at P53 of K&Rand am confused. If I read this correctly, the assignment should occurlast, as it is the lowest order of precedence. Then if * and ++ areof equal precedence ( line 2, same page) and the associativity isright to left, why am I incorrect ( and I must be ) in saying that *s++ = 12 should first increment the pointer, then dereference it, thenassign 12 to that index, and give zog { 6, 12} /** wrong **/ but why?I will leave the others for now, as I am sure the answer to this willhelp with those examples. You need to distinguish between the evaluation of an operator (or perhaps more precisely the expression the operator is part of) and any side effect the operator may have. The ++ operator always evaluates to the original value of its operand. As a side effect, it increments the value of the operand. The only thing you know about the timing of this side effect is that it will be completed at or before the next sequence point. For your example: *s++ associates right to left and therefore is parsed as *(s++). We know that s++ evaluates to &zog[0]. We also know that s will eventually be incremented to &zog[1] but that has nothing to with the evaluation of the expression s++. The * operator will be applied to the evaluated expression (it is completely unaffected by the side effect) and will result in the object zog[0]. Therefore the left operand of the = operator is zog[0]. The actual incrementing of s can occur any time the compiler feels like it as long as the resulting executable code evaluates the expression correctly. Remove del for email Jun 1 '07 #22

 P: n/a On May 31, 6:41 pm, Barry Schwarz > You need to distinguish between the evaluation of an operator ....... and any side effect.... The ++ operator always evaluates to the original value of its operand. As a side effect, it increments the value of the operand....... completed at or before the next sequence point. For your example: *s++ associates right to left and therefore is parsed as *(s++). We know that s++ evaluates to &zog[0]. We also know that s will eventually be incremented to &zog[1] but that has nothing to with the evaluation of the expression s++. The * operator will be applied to the evaluated expression (it is completely unaffected by the side effect) and will result in the object zog[0]. Therefore the left operand of the = operator is zog[0]. And this was certainly a large part of the confusion for me. And, as you say in the next paragraph, understanding that "timing" plays no role, is crucial, and has been nicely pointed out, by you here. > The actual incrementing of s can occur any time the compiler feels like it as long as the resulting executable code evaluates the expression correctly. Thank you Barry. I think this, as RH explained, once understood, really does take one to the next level of understanding of C. I am just beginning to wonder how many levels there are? :-) Jun 1 '07 #23

 P: n/a Barry Schwarz wrote: > .... snip ... > For your example: *s++ associates right to left and therefore is parsed as *(s++). We know that s++ evaluates to &zog[0]. We also know that s will eventually be incremented to &zog[1] but that has nothing to with the evaluation of the expression s++. Which I suspect is the cause of the confusion. People aren't separating the side effect (incrementing) from the value of the expression (unincremented). For this ignore the *, which uses the value of the expression. -- cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Jun 1 '07 #24

 P: n/a mdh wrote: Thank you Barry. I think this, as RH explained, once understood, really does take one to the next level of understanding of C. I am just beginning to wonder how many levels there are? :-) There always seems to be at least one level more that you have not reached yet. In contrast, in C++ there always seem to be at least 10 levels more :-) Bart v Ingen Schenau -- a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/ Jun 1 '07 #25

 P: n/a Bart van Ingen Schenau wrote: mdh wrote: >Thank you Barry. I think this, as RH explained, once understood,really does take one to the next level of understanding of C. I amjust beginning to wonder how many levels there are? :-) There always seems to be at least one level more that you have not reached yet. In contrast, in C++ there always seem to be at least 10 levels more :-) Winning IOCCC (or even making an entry) is one personal goal of mine and lots of level up (I am not that far away - from making an entry...) Perhaps not a recommendable goal in life and not a recommended level to reach for "normal" programming but anyway... Jun 2 '07 #26

### This discussion thread is closed

Replies have been disabled for this discussion.