Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parsing C++ is literally undecidable (2013)

blog.reverberate.org

Post reply on HN
Print view View original

111–120 of 146 posts

Re: Parsing C++ is literally undecidable (2013)

#111

Post by igor_akhmetov »

uglycoyote wrote: post #98
bluGill wrote: post #93

Earlier quoted context omitted.

Java had it first (by at least 10 years), but C++ IDEs do the same. Clang not being designed to make it impossible to access the AST has made this feasible for most IDEs. There are still cases where it cannot be done (macros), but in many cases it can be done now.

Jetbrains makes excellent refactoring tools for multiple languages so I usually use their tools as my gauge of how well a language lends itself to refactoring. As a daily user of Resharper in both C# and C++, I really notice how much poorer they work in C++. Renaming operations, as you mentioned, do work in C++ sometimes, but not others. Generally if it is a variable or parameter that's used locally I can rename it i…

Please file bugs in http://youtrack.jetbrains.com/issues?q=%23RSCPP for the issue you encounter.

Re: Parsing C++ is literally undecidable (2013)

#112

Post by im3w1l »

biggestdecision wrote: post #95
pjmlp wrote: post #24

Earlier quoted context omitted.

Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…

Swift's GC is really a lot closer to modern C++ style memory management than the other languages you mentioned. If you use RAII & shared_ptr in C++ you are using the exact same techniques that Swift's "GC" uses.

Maybe. But shared_ptr should only be used very sparingly. Almost all objects should be stack or unique_ptr.

Re: Parsing C++ is literally undecidable (2013)

#113

Post by waynecochran »

john_moscow wrote: post #100

As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…

I have never written code to translate templates. Do you actually build a syntax tree for the template itself? I always assumed you would just store a simpler representation of the template (e.g., just a string of lexemes) and only build syntax trees when the template is instantiated.

Of course you still need to "parse" the template when it is encountered but you have to do it without semantic information (e.g., you don't know what `a` will expand to until instantiation) -- I guess that is the problem.

It is funny that Lisp's defmacro doesn't have this problem because the code itself is a syntax tree.

Re: Parsing C++ is literally undecidable (2013)

#114

Post by _bxg1 »

rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

C--

Re: Parsing C++ is literally undecidable (2013)

#115

Post by _bxg1 »

bluGill wrote: post #91
rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

There are been hundreds of attempts using a number of different ideas. The reason for C++ and not those alternatives is there is a lot of C++ code. If most of my code is C++ I don't gain anything from your new language as I spend most of my time maintaining old code. Even if I use your language for new code that means I constantly have to remember if I'm fixing a bug using C++ code rules or the new language rules. So…

In other words it's the same network effects that weigh down any attempt at creating a new ecosystem. So if you're going to do that, you may as well start from scratch and do things better from the get-go.

Re: Parsing C++ is literally undecidable (2013)

#116

Post by rozab »

john_moscow wrote: post #100

As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…

Do Java and C# not have any problems like this?

Re: Parsing C++ is literally undecidable (2013)

#117

Post by fusilli_jerry »

john_moscow wrote: post #100

As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…

To be clear here though, you can always (*undecidably, but subject to practical constraints) fully parse a template definition into a parse tree, and that parse tree will not change for any instantiation.

In your example, 'a' is known at parse time to either be a type or a value even if it's a template parameter, so the statement will always parse one way or another. Of course, 'a' itself may change in type or value so the problem is still unwieldy and, probably key to your use case, requires knowledge of type information from a possibly far-off part of the translation unit.

Re: Parsing C++ is literally undecidable (2013)

#118

Post by waynecochran »

john_moscow wrote: post #100

As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…

Might as well throw in the most vexing parse (https://en.wikipedia.org/wiki/Most_vexing_parse) with it:

    void func()
    {
       a  d();
    }

Re: Parsing C++ is literally undecidable (2013)

#119

Post by waynecochran »

rozab wrote: post #116
john_moscow wrote: post #100

As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…

Do Java and C# not have any problems like this?

Generics are not templates (i.e., not instantiated at compile time) so you avoid a lot of this mess.

Re: Parsing C++ is literally undecidable (2013)

#120

Post by john_moscow »

fusilli_jerry wrote: post #117
john_moscow wrote: post #100

As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…

To be clear here though, you can always (*undecidably, but subject to practical constraints) fully parse a template definition into a parse tree, and that parse tree will not change for any instantiation. In your example, 'a' is known at parse time to either be a type or a value even if it's a template parameter, so the statement will always parse one way or another. Of course, 'a' itself may change in type or value…

Yeah, good luck with this one then:

  template  void func()
  {
    foo::a  d;
  }
Post reply on HN