3 ms·

> - Pointer to array outliving invalidation of array Another problem that can be largely avoided with a clear architecture. 1. The vast majority of buffers sh

> - Pointer to array outliving invalidation of array Another problem that can be largely avoided with a clear architecture. 1. The vast majority of buffers should be allocated at program startup, stored in a global variable, and freed at the end. 2. In almost all other cases, pointer ownership should just not be moved across functions (mostly "initializer functions" which return allocated memory). I think the idea that a function takes a data pointer without any idea how it was created, and then stores the pointer somewhere in its own structures, comes from garbage-collected languages and OOP culture which has an (I think) irrational aversion to globally architected dataflow. The messy object graphs that are created in this culture are just not manageable without a GC or another mechanically enforced discipline. I'm not a fan of neither C++, nor Rust, nor garbage collected languages, for complex tasks. One can get away with less expertly architected programs in these languages. But, IMHO, they don't support, or do even impede, clear architecture, which ultimately leads to complexity. And this does mean hard to maintain and buggy software - it's just more memory-safe.

klodolph 9y ago
Now the only problem is in communicating and enforcing that architecture, hiring people who understand how important this architecture is or training them, adding these architectural checks to your code review process, having discussions about which cases are exceptions, and figuring out what to do with legacy code.
- jstimpfle 9y ago
  Legacy code is reduced to a fraction with good architecture, though. Well architected programs are a lot shorter and a lot more straightforward. And I don't really think you can make clear rules or exceptions - so no general discussions needed. Just don't admit data flow designs that aren't completely thought through (and really simple). Yes, it takes experienced developers.
  - klodolph 9y ago
    You can point out that the ancient Egyptians built the pyramids just fine, but I'm still going to argue in favor of mechanization. In my experience, good architecture does not materialize often enough to make this a viable strategy except for certain specialized teams. Consider writing code in C when you don't completely understand the problem and haven't devised a solution yet, or when you know it's going to get assigned to a junior developer and you don't have spare time for extra oversight. Or consider that you might ship poorly architected code because it's functional and shipping it will earn you money, or you might inherit large tracts of legacy code that are too expensive to refactor. We all love ourselves some good architecture in our programs, but I'd rather have the penalty for bad architecture be "fails to compile" or "assertion error at runtime" rather than "our product has a security vulnerability". Just because the problem can be solved by throwing better, more experienced developers at it doesn't mean that we should. Let's throw the experienced developers at the more exciting problems and let our tools figure out memory safety for us... at least, most of the time. > Legacy code is reduced to a fraction with good architecture, though. I honestly don't understand this claim at all. I've only worked at one company where I didn't have to work with legacy code. The amount of legacy code I've been personally responsible for has varied from ~20 kloc (fairly manageable) to ~1 Mloc. I don't know what kind of good architecture could reduce that 1 Mloc. I ended up just throwing the address sanitizer at it, working on the test suite, and prioritizing refactors based on expected cost and payoff.
    - jstimpfle 9y ago
      That was meant as "the amount of legacy produced is much smaller".
Ar-Curunir 9y ago
Are you seriously calling global mutable state "expert architecture"? The thousands of C-based security vulnerabilities indicate that many experienced developers haven't figured out a "clear architecture" that prevents such issues.
- jstimpfle 9y ago
  > Are you seriously calling global mutable state "expert architecture"? Yes. Putting global state in a class and instantiating it once is pretty pointless. It's a lot of boilerplate and in the end just hides the intention. To the point that programmers confuse themselves about their own assumptions. Leads only to more bugs. Furthermore, global state (as well as global constant data) enjoys the best support for memory management in existence: the linker / process loader. (well-tested, no maintenance overhead)

klodolph 9y ago

Now the only problem is in communicating and enforcing that architecture, hiring people who understand how important this architecture is or training them, adding these architectural checks to your code review process, having discussions about which cases are exceptions, and figuring out what to do with legacy code.

jstimpfle 9y ago
Legacy code is reduced to a fraction with good architecture, though. Well architected programs are a lot shorter and a lot more straightforward. And I don't really think you can make clear rules or exceptions - so no general discussions needed. Just don't admit data flow designs that aren't completely thought through (and really simple). Yes, it takes experienced developers.
- klodolph 9y ago
  You can point out that the ancient Egyptians built the pyramids just fine, but I'm still going to argue in favor of mechanization. In my experience, good architecture does not materialize often enough to make this a viable strategy except for certain specialized teams. Consider writing code in C when you don't completely understand the problem and haven't devised a solution yet, or when you know it's going to get assigned to a junior developer and you don't have spare time for extra oversight. Or consider that you might ship poorly architected code because it's functional and shipping it will earn you money, or you might inherit large tracts of legacy code that are too expensive to refactor. We all love ourselves some good architecture in our programs, but I'd rather have the penalty for bad architecture be "fails to compile" or "assertion error at runtime" rather than "our product has a security vulnerability". Just because the problem can be solved by throwing better, more experienced developers at it doesn't mean that we should. Let's throw the experienced developers at the more exciting problems and let our tools figure out memory safety for us... at least, most of the time. > Legacy code is reduced to a fraction with good architecture, though. I honestly don't understand this claim at all. I've only worked at one company where I didn't have to work with legacy code. The amount of legacy code I've been personally responsible for has varied from ~20 kloc (fairly manageable) to ~1 Mloc. I don't know what kind of good architecture could reduce that 1 Mloc. I ended up just throwing the address sanitizer at it, working on the test suite, and prioritizing refactors based on expected cost and payoff.
  - jstimpfle 9y ago
    That was meant as "the amount of legacy produced is much smaller".

Ar-Curunir 9y ago

Are you seriously calling global mutable state "expert architecture"? The thousands of C-based security vulnerabilities indicate that many experienced developers haven't figured out a "clear architecture" that prevents such issues.

jstimpfle 9y ago
> Are you seriously calling global mutable state "expert architecture"? Yes. Putting global state in a class and instantiating it once is pretty pointless. It's a lot of boilerplate and in the end just hides the intention. To the point that programmers confuse themselves about their own assumptions. Leads only to more bugs. Furthermore, global state (as well as global constant data) enjoys the best support for memory management in existence: the linker / process loader. (well-tested, no maintenance overhead)