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

91–100 of 146 posts

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

#91

Post by bluGill »

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. Some projects have successfully done this and eventually re-wrote everything. However others have not and the pain of a new language is a problem.

The other problems with that approach means C++ is everywhere.

I know that I can find a good compiler for C++ when I want to switch platforms. Will your new language support my new platform? Will your new language even exist? I've worked on a number of projects where the code was written in some language where the compiler vendor is out of business. This risk works against all new languages (some have overcome it, some have not).

With C++ I know if I need to hire more people I can hire experts to help out. If I choose your language do I have to pay my new employees to learn the language for the first few months? Learning my code (which is always hard no matter what the language) is already going to be a problem using something that nobody knows just makes it worse.

Will your language optimize well? C++ being everywhere means that compilers vendors have put a lot of effort into writing good optimizers. When performance matters C++ will often come in first because of this effort.

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

#92

Post by bluGill »

gmueckl wrote: post #84
bluGill wrote: post #74

Earlier quoted context omitted.

GC latencies doesn't bother them, because they put large efforts into ensuring there is not garbage to collect. Tricks normally reserved for hard real time embedded systems like allocating all memory buffers at startup time. GC is very useful for programs that don't have any form of real time - but games are real time and thus you need to be careful to ensure that the worst case of the garbage collector doesn't harm…

I have never seen such memory mamagement tricks employed in Unity scripts. I'm not saying that they don't exist. They are only rarely required. To be honest, I expected things to be much worse from previous experiences.

There are of course a large number of it depends. Sometimes there isn't a problem sometimes there is.

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

#93

Post by bluGill »

coldpie wrote: post #81
jonstewart wrote: post #68

Earlier quoted context omitted.

Can you be more specific and/or support the argument that the tools for C++ are behind what's available for Java? Visual Studio has had Intellisense since forever, clang-format can enforce style standards, static analyzers these days are amazing, the address sanitizer and valgrind find memory problems easily, etc.

> Can you be more specific and/or support the argument that the tools for C++ are behind what's available for Java? The most obvious example to me is in Eclipse, you can right-click on a field in a Java class and choose to Rename it. It will then correctly update that field's name across the entire codebase. AFAIK this is impossible in C & C++ because they are such complicated languages to parse. Macros alone make th…

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.

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

#94

Post by mamcx »

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.

> Can we design a language (cpp-prime?)

I dislike, a lot, the C family of languages. I wish that the pascal or oCalm have "won". But being practical, we are stuck in this reality, so:

Is not "we". Is "them". I think only IF the core developers of that languages provide the "blessed" syntax it could actually catch up.

What I have wondered is why C/C++/JS not provide a "clean up" forward policy.

I think all involved are smart enough to see what is wrong with that langs (we always know what suck of what we build with time). Then say:

"This is $IDEAL-C we will targeting. This will fix this list of problems, and maybe this other list, BUT...

$IDEAL-C is a in-progress. Each change is iterative, and will deprecate in steps.

$BAD-C will be continued to be develop. $IDEAL-C transpile to $BAD-C. $IDEAL-C is another file extension. It will keep the same $IDEALS of $BAD-C.

Eventually, $IDEAL-C-STEP-1 will replace $BAD-C and become $BAD-C. And that until we reach $IDEAL-C! "

I know this look like what modern c/c++/js is doing, but the trouble is that that are additive changes. That mean triple work: Keep with $new, still have the problems of $old and maintain $both stuff at the time. What is lacking is doing subtractive changes and REMOVE what is wrong.

The key is transpiling, and not change the core tenants of the lang (ie: C stay as a razor edge).

The big problem, probably, is to not do drastic paradigm changes (ie: turn C in a functional lang), instead, clean the lang until is like what a good, idiomatic, modern developer of it will use.

I think is doable to make $IDEAL-C/C++/JS to be near identical to most developers and from a distance, not look different at all. Being progressive and in steps, provide auto-tranforming tools along the way and I think the community will move on.

I have see, partially, the idea applied with C#, so I think is doable?

P.D: Probably $IDEAL-C must only fix a very small list of stuff, initially. For example, lets say "Remove dangling IFs from C. END"

That its. This small-scope is I think, the key to make the experiment worthwhile.

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

#95

Post by biggestdecision »

pjmlp wrote: post #24
otabdeveloper4 wrote: post #20

Earlier quoted context omitted.

> due to their lack of manpower vs other languages offerings and continuous improvements No. D failed due to a mandatory GC and the 'two standard libraries' idiocy.

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.

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

#96

Post by oblio »

fanf2 wrote: post #46
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.

Damian Conway has a couple of papers from 1996 suggesting a better syntax for C++ http://users.monash.edu/~damian/papers/#Human_Factors_in_Pro...

You know your proposal failed when there's people born back then that have just finished college this year and they still won't be able to use the changes you proposed ;-)

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

#97

Post by jokoon »

unrealhoang wrote: post #82
jokoon wrote: post #32

Earlier quoted context omitted.

Rust has a high learning curve (borrowing, etc). Rust is a competitor to ADA, not C++. You can certainly ask developers to write things in rust instead, and even progressively rewrite codebase in rust since it's compatible with C++, but a language is about adopters, and ease of learning for beginners and students.

Counterpoint, Rust is actually easier to learn, and take way less time from inception to writing production-ready code.

even the tutorial says that borrowing has a high learning curve

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

#98

Post by uglycoyote »

bluGill wrote: post #93
coldpie wrote: post #81

Earlier quoted context omitted.

> Can you be more specific and/or support the argument that the tools for C++ are behind what's available for Java? The most obvious example to me is in Eclipse, you can right-click on a field in a Java class and choose to Rename it. It will then correctly update that field's name across the entire codebase. AFAIK this is impossible in C & C++ because they are such complicated languages to parse. Macros alone make th…

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 instantly with no problem. If it's a variable exposed in the class header, then it will tend to sit there churning for enough time before I decide that I should probably cancel the operation.

Likewise, simply using a "Find References" or "Find Usages" in C++ usually works, but at times it gives odd suggestions of things that are clearly not usages of the thing I'm searching, but something else with the same name that it just is not smart enough to understand is not a real usage. (possibly due to the difficulty of parsing templates or macros)

"Extract Method" is one of my favorite C# refactorings. Resharper C++ also has this operation but it is a bit of a gong show, and generates results that usually have to be tidied up considerably afterwards.

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

#99

Post by alexhutcheson »

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's not really a need anymore, because LibClang[1] has solved the parsing problem. Historically it was really hard to write tooling (syntax highlighters, static analyzers, scripts to update build dependendencies, etc.) for C++ due to the difficulty of parsing the language. In the past several years, that has completely changed - you just call LibClang to handle the parsing for you, and work with the high-level abstractions provided by LibClang instead of munging the text yourself. There are lots of reasons to want to replace C++, but "it's hard to write a parser" is no longer a relevant one.

[1] https://clang.llvm.org/docs/Tooling.html

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

#100

Post by john_moscow »

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 (and hence the meaning of a would change based on the instantiation).

Post reply on HN