C++0x



  • @Isuwen said:

    @poopdeville said:

    He showed an example of a grammatically correct C++ program which will not compile because C++'s grammar is undecidable.
     

    There is more to correctness than grammar. The program is logically incorrect. Infinite recursion is always a logical error. You should be praising the compiler for detecting it, rather than compiling through the heat death of the universe.

     

    And, for that matter, who gives a fuck? Whoever argued it is right : This example is stupid because it is ALWAYS an error. The compiler should not be expected to compile a program when you write shitty code like that. 

    Certainly, recursion to arbitrary depths is not an error. The fact that the compiler can't tell arbitrary depths from infinite depths is (1) the point of Turing's response to the Halting Problem, and (2) the freaking point.

    You can't in principle know how deep a recursive algorithm is going to go. That doesn't mean it is incorrect. That doesn't mean it isn't useful.

    What it might mean is that your compiler might barf on a useful, provably correct algorithm because of this max-depth business.



  • @poopdeville said:

    What it might mean is that your compiler might barf on a useful, provably correct algorithm because of this max-depth business.

    And the point is? Lets say you rewrite the program in some other way -- do the limitations magically go away? You always have some max-depth in recursion (or iterative methods), be running out of stack space/memory or time. Granted, the limits may be higher, but you can still find a problem where the program will `barf' even though it is (theoretically) correct.

    And FWIW, Isuwen touched an important point: there's more to correctness than grammar.



  • @mallard said:

    @Some unnamed 'modern' language said:

    Console.Write("Literal" + someString + someInt.ToString() + someCustomClass.ToString())

     

     

    How about 

    Console.Write (String.Format("Literal {0}{1}{2}", someString, someInt, someCustomClass);

    instead of the horrible string concatenation? Plus the string.format version can easily be localised to take into account different sentence structures when changing languages....



  • @cvi said:

    @poopdeville said:
    What it might mean is that your compiler might barf on a useful, provably correct algorithm because of this max-depth business.

    And the point is? Lets say you rewrite the program in some other way -- do the limitations magically go away? You always have some max-depth in recursion (or iterative methods), be running out of stack space/memory or time. Granted, the limits may be higher, but you can still find a problem where the program will `barf' even though it is (theoretically) correct.

    And FWIW, Isuwen touched an important point: there's more to correctness than grammar.

    What do you mean, what is my point? Templates are supposed to be able to do useful work for you. Sometimes they can't because of artificial compiler limitations. (Read: bugs) Tied to this idea, C++ is supposed to do useful work for you. But, in general, you can't even tell if it will compile until you've tried. That's the WTF. C++ is sounding more and more like Perl 5 without the fun tricks.

    Regarding the environment: max-depth issues can be completely eliminated with tail call optimization. Space and time limitations can be mitigated with money. That does not address the point that templates are supposed to be able to perform general purpose computation at compile-time. This is a dilemma: either they can, and so C++ is undecidable (as a grammar), or they can't, and C++ is still undecidable as demonstrated. Which would you prefer?



  • @Isuwen said:

    You're trying to use a malformed program to prove that writing a 'correct' compiler is impossible.

    That's just stupid. 

    Of course the compiler can't compile this. It'll generate an error, just like it's supposed to.

     

    The program would be malformed if the compiler issued an error due to the syntax, invalid types, or so forth.  But the compiler cannot do any such thing with the given code.  The error is issued because the compile has reached it arbitrary maximum depth, not because the compiler has located any error with the code.  In fact, the compiler, if allowed to continue forever, would never find any error with the code.

    @Isuwen said:
    @poopdeville said:
    He showed an example of a grammatically correct C++ program which will not compile because C++'s grammar is undecidable.

    There is more to correctness than grammar. Yes, but we're discussing the grammar here.  Please try to keep up.

    The program is logically incorrect.
      No, it isn't.  Do understand the concept of undecidability?

    Infinite recursion is always a logical error. You should be praising the compiler for detecting it, rather than compiling through the heat death of the universe.
      Nonsense.  Different types of recursion (or corecursion) can be accomplished thanks to lazy evaluation and tail recursion elimination.  If I were calculating all the digits of pi, I would be quite displeased that you think my quest is a logical error.

    And, for that matter, who gives a fuck? Whoever argued it is right : This example is stupid because it is ALWAYS an error.
      It's NEVER an error.  That's the real problem.

    The compiler should not be expected to compile a program when you write shitty code like that.
      The code itself is quite elegant, as recursion often is.  And the compiler isn't expected to compile a program given such code, BECAUSE IT CANNOT DETERMINE WHETHER OR NOT THE CODE IS VALID.  You and I, we know the code goes on forever.  The compiler does not, and thanks to the Halting Problem, cannot.

     @cvi said:

    And FWIW, Isuwen touched an important point: there's more to correctness than grammar.
      Isuwen is so far out of his/her depth here that it's funny.  It's one thing to debate the merits of an undecidable grammar.  It's another to debate it without demonstrating any comprehension of what undecidability is.



  • @poopdeville said:

    the reason it barfs is because it sets an artificial upper limit on the depth of template recursion, in spite of the specification that templates are supposed to be Turing complete.

     

    Sorry, but every programming language has an upper limit on recursion, it's called the maximum stack size, and it doesn't void their Turing-completeness.

    A langauge is Turing complete if it could compute every Turing-computable function, given infitie memory and time. However, no real system has infinite memory and time. Stack size is effectively a memory limit and therefore does not void Turing-completeness.



  • @Heron said:

    @tray said:

    Ok, but how do you pronounce "C++0x" ?

    Assuming you're joking, I'm answering anyway:

    "See Plus Plus Oh Eks "






    No, I was serious. After the story of C#, my imagination went wild on C++0x. My guesses were "seeplusplusnil", "seeplus-plusouh" and "seepoundouh".




    I really thought that 0x had some special meaning.



  • @bstorer said:

    @cvi said:
    And FWIW, Isuwen touched an important point: there's more to correctness than grammar.
      Isuwen is so far out of his/her depth here that it's funny.  It's one thing to debate the merits of an undecidable grammar.  It's another to debate it without demonstrating any comprehension of what undecidability is.

    It's been a while since I studied programming languages, so lets see if I got this right: The two points people have made is: C++ grammar is undecidable because

    • a b( c ); can mean two different things, at least out of any context
    • you can write a template "meta-program" that will never complete, and the compiler can't determine this

    The first point is really a limitation of context-free grammars, which simply means that C++ grammar is not context free (IIRC C++ grammar is not LALR anyway, so the parsing is bound to be somewhat messy).

    And I still think the second point is a general limitation of computers, because as someone mentioned, computers are not ideal turing-machines (and even if they were, you'd still need to solve the halting-problem which is, of course, not possible).

    So, conclusion: I might also be so far out of my depth that I really don't see the problem with C++ grammar being undecidable (in the second sense). Granted, you can't tell if a given program will ever finish compiling, but then again, you can't tell if a given program will ever finish executing. Any meta-programming will suffer from the same limitations normal programs do. (In case I'm completely missing the point, any information on where I can learn more about that problem is appreciated. I don't claim to be very clued up on these issues.)

    @poopdeville said:

    Regarding the environment: max-depth issues can be completely eliminated with tail call optimization.

    Can you really tail-call optimize multiple recursion? I can't see how you'd do that. And the point still stands: regardless of how much resources you have available, there's always a problem which would require more.

    @poopdeville said:

    This is a dilemma: either they can, and so C++ is undecidable (as a grammar), or they can't, and C++ is still undecidable as demonstrated. Which would you prefer?

    They can, barring (compiler) bugs and hardware limitations? As any other programming language/program out there?



  • @cvi said:

    It's been a while since I studied programming languages, so lets see if I got this right: The two points people have made is: C++ grammar is undecidable because

    • a b( c ); can mean two different things, at least out of any context
    • you can write a template "meta-program" that will never complete, and the compiler can't determine this

    The first point is really a limitation of context-free grammars, which simply means that C++ grammar is not context free (IIRC C++ grammar is not LALR anyway, so the parsing is bound to be somewhat messy).

    Mostly yes, but some no.  The first point, that AA BB(CC); is ambiguous, does not inherently make the language grammar undecidable.  It does make it context-sensitive.  This, of course, comes from C, but C has a decidable grammar.  The problem comes in from the the fact that in order to determine what AA BB(CC); means, you have to establish whether CC is a type or a value.  This can be undecidable, as in the example code I gave.

    And I still think the second point is a general limitation of computers, because as someone mentioned, computers are not ideal turing-machines (and even if they were, you'd still need to solve the halting-problem which is, of course, not possible).

    So, conclusion: I might also be so far out of my depth that I really don't see the problem with C++ grammar being undecidable (in the second sense). Granted, you can't tell if a given program will ever finish compiling, but then again, you can't tell if a given program will ever finish executing. Any meta-programming will suffer from the same limitations normal programs do. (In case I'm completely missing the point, any information on where I can learn more about that problem is appreciated. I don't claim to be very clued up on these issues.)

      Actually, I don't think you're out of your depth.  Isuwen claimed that infinite recursion is always logically incorrect, a statement somewhat akin to saying, "I have no idea what I'm talking about.  Please, savage me mercilessly."  I get what you're saying: clearly somebody has figured out how to parse the language, so who cares?  To be perfectly honest, I don't regard it as that big a deal that C++ has an undecidable grammar, because I don't run up against it. But it does deserves some criticism because it reeks of poor design.  Here's an excellent example I've found, along with the explanation of what's going on:

    #include <cstdio>

    template<int n> struct confusing
    {
    static int q;
    };

    template<> struct confusing<1>
    {
    template<int n>
    struct q
    {
    q(int x)
    {
    printf("Separated syntax and semantics.\n");
    }
    operator int () { return 0; }
    };
    };

    char x;
    int main()
    {
    int x = confusing<sizeof(x)>::q < 3 > (2);

    return 0;
    }

    If you didn't take care about semantics during parsing, then confusing<1>::q is a templated typename, so confusing<1>::q<3>(2) is instantation of object of type confusing<1>::q<3> with argument 2.

    If you "do" semantics during the syntax pass, then confusing<4> will be looked up, confusing<4>::q is a variable. Declaration would "expand" to int x = (confusing<4>::q < 3) > 2.

    You can see that parse trees in those cases are completely different, based on sizeof operator!

    The original post is located in here. It warrants disdain that the structure of the language is so bad as to require extensive symmantic analysis during the syntax parse. 

    @poopdeville said:
    Regarding the environment: max-depth issues can be completely eliminated with tail call optimization.

    Can you really tail-call optimize multiple recursion? I can't see how you'd do that. And the point still stands: regardless of how much resources you have available, there's always a problem which would require more.

    You can tail-call optimize recursion chains, so long as the functions are all tail recursive.  You are correct, though, that there are recursions that cannot be accomplished in constant space (e.g., walking a simple binary tree).



  • I'm interested to know whether the arbitrary limit the compiler puts on template recursion is higher than the arbitrary limit on functional recursion imposed by the limited availability of stack space.   I'm pretty sure that all template recursion could be accomplished some other way (using functional recursion), so if the compiler's limit on template recursion is higher than the limit imposed by stack space, then we're getting more computational power from the compiler than we could from a regular recursive function.  (If that makes sense.)

    bstorer, I'll concede the "undecidable" point to you - with the caveat that I don't necessarily think that the mere possibility of writing an infinitely recursive template means there's some huge design flaw in C++, any more than the mere possibility of writing an infinitely recursive function means there's a huge design flaw.

    Just because they let you do it doesn't mean it's badly designed.

    I don't know if you're religious, but if you are, perhaps an analogy will illustrate what I mean (and if you aren't, the analogy should still hold):  God lets us choose what we want to do, whether or not those choices are good, whether or not they result in salvation or condemnation.  That doesn't mean that God's decision to allow us the freedom to choose was a bad design decision, it simply means that the advantage gained through allowing the freedom is greater than the risks involved.  I think the same is true regarding templates - they can be abused, and they can make compilers barf all over themselves, but they provide distinct advantages that, in my opinion, far outweigh the "risks" involved.

    Someone said something along the lines of "in general, you can't know ahead of time whether or not a C++ program will compile".  That's a very poor generalization; in fact I would say that in general, you almost always know whether it will compile, assuming you're the one writing the program and you're a competent programmer.  Granted, it may be difficult if you're messing around with recursive templates, but most C++ programs don't use recursive templates (I have never written one non-academically, myself), and even then it's really no harder than messing around with recursive functions.  The skill required to determine visually whether a given recursive template will compile is no more than the skill required to visually determine whether a given recursive function will terminate (visually meaning "by a human").  Most programmers I'm acquainted with are capable of that, but I'm aware that there are some less-capable programmers out there (this is, after all, a site of WTFs).



  • @Heron said:

    I'm interested to know whether the arbitrary limit the compiler puts on template recursion is higher than the arbitrary limit on functional recursion imposed by the limited availability of stack space.   I'm pretty sure that all template recursion could be accomplished some other way (using functional recursion), so if the compiler's limit on template recursion is higher than the limit imposed by stack space, then we're getting more computational power from the compiler than we could from a regular recursive function.  (If that makes sense.)

    As mentioned above, some forms of recursion put only a constant amount of data on the stack, allowing for an infinite recursion without stack overflow.  That clearly beats any finite compiler depth limit.

    bstorer, I'll concede the "undecidable" point to you - with the caveat that I don't necessarily think that the mere possibility of writing an infinitely recursive template means there's some huge design flaw in C++, any more than the mere possibility of writing an infinitely recursive function means there's a huge design flaw.

    Just because they let you do it doesn't mean it's badly designed.

    Look at the code I found and posted above that requires symmantic evaluation in order to parse the syntax of the language.  That's bad design.  Does it single-handedly invalidate any usefulness to the language?  Of course not.  But enough things like this crop up in C++ to give one pause.  Have you ever given any thought to why the language requires semicolons, when the compiler can figure out when one is missing?  Start thinking about these things, and you'll realize that C++, however useful you find it, is far from perfect.

    A bit about me: C++ was the first language I learned, save some very simple BASIC programs.  For a few years, I thought about computer science topics in terms of C++.  And then I learned C, and Objective C, and Perl, and Java, and Python, and Ruby, and Lisp, and Scheme, and Prolog, and Haskell, and so on.  And now I very rarely code anything in C++.  If I need low level stuff, I go to C.  If I don't, I go (lately) to Python or Ruby.  But, hey, that's my personal preference.  If it works for you, go to it.



  •  wow, this thread is filled with posts that basically advertise that people have no idea what they are talking about.

     

    And to make a point that making a compiler hard to write is bad for the language:   Since the C++ compiler is so complex, the optimizers, debuggers, and profilers for it are not as good as they could.  Also the compiler could be much faster if it didn't have to be so complex.



  • @mallard said:

    @poopdeville said:

    the reason it barfs is because it sets an artificial upper limit on the depth of template recursion, in spite of the specification that templates are supposed to be Turing complete.

     

    Sorry, but every programming language has an upper limit on recursion, it's called the maximum stack size, and it doesn't void their Turing-completeness.

    A langauge is Turing complete if it could compute every Turing-computable function, given infitie memory and time. However, no real system has infinite memory and time. Stack size is effectively a memory limit and therefore does not void Turing-completeness.

    I've never seen a programming language with an upper limit on recursion. I've seen runtime environments with upper limits on recursion, but never a programming language.



  • @Carnildo said:

    @mallard said:

    @poopdeville said:

    the reason it barfs is because it sets an artificial upper limit on the depth of template recursion, in spite of the specification that templates are supposed to be Turing complete.

     

    Sorry, but every programming language has an upper limit on recursion, it's called the maximum stack size, and it doesn't void their Turing-completeness.

    A langauge is Turing complete if it could compute every Turing-computable function, given infitie memory and time. However, no real system has infinite memory and time. Stack size is effectively a memory limit and therefore does not void Turing-completeness.

    I've never seen a programming language with an upper limit on recursion. I've seen runtime environments with upper limits on recursion, but never a programming language.

     

    this is all part of their thinking that a programing language is the same as a program.  Notice when they said that it's fine that parsing C++ is undeterminate because all lanugauages can have undeterminate programs.  



  • @tster said:

    this is all part of their thinking that a programing language is the same as a program.  Notice when they said that it's fine that parsing C++ is undeterminate because all lanugauages can have undeterminate programs.  

     

    Sorry, but where is that claim? 



  • @cvi said:

    @poopdeville said:
    What it might mean is that your compiler might barf on a useful, provably correct algorithm because of this max-depth business.

    And the point is? Lets say you rewrite the program in some other way -- do the limitations magically go away? You always have some max-depth in recursion (or iterative methods), be running out of stack space/memory or time. Granted, the limits may be higher, but you can still find a problem where the program will `barf' even though it is (theoretically) correct.

    And FWIW, Isuwen touched an important point: there's more to correctness than grammar.

     


  • The problem is, it's impossible for a compiler to actually detect infinite recursion, so it just craps out after a certain number of levels of finite recursion.



  • honestly, what do you expect the compiler to do if it sees an infinite recursion ? replace the loop with a nop and move on ? And how do you define infinite (in iterations) ? When it overflows the stack?



  • @bstorer said:

    Have you ever given any thought to why the language requires semicolons, when the compiler can figure out when one is missing?
     

    There are times where the compiler cannot figure out what to do.  Consider the following:

    [code]int* q = new int; int x = 5; *q = 7;[/code]

    What would happen if the semicolon were missing?

    [code]x = 5*q = 7[/code]

    The compiler would assign 7 to the pointer q (not the memory pointed at by q), then multiply 5 by q, and assign that to x.  That is certainly not the same.

    Yes, the compiler might be able to see that q is a pointer and therefore the * is dereferencing it, but multiplying by an int* is still technically possible, and maybe that's what the programmer intended for some reason.  I realize that few, if any, programmers would write something like the second statement on purpose, but they would certainly write things like the first snippet, and without semicolons the statement changes meaning.

    So you see, semicolons do serve a useful purpose.



  • @pitchingchris said:

    honestly, what do you expect the compiler to do if it sees an infinite recursion ? replace the loop with a nop and move on ? And how do you define infinite (in iterations) ? When it overflows the stack?

     

    we aren't saying the compiler sucks.  We're saying that C++ as a language has a problem because it's syntax is not parsable in a determinate amount of time.  How big a problem it is however, is a question still up in the air.



  • @Heron said:

    So you see, semicolons do serve a useful purpose.
     

    If you consider multiple statements per line to be useful, sure.  Otherwise, you'll have to try harder.  But don't bother posting it here; my point is much broader than the questionable merits of semicolons.  Too few programmers really understand the language they're using.



  • @tray said:

    No, I was serious. After the story of C#, my imagination went wild on C++0x. My guesses were "seeplusplusnil", "seeplus-plusouh" and "seepoundouh".

    I really thought that 0x had some special meaning.
     

    Not that it's relevant to this discussion, but the aim is to call it C++09 if and when it gets released next year:

    http://www.artima.com/cppsource/cpp0x.html 


  • Discourse touched me in a no-no place

    @Heron said:

    <font face="Lucida Console" size="2">x = 5*q = 7</font>

    The compiler would assign 7 to the pointer q (not the memory pointed at by q), then multiply 5 by q, and assign that to x. 

    I suggest you upgrade your compiler to one that conforms. It should not compile at all.



  • @Heron said:

    @bstorer said:

    Have you ever given any thought to why the language requires semicolons, when the compiler can figure out when one is missing?
     

    There are times where the compiler cannot figure out what to do.  Consider the following:

    <FONT face="Lucida Console" size="2">int* q = new int; int x = 5; q = 7;</FONT>

    What would happen if the semicolon were missing?

    <FONT face="Lucida Console" size="2">x = 5q = 7</FONT>

    The compiler would assign 7 to the pointer q (not the memory pointed at by q), then multiply 5 by q, and assign that to x.  That is certainly not the same.

    Yes, the compiler might be able to see that q is a pointer and therefore the * is dereferencing it, but multiplying by an int* is still technically possible, and maybe that's what the programmer intended for some reason.  I realize that few, if any, programmers would write something like the second statement on purpose, but they would certainly write things like the first snippet, and without semicolons the statement changes meaning.

    So you see, semicolons do serve a useful purpose.

    You'll have to find a better example. In both C and C++, multiplying by a pointer is not a valid operation.



  • @Heron said:

    There are times where the compiler cannot figure out what to do.  Consider the following:

    <font face="Lucida Console" size="2">int* q = new int; int x = 5; *q = 7;</font>

    What would happen if the semicolon were missing?

    <font face="Lucida Console" size="2">x = 5*q = 7</font>

    The compiler would assign 7 to the pointer q (not the memory pointed at by q), then multiply 5 by q, and assign that to x.  That is certainly not the same.

     

    Even assuming you could multiply a pointer (which you can't, as was pointed out), the = (assignment) operator has lower precedence than almost every other operator, including the unary * (pointer dereference) and binary * (multiplication).  Hypothetically, the compiler would not first assign 7 to q, then multiply by 5.  It would multiply 5 by q, then assign 7 to the resulting pointer (assuming that 5 * q is a valid lvalue, which it isn't).

     

    So your example fails in numerous ways. 

    It was also pointed out that semicolons are pretty much only useful if you need multiple statements per line.   As a (terrible) counter-example, semi-colons are optional in Javascript.  A newline is enough to terminate a statement in Javascript.




  • It appears I stand corrected.  It also occurred to me that even if it were a problem, the operator used to dereference a pointer could be changed, and the issue would disappear. 



  • @Heron said:

    It appears I stand corrected.  It also occurred to me that even if it were a problem, the operator used to dereference a pointer could be changed, and the issue would disappear. 

     

    I don't think the problem is in the operator used to dereference a pointer.  The problem is that "5 * q" is not an lvalue, whether you take it as 5 multiplied by q, or 5 (*q) (which doesn't even make any sense), so it doesn't make sense to even try to evaluate "5 * q = 7".

    Here's the 2 possibilities:

    int q = 5;

    5 * q = 7; // Oops, 5 * q is not an lvalue

    ///

    int p; 

    int *q =&p

    5 * q = 7; // This won't compile, because 5 (*q) is MEANINGLESS

    Indeed, if one tries to compile your example, the compiler complains about "invalid operands to unary *" or something to that effect.

    And your statement that the compiler would interpret your example as

    5 * (q = 7) 

    is false,  because of operator precedence, as explained above.  The compiler is not going to arbitrarily change operator precedence rules just to make sense of broken code.



  • @CodeSimian said:

    As a (terrible) counter-example, semi-colons are optional in Javascript.  A newline is enough to terminate a statement in Javascript.

    What the hell do you have against Javascript?  For your information, I am far too busy to reach for the semi-colon key.  It's under my weak little pinky, the France of the fingers!  Years of chronic masturbation have led to severe nerve damage in my right hand which makes typing a semi-colon a painful and erotic experience.  Try explaining to your co-workers why you have a perpetual erection when writing web frontends.

     

    And for those without a sense of humor: this was a joke.  Also, Javascript is a really shitty, painful language. 



  • @morbiuswilters said:

    What the hell do you have against Javascript?  For your information, I am far too busy to reach for the semi-colon key.  It's under my weak little pinky, the France of the fingers!  Years of chronic masturbation have led to severe nerve damage in my right hand which makes typing a semi-colon a painful and erotic experience.  Try explaining to your co-workers why you have a perpetual erection when writing web frontends.
     

    <FLAME!!!/>

    <FLAME!!!/> 

    <FLAME!!!/> 

    @morbiuswilters said:

    And for those without a sense of humor: this was a joke.  Also, Javascript is a really shitty, painful language. 

    Oh wait, shit... I uh... 

    You are a troll! You ruined this thread! GAH!



  • @MasterPlanSoftware said:

    @morbiuswilters said:

    What the hell do you have against Javascript?  For your information, I am far too busy to reach for the semi-colon key.  It's under my weak little pinky, the France of the fingers!  Years of chronic masturbation have led to severe nerve damage in my right hand which makes typing a semi-colon a painful and erotic experience.  Try explaining to your co-workers why you have a perpetual erection when writing web frontends.
     

    <FLAME!!!/>

    <FLAME!!!/> 

    <FLAME!!!/> 

    @morbiuswilters said:

    And for those without a sense of humor: this was a joke.  Also, Javascript is a really shitty, painful language.

    Oh wait, shit... I uh... 

    You are a troll! You ruined this thread! GAH!

    I really don't see how admitting to be a chronic masturbator is a flame of any kind. I think you just wanted to SAY SOMETHING in this thread. Were you feeling left out?



  •  @poopdeville said:

    I think you just wanted to SAY SOMETHING in this thread. Were you feeling left out?

    Pot meet kettle.



  • @MasterPlanSoftware said:

    Pot meet kettle.
    I don't like this idiom. The fact that the pot is black doesn't invalidate its claim that the kettle is black. The kettle being black is an objective fact that is valid no matter the colour of the one indicating it. Applying this idiom to others doesn't make any sense, either. A spammer calling another spammer a spammer is just as valid as the same statement uttered by a non-spammer! Stop being racist.



  • @Welbog said:

    Stop being racist.
     

    You are the only one to mention 'black'. You racist POS.



  • @MasterPlanSoftware said:

    You are the only one to mention 'black'. You racist POS.
    No, you!

    Anyway, that idiom rubs me the wrong way. It's completely meaningless since it doesn't invalidate anything said. It's really nothing more than a fancy way of saying, "No, you" which I'm sure we can all agree isn't a good way to have a conversation.



  • @MasterPlanSoftware said:

     @poopdeville said:

    I think you just wanted to SAY SOMETHING in this thread. Were you feeling left out?

    Pot meet kettle.

     

     

    Way to undermine your credibility.   You still haven't mentioned recursive C++ templates.  (Hint:  that's what the discussion was about)



  • @poopdeville said:

    @MasterPlanSoftware said:

     @poopdeville said:

    I think you just wanted to SAY SOMETHING in this thread. Were you feeling left out?

    Pot meet kettle.

     

    Way to undermine your credibility.   You still haven't mentioned recursive C++ templates.  (Hint:  that's what the discussion was about)

     

     And yet... I am still not the troll who follows me to whatever thread I might post in and flames away. Do you think I really care about your opinion?

    Get over yourself.



  • I consider making your stupidity obvious to all a public service.

    Still, this is my 48th post, to your 1599th (in about the same amount of time!). My pattern of harassment MUST end!!



  • @poopdeville said:

    Still, this is my 48th post
     

    And over half of them have been due to you following me around trolling. 

    It is pathetic, but I guess I should be flattered. If that is how you want to spend your time, be my guest.



  • It was also pointed out that semicolons are pretty much only useful if you need multiple statements per line. As a (terrible) counter-example, semi-colons are optional in Javascript. A newline is enough to terminate a statement in Javascript.

    well... sort of. The actual rule for javascript is "if you get an error, and the previous line did not end in a semicolon, try it with a semicolon inserted at that point" - which means if the code is syntactically correct but has different semantics without anything there, a newline will NOT terminate the statement. I've actually run into this.



  •  @MasterPlanSoftware said:

    And over half of them have been due to you following me around trolling. 

     

     

    Not really, no.  I did come out of lurker mode recently, mostly because I got sick of your stupid bullshit thread hijacking.  I come here to read interesting Sidebar WTFs, and learn best practices from the mistakes of others.  There's no need to "follow" you.  You post in almost every goddamned thread.



  • @poopdeville said:

    your stupid bullshit thread hijacking
     

    That is the lamest excuse I could imagine. But it is repeated by the other trolls like morbii who have nothing to do but wait for a post by me and flame away. 

    Tell me how *I* hijacked this thread. *You* are the one who continues to flame away. I do have the right to defend myself.

    @poopdeville said:

    You post in almost every goddamned thread.
     

    Again, get over yourself. I know it bothers you to see my name in any post I make, but do you think that every time I go to make a post I think "What would poop want me to do?" "How will poop feel about this post?" "I hope poop doesn't flame me after I post like he always does!"

    Jesus. Watch that ego, your head might stop fitting through the door.

     



  • I already said: I regard making your stupidity obvious to all a public service. It's fun and easy, too.



  • @poopdeville said:

    ...mental diarrhea...

    MPS only replied to my joke with a joke of his own.  Honestly, I probably started this thread derailing.  Still, it was you who jumped at the opportunity to start trolling him because you don't have the brain cells to comprehend the concept of humor.  STFU and DIAF.

     

    In an attempt to rerail this thread:  You guys seriously need to get out of college and get jobs.  I don't mean that offensively, but how much does it really matter if the grammar of C++ is undecidable?  There are dozens of things that make C++ an unholy mess.  Now, if you were writing a compiler, I'd feel nothing but sympathy for you.  No, I take that back, because you are willfully putting yourself through that misery and by doing so allowing this abortion to continue to haunt us.  So, yeah, C++0x is probably going to suck.  We will see copious abuse of even the most obscure of language features.  Gentlemen, we have not had ground this fertile for WTFery since SpectateSwamp was first introduced to a computer.



  • @morbiuswilters said:

    MPS only replied to my joke with a joke of his own. ... In an attempt to rerail this thread: You guys seriously need to get out of college and get jobs. I don't mean that offensively, but how much does it really matter if the grammar of C++ is undecidable? There are dozens of things that make C++ an unholy mess. Now, if you were writing a compiler, I'd feel nothing but sympathy for you.

    I don't mean to undermine your re-railment (and I will reply to that specifically shortly), but where I come from, jokes are funny. MPS didn't even understand your joke. And he made it abundantly clear that he hasn't read the thread. But he still felt compelled to post in it. Yes, it annoys me enough to post about it. I know I am not the only one. This is my last word on this topic.

    Regarding C++0x: the problem with an undecidable grammar is that it makes certain compiler optimizations impossible, many more plain old difficult, and greatly increases the compiler's complexity. g++ has been around for a good 20 years now, and has had a lot of the kinks removed, but it took that long to get where it is.

    For example: a decidable grammar allows many compilers to automatically turn recursive calls into tail-recursive calls.



  • @poopdeville said:

    MPS didn't even understand your joke.
     

    Actually, I think I understood the joke a lot better than you have. If you didn't find my reply funny, by all means ignore it, or flame it, or whatever. But don't try and act like you are some kind of knight in shining armor coming to the forum's rescue.

    @poopdeville said:

    But he still felt compelled to post in it. Yes, it annoys me enough to post about it. I know I am not the only one.

    You feel compelled to do the same thing in every thread where I post. What is different about this one?

    @poopdeville said:

    This is my last word on this topic.

    I really wish I could believe that.



  • @poopdeville said:

    I don't mean to undermine your re-railment (and I will reply to that specifically shortly), but where I come from, jokes are funny. MPS didn't even understand your joke. And he made it abundantly clear that he hasn't read the thread. But he still felt compelled to post in it. Yes, it annoys me enough to post about it. I know I am not the only one. This is my last word on this topic.

    His reply was a joke as well.  That is what you are missing.

     

    @poopdeville said:

    Regarding C++0x: the problem with an undecidable grammar is that it makes certain compiler optimizations impossible, many more plain old difficult, and greatly increases the compiler's complexity. g++ has been around for a good 20 years now, and has had a lot of the kinks removed, but it took that long to get where it is.

    For example: a decidable grammar allows many compilers to automatically turn recursive calls into tail-recursive calls.

    I am aware of this.  C++ is also a bitch to parse.  That's why I said I feel pity for compiler developers.  If you were referring to the speed of the generated binary being unsuitable, that's silly.  For most things, C++ is more than fast enough and if it isn't, you're probably using C or assembly anyway.  If you're the kind of person who is concerned about that level of optimization, you don't need an object-oriented language.  The biggest problem with C++ from a user of the language is that it's a fucking monstrosity.  It's almost impossible to hold it all inside your head at the same time.  This comes back to bite you when working on a team with someone who decides to bust out some obscure feature you never learned or have since forgotten.  Due to the sloppy construction of the language, there are also all kinds of gotchas involving constructors, memory allocation, header files and on and on and on...  The end result is experienced C++ devs utilize all kinds of bizarre practices to work around language limitations and if you aren't skilled in this dark art, you are essentially SOL.

     

    If you like C++, that's fine for you, but I mostly loathe it.  Pinning it's problems on an undecidable grammer is a little absurd, though.  Yes, it's a big problem, but C++ is so full of them.  I think this was also the point the OP was trying to make, that any extension of C++ is going to just add more and more shit into the language until it collapses and destroys the universe.

     



  • @morbiuswilters said:

    I am aware of this.  C++ is also a bitch to parse.  That's why I said I feel pity for compiler developers.  If you were referring to the speed of the generated binary being unsuitable, that's silly.  For most things, C++ is more than fast enough and if it isn't, you're probably using C or assembly anyway.  If you're the kind of person who is concerned about that level of optimization, you don't need an object-oriented language.  The biggest problem with C++ from a user of the language is that it's a fucking monstrosity.  It's almost impossible to hold it all inside your head at the same time.  This comes back to bite you when working on a team with someone who decides to bust out some obscure feature you never learned or have since forgotten.  Due to the sloppy construction of the language, there are also all kinds of gotchas involving constructors, memory allocation, header files and on and on and on...  The end result is experienced C++ devs utilize all kinds of bizarre practices to work around language limitations and if you aren't skilled in this dark art, you are essentially SOL.

     I kind of agree with you, but I also think that some people can go out of their way to use some niche features of the language and made it harder than it has to be. I say throw bizzare practices out of the window and stick to solving problems, not just using some little known feature because you think it's cool.



  • @pitchingchris said:

    I kind of agree with you, but I also think that some people can go out of their way to use some niche features of the language and made it harder than it has to be. I say throw bizzare practices out of the window and stick to solving problems, not just using some little known feature because you think it's cool.

    Yes, but the problem is that C++ is so fucking full of niche features.  Everything is an edge case.  And they all interact in strange, unexpected and dazzling ways.  I'm not gonna claim to be a C++ expert, but I've seen enough shitty code written by developers who are competent in a language like C or Java.  I've also encountered so many workarounds for the flaws in the language that I'm convinced C++ is a work of pure evil.  Since I don't have to code C++ on a day-by-day basis, I don't bother remembering or practicing a lot of the workarounds, but the fact that they exist is proof enough that the language is deeply flawed.



  • @morbiuswilters said:

    In an attempt to rerail this thread:  You guys seriously need to get out of college and get jobs.

    I have a job, and it thankfully requires no C++ programming from me.  But while we're on the subject, when I was in college, I couldn't have evaluated whether or not C++ was a good language.  We used it in all our programming-intensive classes, so it must be pretty good, right?  It took leaving college and getting a job and writing legitimate, large-scale programs in other languages to realize that C++ wasn't as great as I'd been lead to believe.

    I don't mean that offensively, but how much does it really matter if the grammar of C++ is undecidable?

    To you?  Probably not a whit.  To most people, in fact, it doesn't matter.  But this amuses me: we mock other programmers on this site for commiting some pretty minor WTFs, but C++ contains many massive WTFs.

    There are dozens of things that make C++ an unholy mess.

    I don't understand.  Is this somehow a point in C++'s favor?  Or a justification of an undecidable grammar?  Seems like it makes a pretty good argument that the undecidable grammar is symptomatic of the language as a whole.

    Now, if you were writing a compiler, I'd feel nothing but sympathy for you.  No, I take that back, because you are willfully putting yourself through that misery and by doing so allowing this abortion to continue to haunt us.

    Wait, which side are you arguing again?

    So, yeah, C++0x is probably going to suck.  We will see copious abuse of even the most obscure of language features.

    What I don't get about C++0x is that their solution for a cumbersome, syntax-heavy language is to throw more keywords and syntax into it.

    Gentlemen, we have not had ground this fertile for WTFery since SpectateSwamp was first introduced to a computer.
      Hmmm, anyone wanna rewrite SSDS in C++0x?



  • @bstorer said:

    Hmmm, anyone wanna rewrite SSDS in C++0x?
     

    Obviously, we should rewriting C++0x in SSDS.


Log in to reply