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

121–130 of 146 posts

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

#121

Post by fusilli_jerry »

john_moscow wrote: post #120
fusilli_jerry wrote: post #117

Earlier quoted context omitted.

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; }

This is still not ambiguous: in order for 'foo::a' to be a template, 'a' must be prefixed with the 'template' disambiguator keyword, and in fact for any of a, b, or c to be types at all they would have to be prefixed with 'typename'. As written, it must parse as two expressions; if 'foo::a' turns out to be a class template at instantiation time, it's an error.

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

#122

Post by xiphias2 »

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.

I wanted to understand why Ada is not used in systems programming if it's so great, and found the answer:

,,Ada developers either use a garbage collector, or they avoid freeing memory entirely and design the whole application as a finite state machine (both of which are possible in Rust, too, but the point is you don’t have to).

Of course, Ada has range-checked arithmetic, which Rust doesn’t have (it needs const generics first before that can be done in a library), so if you’re more worried about arithmetic errors than dangling pointers, then you might prefer Ada.''

For me not freeing memory sounds like a joke. It's the opposite of zero cost abstraction. Regarding GC there are lots of great languages already (for example modern Java).

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

#123

Post by pjmlp »

jacobush wrote: post #71
pjmlp wrote: post #55

Earlier quoted context omitted.

The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers". The rest of the C++ world has long moved into automatic memory management as best practices.

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.

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

#124

Post by jokoon »

xiphias2 wrote: post #102
jokoon wrote: post #97

Earlier quoted context omitted.

even the tutorial says that borrowing has a high learning curve

The biggest problem with C++ is that all real life production code is full of memory safety bugs. People usually just live with it. If you want to minimize memory safety issues, C++ becomes even harder than Rust.

STL containers usually makes things easier.

Usually the libraries deal with low level issues and are doing the hard work of increasing safety.

Safety will always has a cost somewhere.

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

#125

Post by pjmlp »

atilaneves wrote: post #86
pjmlp wrote: post #19

Earlier quoted context omitted.

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.

I only use C++ alongside Java and .NET, when they need an extra help.

The problem with D in its current state is that its tooling isn't match for OS SDKs + IDE + libraries, beyond the typical POSIX daemon scenarios, unless one is willing to put some effort into it.

So it is hard to catch up to C++, specially after all major compilers reach C++20 compliance.

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

#126

Post by lallysingh »

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.

A C++ parser needs a semantic analyzer. The grammar is context sensitive. Eyeball a full year for an engineer to get one that's actually standards compliant. I've written a Java parser in two weeks in grad school while taking classes. You can easily use a parser generator (like ANTLR) because you have a context-free grammar.

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

#127

Post by lallysingh »

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

Java has generics and overloading; how far can you realistically get before building a full frontend? Honest question.

The grammar is still context free.

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

#128

Post by V_Terranova_Jr »

thesuperbigfrog wrote: post #89
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.

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

Ada has been on the way out, at least in recent U.S. DoD flight system developments (and likely NASA as well) for a long time. I don't see this trend reverting any time soon.

On the other hand, we can, and I hope will, move to much more rigorous approaches, such as the use of Rust, for flight software implementations. As you say, Rust was not specifically designed to compete with Ada, but accomplishes a number of similar goals and ultimately strives for correctness-by-construction, as does Ada.

We will be better off in flight software using newer, safer languages employed by the software community writ large instead of trying to mandate niche languages.

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

#129

Post by jonstewart »

lallysingh wrote: post #126
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.

A C++ parser needs a semantic analyzer. The grammar is context sensitive. Eyeball a full year for an engineer to get one that's actually standards compliant. I've written a Java parser in two weeks in grad school while taking classes. You can easily use a parser generator (like ANTLR) because you have a context-free grammar.

It's well known that C++ is hard to parse. What's less well known is _how much_ the tools have gotten better in the last 10 years.

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

#130

Post by thesuperbigfrog »

V_Terranova_Jr wrote: post #128
thesuperbigfrog wrote: post #89

Earlier quoted context omitted.

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

Ada has been on the way out, at least in recent U.S. DoD flight system developments (and likely NASA as well) for a long time. I don't see this trend reverting any time soon. On the other hand, we can, and I hope will, move to much more rigorous approaches, such as the use of Rust, for flight software implementations. As you say, Rust was not specifically designed to compete with Ada, but accomplishes a number of sim…

>> Ada has been on the way out, at least in recent U.S. DoD flight system developments (and likely NASA as well) for a long time. I don't see this trend reverting any time soon.

Yeah, C++ has been working out great on the F-35.

>> On the other hand, we can, and I hope will, move to much more rigorous approaches, such as the use of Rust, for flight software implementations.

Competition is good and more choices for building avionics systems are welcome. I don't know of any DO-178C certified Rust implementations, but we need them.

>> We will be better off in flight software using newer, safer languages employed by the software community writ large instead of trying to mandate niche languages.

Part of the issue is that high-integrity, hard real-time embedded systems are their own niche in terms of requirements. Java and C# are widely-used programming languages with hundreds of millions of lines of code deployed in business-critical production environments and yet both are unsuitable for avionics environments. The more avionics niche-specific a programming language becomes the more likely it is to add complexity and features that those who program outside the niche will never use or care about.

Post reply on HN