3 ms·

Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If

Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If you don't, headers will just include other headers will include other headers... And you end up waiting for minutes for the rebuild whenever you make one tiny change in one of these headers... But still, moving code from headers to implementation files helps reduce build times. (Very innovative!) Where I work, the stuff I do in C compiles in less than a tenth of the time. And that's compared to MFC-era C++ (C with classes, not C++11).

pjmlp 7y ago
I don't touch C unless obliged to do so.
- jstimpfle 7y ago
  So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.
  - 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.

pjmlp 7y ago

I don't touch C unless obliged to do so.

jstimpfle 7y ago
So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.
- 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.