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

81–90 of 146 posts

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

#81

Post by coldpie »

jonstewart wrote: post #68
lallysingh wrote: post #2

This is why the tools situation in c++ had been so far behind other languages like Java. You have to build a full frontend to even parse the language. They're slowly becoming available via clang now, which is nice.

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 this feature effectively impossible.

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

#82

Post by unrealhoang »

jokoon wrote: post #32
xiphias2 wrote: post #25

Earlier quoted context omitted.

Rust seems to be the most successful zero-overhead language competitor to C++, though it's far not as mature as C++ yet.

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.

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

#83

Post by zamadatix »

etalian wrote: post #59
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.

I wondered the same a while ago, and it turns out you can, in fact to test this hypothesis I ended up implementing such a language myself. The resulting syntax can express every construct from modern C++, is fully LALR(1) (no ambiguities and no vexing parses), has fewer keywords and is in general shorter than the equivalent C++ code, and once you know the syntax it is (subjectively) easier to read too (no spiral rule…

Do you have any examples of the syntax?

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

#84

Post by gmueckl »

bluGill wrote: post #74
gmueckl wrote: post #69

Earlier quoted context omitted.

Well, GC latencies don't bother game developers who work with Unity or people using Java or C# for high speed trading. Realistically, having the option to use a GC is a boon for many applications. Not everything is hard realtime all the time. Some complex applications tend to have a hard realtime part and parts where it doesn't matter. E.g. a CNC machine controller does not need a guaranteed response time for the HMI…

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.

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

#85

Post by seanmcdirmid »

einpoklum wrote: post #80

Key point: > In practice, compilers limit template instantiation depth, so this is more of a theoretical problem than a practical one.

Magic numbers to limit undecidability are incredibly fragile. You think you have all the cases covered and another comes up, or the numbers need to be enlarged because of some reasonable code being rejected.

Better to have this problem in the parser than the type checker, at least.

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

#86

Post by atilaneves »

pjmlp wrote: post #19
skocznymroczny wrote: post #13

Earlier quoted context omitted.

In theory that's D. D was designed to be easier to parse than C++, for example, it uses Foo!Bar and Foo!(Bar, 4) template syntax rather than Foo and Foo . On the other hand, it still uses templates and supports mixins (basically #define on steroids), so while it's easy to parse, large chunks of code don't exist until compile time so can't be indexed by IDEs perfectly.

And as much as I like their community, I feel it already lost its spotlight opportunity, due to their lack of manpower vs other languages offerings and continuous improvements. Even if C++ is a little baroque, C++17 and now C++20 provide many of the D's benefits, while keeping all the libraries, and finally we are getting Java like C++'s tooling to just throw it away.

I went back to C++14 a few years ago after writing D and it was painful. The only addition to C++17 that made my life easier was `void_t`, but even then it's not even close.

Having to deal with headers again and C++'s templates was torture.

Did C++ close the gap? Yes. However, I can still write D 2-3x faster than I can write C++. It's similar to how I'm 2-3x more productive in C++ than in C.

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

#87

Post by jstimpfle »

pjmlp wrote: post #33
jstimpfle wrote: post #28

Earlier quoted context omitted.

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing,…

On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.

Of course there will always be some issues somewhere. But, ignoring perfect memory safety, the issues are widely overblown, to the extent that I find manually managing memory a lot easier than dealing with GC once a project grows beyond a couple KLOC.

It's all about proper planning and code organization. Use pooling, central manager structures, etc. If it can be avoided, then do not allocate and free stuff in a single function like you would carelessly do with automated GC. Structure the data such that you don't have to release stuff individually - put it in containers (such as vectors or maps), such that you can release everything at once at certain points in time, or such that you can quickly figure out what can be released at central code locations (that's much like automated GC, but it's staying in control and retaining room for optimization).

I don't think "multiple distributed teams" makes the challenge any harder. You certainly want to (and I'm sure you easily can) contain each ownership management domain wholly in one team.

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

#88

Post by gmueckl »

bluGill wrote: post #77
gmueckl wrote: post #70

Earlier quoted context omitted.

I don't think that your statement about C with C++ compilers holds true anymore. I have seen quite a few codebases that are definitely C++, but use bespoke memory management strategies where required. Pool allocators and allocation-only heaps are high on the list of things that are useful in this area, for various reasons.

I'd call most of that C with classes.

As ooposed to what? This is the core of C++, even though feature creep has opened up the language to other coding styles and patterns.

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

#89

Post by thesuperbigfrog »

jokoon wrote: post #32
xiphias2 wrote: post #25

Earlier quoted context omitted.

Rust seems to be the most successful zero-overhead language competitor to C++, though it's far not as mature as C++ yet.

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.

Rust and Ada are are only incidentally competitors:

Ada was designed for programming safety-critical, military-grade embedded systems.

Rust was designed as a memory-safe, concurrency-safe programming language, largely to overcome the shortcomings of C++.

Each excels at what it was designed for, but the intended use cases are very different.

Rust is not (currently) being used for aircraft flight control systems--Ada is.

Ada is not (currently) being used for high-performance web browsers and servers--Rust is.

While there are SOME similar design goals in terms of memory safety, concurrency safety, and error prevention, Rust was not designed to compete with Ada.

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

#90

Post by [deleted] »

tralarpa wrote: post #48
vkazanov wrote: post #40

Earlier quoted context omitted.

"Formal education in CS" is not the same as, say, a degree related to programming languages or compilers.

Yes. There is a section in one of his books where he wrote that he added some feature in an ad-hoc way just because of a request from a colleague. Unfortunately, as I have already written in another comment some months ago, C++ was the wrong thing that came at the right time (C people were starting looking for alternatives, seeing what cool things other languages were doing).

[deleted]
Post reply on HN