Hacker News Reader

Comment by fizzynut | Hacker News Reader

Like I said, use constexpr.

  constexpr int a = 4;
  auto& b = a;
   
  a+= 1; // compile error
  b+= 1; // compile error

Trying to make b constexpr with "a" as an int is also a compile error.

View on HN

That would unnecessarily constraint `a` to be known at compile time though? I imagine that would be incredibly limiting.

E.g., if you're implementing an iterator that takes a reference to the length of the container being iterated, and you require that that reference is constexpr, that means the container will have a fixed, compile-time-known, size.

Since you didn't reply to the other parts of the comment, I'll presume that C++ doesn't have the mutex I'm talking about (apart from this attempt[0], which I just learnt about and commented on in a different reply), and that it's not possible to have non-ref-counted shared references while statically avoiding dangling pointers.

[0] https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

A lot of constants are known at compile time and constexpr solves a lot of problems. However, you do not need constexpr to solve your example- this is still a compile error:

void iter(std::vector<int>& vec) {

     auto& vec_size = vec.size();

     vec_size += 10; //compile error

}

There are many ways of forcing compile errors for mutexes that people have built, but they all come with their own trade-offs.

I've not encountered a problem where I specifically needed "non-ref-counted shared references while statically avoiding dangling pointers", so I'm not an expert on it.

What I'm referring to with regards containers is: preventing containers being modified while they are being iterated on (which is usually bad, because you will probably invalidate the iterator when modifying the container). That is what is prevented by Rust's references rules, and to my knowledge, isn't possible to protect against in C++ (statically).

Thanks for the replies about the other stuff!

Reply on news.ycombinator.com