Sure, but it’s not enough.

You can forget the virtual destructor. Maybe the language is excused because it’s only a leak.

You could mess up the what() functions. (It’s not locally obvious that it’s correct in this code.) std::exception is fundamentally dangerous. Rust can get away with safely returning references like that because the lifetime is part of the function’s signature. C++, even modern C++, can’t.

Even the iterative example is only a bit safe. You can’t walk off the end by going one too far, but you can certainly mess up by invalidating the iterator in the loop body.

> You can't accidentally walk past the end of the array by going one item too far.

AFAIK, that's with a caveat of "unless you modified the array length within the loop" (looking at the gist, "ast" is a deque, so you can pop items from either end); IIRC, that C++ construct evaluates the begin and end only once at the start, instead of every iteration (unlike what you might do with "classic" C++ evaluating "it != ast.end()" every time), so it wouldn't notice the change. This is particularly annoying since C++ developers can be tempted to optimize a classic "for (auto it = ast.begin(); it != ast.end(); ++it)" loop into either the new-style "for (auto it : ast)" or the old-style optimized "auto end = ast.end(); for (auto it = ast.begin(); it != end; ++it)" loop, even though that would break the code if "ast.end()" ever changes within the loop.

(Since the initial discussion is actually about C and C++ versus Rust: in Rust, you wouldn't be able to modify the array within the loop, since the iterator is borrowing it, so this issue would be caught by the compiler.)

Thanks for the example!

Checks linked resources

      while(!ss.eof()){
        ss >> token;

Can cause an endless loop (with finite input stream; for example in case of a read error).

    p >> x;
    if(!p.fail() && p.eof()){

This way of error checking is correct for C++ but not nice (it or part of it can be forgotten with no warning--see below for an instance of it :P).

    struct stack_empty_error: public std::exception{
      const char\* what() const throw(){

Missing "override" annotation here. Can easily fuck it up since overloads are allowed.

        return " ==> Error: stack empty." ;
      }
    };



    auto x = _stack.back();
    _stack.pop_back();
    return x;

Correct in C++ but incredibly weird--typical for lowlevel languages that are far away from the user.

Also, when I press Ctrl-D, I get an endless loop printing "EXPR+> stack". Typical C++ program...

Why some functions are declared like:

    void foo()  { .. }

And others

    auto foo() -> void { .. }

Fashion.

The second syntax was introduced for lambdas and decltype() usage for return types that depend on the parameters (due to look up rules), and some C++ subcultures now use it everywhere.

>...And others

> auto main() -> int {

Absolutely no reason to masquerade main() in such a fashion!

It's a rule of least surprise, be it for user or fellow developer.

>...Here's an example of C++ code written intentionally with all the latest C++ features.

Does it really need to include <string.h>?

That's quite readable and actually makes me wanna try C++20 or whatever it is.

the gist is mostly c++11, all I can say is that c++20 is much better.

with constexpr etc, and std::move, and unique_ptr in use, many memory safety issues can be contained.

adding cppfront on top can make modern c++ even more memory safe.

Why are spaces randomly omitted for language constructs like if and for, and reference type &s left aligned?!

What's wrong with left aligned & and *? I prefer it because for me it makes more sense; it is not a <type>, it is a <type> reference (or pointer). This involves different semantics than just a <type>, so it makes sense to me for the extra information to be with the type.

Randomly? This author does it consistently. Some people prefer with spaces, some prefer without, most people follow the coding standards for the company / project they're working on.

In other words, you are not aware of anything wrong with this code.