To-do: Unclassified proto-rules

This is our to-do list. Eventually, the entries will become rules or parts of rules. Alternatively, we will decide that no change is needed and delete the entry.

• No long-distance friendship
• Should physical design (what's in a file) and large-scale design (libraries, groups of libraries) be addressed?
• Namespaces
• Avoid using directives in the global scope (except for std, and other "fundamental" namespaces (e.g. experimental))
• How granular should namespaces be? All classes/functions designed to work together and released together (as defined in Sutter/Alexandrescu) or something narrower or wider?
• Should there be inline namespaces (à la std::literals::*_literals)?
• Avoid implicit conversions
• Const member functions should be thread safe ... aka, but I don't really change the variable, just assign it a value the first time it's called ... argh
• Always initialize variables, use initialization lists for member variables.
• Anyone writing a public interface which takes or returns void* should have their toes set on fire. That one has been a personal favorite of mine for a number of years. :)
• Use const-ness wherever possible: member functions, variables and (yippee) const_iterators
• Use auto
• (size) vs. {initializers} vs. {Extent{size}}
• Don't overabstract
• Never pass a pointer down the call stack
• falling through a function bottom
• Should there be guidelines to choose between polymorphisms? YES. classic (virtual functions, reference semantics) vs. Sean Parent style (value semantics, type-erased, kind of like std::function) vs. CRTP/static? YES Perhaps even vs. tag dispatch?
• should virtual calls be banned from ctors/dtors in your guidelines? YES. A lot of people ban them, even though I think it's a big strength of C++ that they are ??? -preserving (D disappointed me so much when it went the Java way). WHAT WOULD BE A GOOD EXAMPLE?
• Speaking of lambdas, what would weigh in on the decision between lambdas and (local?) classes in algorithm calls and other callback scenarios?
• And speaking of std::bind, Stephen T. Lavavej criticizes it so much I'm starting to wonder if it is indeed going to fade away in future. Should lambdas be recommended instead?
• What to do with leaks out of temporaries? : p = (s1 + s2).c_str();

• pointer/iterator invalidation leading to dangling pointers:

  void bad()
  {
      int* p = new int[700];
      int* q = &p[7];
      delete p;
  
      vector<int> v(700);
      int* q2 = &v[7];
      v.resize(900);
  
      // ... use q and q2 ...
  }
  

• LSP

• private inheritance vs/and membership

• avoid static class members variables (race conditions, almost-global variables)

• Use RAII lock guards (lock_guard, unique_lock, shared_lock), never call mutex.lock and mutex.unlock directly (RAII)

• Prefer non-recursive locks (often used to work around bad reasoning, overhead)
• Join your threads! (because of std::terminate in destructor if not joined or detached ... is there a good reason to detach threads?) -- ??? could support library provide a RAII wrapper for std::thread?
• If two or more mutexes must be acquired at the same time, use std::lock (or another deadlock avoidance algorithm?)
• When using a condition_variable, always protect the condition by a mutex (atomic bool whose value is set outside of the mutex is wrong!), and use the same mutex for the condition variable itself.
• Never use atomic_compare_exchange_strong with std::atomic<user-defined-struct> (differences in padding matter, while compare_exchange_weak in a loop converges to stable padding)
• individual shared_future objects are not thread-safe: two threads cannot wait on the same shared_future object (they can wait on copies of a shared_future that refer to the same shared state)

• individual shared_ptr objects are not thread-safe: different threads can call non-const member functions on different shared_ptrs that refer to the same shared object, but one thread cannot call a non-const member function of a shared_ptr object while another thread accesses that same shared_ptr object (if you need that, consider atomic_shared_ptr instead)

• rules for arithmetic