4 ms·

So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I do

• pjmlp 7y ago
  Sensible use of language features, and definitely no use of inherited C unsafety features like manual resource management, unchecked arrays accesses, implicit enum conversations, lack of namespacing, nullable pointers instead of references,...
  • jstimpfle 7y ago
    > [no use of] unchecked arrays accesses that requires to include i.e. vector everywhere, which drives up compile times and adds dependencies. Maybe slightly better: some slice type. But it's still a lot of boilerplate, and doesn't play nice with parallel arrays. > [no use of] implicit enum conversations > [no use of] nullable pointers How do you deal with "missing or N/A values"? Because, as every database guy will assert you, these things exist, and they are very common. How do you deal with the situations where only a subset of the enum values is applicable anyway? Because these situations are extremely common as well, and once again, types can't help here without A LOT of additional boilerplate. > lack of namespacing It's a feature, not a bug, to know that every thing is referenced by exactly one name. Makes reading code so much easier.
    • pjmlp 7y ago
      Binary dependencies that are already compiled, external template instantiation exists since C++11. I deal with nullable types when needed, not for 100% of pointers, like C requires to. A feature that requires linker support to work around third party libraries clashes, C engineering at its best.