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

141–146 of 146 posts

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

#141

Post by einpoklum »

seanmcdirmid wrote: post #85
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.

There's no assumption that all the cases are covered up. Only some. The point is - in practice, don't try to go in too deep with templates.

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

#142

Post by jacobush »

pjmlp wrote: post #123
jacobush wrote: post #71

Earlier quoted context omitted.

I should have said "not garbage collection" instead of manual memory management.

Reference counting, regardless how it is implemented (language primitives or library), is a garbage collection algorithm.

This is stretching definitions imho. Ref counting does not stop the world or kick in when you don’t expect it to.

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

#143

Post by otabdeveloper4 »

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+…

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development.

Yeah, I've heard that 25 years ago. It was, in fact, the big marketing bullet point on Java's first release.

Meanwhile here in 2019, with the death of Moore's Law, careful memory (and cache!) management is more important than before.

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

#144

Post by otabdeveloper4 »

gmueckl wrote: post #51
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.

The GC is realistically only an issue in rare fringe cases. Early on, the competing standard libraries were a massive problem, though. This was overcome with D2, which is already more than a decade old. When this standard library competition existed, the library ecosystem had this very weird split where half of the libraries you would have liked to use in your project used the other library you couldn't link to at th…

> The GC is realistically only an issue in rare fringe cases.

Yes, and one of those fringe cases is when you're building a competitor for C++.

Knowing your target audience helps if you're trying to take over the world.

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

#145

Post by choeger »

bigcheesegs wrote: post #29
choeger wrote: post #22

This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…

What do you mean by wild compiler hacks?

For instance the proposed solution where the compiler becomes a service that blocks compilation of a unit until it has seen all the module dependencies.

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

#146

Post by thesz »

bitwize wrote: post #60
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+…

Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a s…

Using trees of resources is building nondeterministic amount of latency into your system.

One of my first (after awhile) forays into C++ was to analyze big WFST graph to find various statistics. And I found that my program spent as much time freeing resources as doing actual work. Subjectively, of course, yet.

I knew it can happen, so it was not big surprise.

Post reply on HN