Hacker News Reader

Comment by artagnon | Hacker News Reader

Here are a couple of expertly-written C++17/C++20 repositories:

https://github.com/hanickadot/compile-time-regular-expressio...

If you've not written C++ code before, it can take a while to catch up with the latest developments in C++23. Start with C, and learn these, in approximately the specified order:

1. lvalue references.

2. Constructors, destructors, and inheritance.

3. Annotations such as const and noexcept on members.

4. Simple type templates, and value templates.

5. constexpr, std::move, and rvalue references.

6. Type traits and std::enable_if.

7. Concepts.

Once you learn the core language features, learning the various data structures/algorithms in `std` should just be a matter of looking them up in cppreference, and using them over and over again.

Good luck.

View on HN

This is excellent. FWIW I bought and read "C++ Crash Course" by Lospinso. I found that tremendously helpful with his approach of "assuming you really know C [I do], here is C++" and can easily recommend his book for anyone on this path.

That said, I like your ordering too.

The other confounding factor is that I have also written a lot of Java code (both during the development of the language and afterward for my column in Javaworld) which I really enjoyed, but it too "fixes" some things which James disliked about C++ (and as a long time C programmer I understood quite well).

As a learning experience, this journey has been confounding, enlightening, and painful in equal measures :-)

People who come to C++ from Java frequently bring with them Java Disease.

If you find yourself reaching for std::shared_ptr and virtual functions more often than once in a blue moon, you are suffering from Java Disease, and are writing bad code.

Anything that seems to be something Java "fixed" is a thing they failed to understand. You will have to unlearn those, along with myriad bad C habits, many of which you don't know you have. It takes sharp observation to catch them.

Okay, if somewhat harsh :-).

As someone with north of 15 programming languages that I consider myself "fluent" in, albeit some latency involved in ones I've not used for a while, I always look for the idiomatic expression of computation. It is the difference between "writing FORTRAN in <x>, and writing an algorithm in <x>."

One of main the reasons I posted the question is that I found that design patterns I expected to be there, were not there, or were not idiomatic, and for whatever reason I am reasonably good at figuring out when something is "not quite right."

That said, I think it is unfair to characterize the choices of any language designer as either ignorant or wrong. As someone who participated in the design of Java I can assure you that the team "understood" why C++ did what it did. During that development, if there was any confusion, Guy Steele, whose office was three down from mine, would eloquently explain it so that everyone could understand it. That is not to say there weren't different opinions about "better" ways and "worse" ways to do things, Bill Joy was never a big fan of the Java choices and often took the opposing view across from Gosling. The language that Bill was designing was called 'Self' and it embodied his design choices, just as Java embodied Jame's design choices.

Me, as a systems guy, could really care less if Boolean was a first class type or just a uint1. I just want to write code that works.

I can assure you that anybody who makes members virtual by default does not understand the feature, even if that body is named Steele.

What was much worse was copying in wholesale the C crap that C++ had been obliged to adopt to maintain backward compatibility with C, when Java faced no such constraint.

I appreciate that you are consistent.

Have you considered self ? https://selflanguage.org/

I visited Craig Chambers at Stanford in the 80s... I never heard of Bill Joy having anything to do with Self.

Cool, from the self web page -- "The project continued at Sun Microsystems Laboratories until 1995, where it benefited from the efforts of Randall B. Smith, Mario Wolczko, John Maloney, and Lars Bak."

Java was released in March of 1995, about 1/3 of the original Java group left after the 1.0 release (not in a small part because of Sun's attitude). I made the mistake when I went to work at Google of disparaging Self (which Urs Hoezle had worked on and was my boss's boss, oops!) But much of the original Java team had ended up there so it was kind of a fun to catch up.

So when you visited Craig at Stanford did you get along with him?

Seems like 30 years ago. (Because it was?) He was busy, I was an interruption. But he was gracious abt it. I recall I was a lot more interested in tail-call elimination, at the time, than he was.

Self was seminal in two ways: prototypes instead of classes influenced Javascript, and code splitting presaged perhaps the most important JIT technique.

We might have been better off today if Eich had just picked up Self instead of throwing together Javascript. But honestly I don't know either well enough to say.

> I can assure you that anybody who makes members virtual by default does not understand the feature, even if that body is named Steele.

You may be reviled by that design decision, and the ramifications thereof, but I'd put my money on Guy Steele having a sharp grasp of the feature, the alternative design decisions, and the ramifications of most possibilities. If I were designing a language, and could pick any of a handful of people to help with the design, Guy would be near the top of the list, if nothing more that for his ability to explain things clearly and succinctly.

I can imagine Steele advising against it, and Gosling ignoring him and doing it anyway. I earnestly hope that is what happened.

I cannot account for Java having retained so many misfeatures of C despite having no backward-compatibility constraint, other than that nobody was paying any attention.

> anybody who makes members virtual by default does not understand the feature

Which is hilarious coming from C++ people who blindingly obviously didn't understand the features of Smalltalk.

C++ is not cribbed from Smalltalk. Smalltalk is cribbed from Bjarne's thesis adviser's language, Simula. So, any differences you find are direct results of Smalltalk departing from Simula.

As a sibling comment mentioned - somewhat harsh. I can relate to it. I've seen c++ code where they created an entire class hierarchy from "Object".

Well this is what Qt does as far as my understanding goes. If you write Qt applications everything to be used in Qt must derive from QObject. I wouldn't call Qt bad because of that. Sure there's overhead with the vtables but that isn't a problem for everyone.

Qt was first released when C++ had no more organizational features than Java, so it gets a free pass.

QObject is not Qt's greatest sin. That would be its lower-case macros: "slots" etc. There can be no excuse for that. Even C coders knew better, even back then.

QObject is not a base class for everything like in those codebases GP probably thinks about. It's a base class for a very specific set of functionality that can be very roughly summarized as "the thing wants to participate in the signal-slot communication scheme". For example, QFile is a QObject because it has ready-to-read signals etc.

But there are also tons of classes in Qt that are not QObject, esp. all the value classes like QList or QPoint or QString.

If anything, the biggest sin of QObject might be its name. If it had been named QActor or something like that, people wouldn't mind that much.

Welcome to modern c++, where everything is a header file and compile times don't matter.

It's templates all the way down, until you meet specializations.

They are expertly-written, but I don’t think these header-only libraries are reflective of most C++ projects. There’s too many tricks and templates that make it hard to read and get a big picture of how it works.

The JSON library is impressive:

https://github.com/nlohmann/json#examples

I agree with your list. However, I don't find the first library you referenced readable (i.e. https://github.com/hanickadot/compile-time-regular-expressio...), and I am a C++ user since the nineties.

What seems to be the problem with CTRE?

That they are regular expressions.

Expressing an algorithm at compile time is so very different from runtime when you do it in template metaprogramming. There is so much visual noise (for my personal feeling at least), writing such code is easier than reading and understanding. Nothing wrong with that special case of regular expressions here, more a general observation.

constexpr seems to try and step in, but there still is a large codebase around which is hard to maintain and extend. IMHO D and zig show that it can be better to have compile- and runtime-syntax much closer together.

Reply on news.ycombinator.com