Hacker News Reader

Comment by SuperV1234 | Hacker News Reader

Most of these features have been used by countless C++ developers for the past decades -- I really don't see the point in adopting a language that's mostly C++ but without some of the warts. Either pick C++ or something like Rust.

View on HN

I would prefer a "lightweight" C++.

C++ is fine, but it's insanely slow to compile.

I generally like C++, but I could trade anything to make it faster to compile, and most of the time, I just use a small subset of C++ that I feel okay with.

Pre-compiled headers, binary libraries, avoid header only libraries, if lucky to be on latest clang/VC++, modules.

pch are not standard

Modules support was added recently, and I don't think most libraries or cmake support it yet, and I don't really see tutorial about good practices for modules, especially when it comes down to speeding up compilation.

Also modules do not really speed up compilation that much, apparently, or I have not seen benchmarks, maybe because modules are not well supported yet?

Modules are great in theory, but I am not sure they are usable in 100% of cases, especially with all the existing code that is out there?

C++ is not slow to compile. The Standard Library is.

C++ is just slow to compile. With the standard library it is much worse. The problem is that with C++ you're not getting as much encapsulation as you would in C unless you do extra work that also has a performance hit (pimpl). This means that C++ code often has to recompile a whole lot more than C code does when doing incremental compilation in my experience.

This is just not true. There's nothing that makes C++ inherently slow to compile.

PImpl doesn't need to have a performance hit as you can implement it with a local fixed-sized buffer that's not heap-allocated.

You can also design your C++ codebase exactly as you would in C, so there's literally no reason why you'll need to recompile more in one language compared to the other.

C++ is not context free.

A quick google "c++ grammar" will give you clues that C++ is not you average language. Templates are also turing complete, and probably not trivial to parse.

Of course I am not talking about C++98, but C++14, 17, etc, which add significant stuff.

C3 benefits from focusing more on the problem at hand than language complexities.

There are definitely advantages to simpler tools, you can streamline development and make people more productive quicker. Compare that scenario to C++ where you first have to agree the features you're allowing and then have to police that subset throughout on every PR.

Is for the C++ without Classes crowd, mostly.

Personally when I initially learned C++ back in 1993, with Turbo C++ 1.0 for MS-DOS, I hardly saw a reason to further use C instead C++, other than being required to do so.

the problem with picking C++ is that eventually you onboard someone who uses the warts in their code, and then the warts become like craft glitter.

Maybe instead of building a restricted C++ we should be building parsers that restrict what C++ features we use.

It is called static analysis tool.

A matter of code review and static analysis configuration.

Unfortunately adhering to modern tooling is always a quixotic battle, even when they come for free on modern FOSS compilers.

To me it didn't really feel like C++; it is much less complicated. Could you explain more what you mean by this?

C3 is "mostly C++" in the same way that my bicycle is "mostly a motorbike".

Reply on news.ycombinator.com