std::string has some useful features, but be careful.
Using plain old ints as identifiers for classes/structs is tried and true, but
we can do better.
Most of the big proposals for C++20 have been talked over quite a bit. But there are a few “hidden” ones that caught my eye.
The Sieve of Eratosthenes is a well known algorithm for computing primes, but suffers from space requirements. The Incremental Sieve solves that problem.
Spirit tries hard to make dealing with attributes easy, but sometimes, it just gets in the way.
For larger Spirit-based project, organizing the source code well can lead to more efficient builds and increased maintainability.
Of course, this is true for any project. But the heavily templated nature of even a fully realized Spirit parser makes this doubly so. Figuring out how to take advantage of separate compilation while maintaining the ability for each of the pieces to see the needed type/template information is not trivial.
Once your parser grammar grows beyond a few rules/parsers, handling errors will become a priority. Being able to give feedback about where things went wrong, what exactly went wrong, and possible fixes are all things you would like to provide. It might also be nice to see if you could recover the parsing process from the point of failure and continue parsing to maybe find other problems.
I’ve been looking at the Rust Ownership model . The skinny is that Rust has made mostly opposite decisions from C++. Copy vs Move An assignment in Rust is by default, a move. The original variable is declared as invalid and using it will net you a hard error at compile time. The example used in the docs is: let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); That last line will not compile because s1 is no longer valid.
I have decided to design, and build my own computer language. It will be called Onyx. I agree, that is a pretty big task. So we will take a bit at time. Design Criteria I don’t really have a whole lot yet. You might think of onyx as C++ EXCEPT - meaning, it acts like C++ EXCEPT these differences. Over time the list will grow and I’ll turn it into a full-feature language spec.
Last time, we looked at the lexer and supporting staff. This time, we will look at the primitive parser and final usage.