3 ms·

How does that deal with stack-allocated data that gets twiddled by some other code expecting that it will be able to do so, where that expectation outlives the

How does that deal with stack-allocated data that gets twiddled by some other code expecting that it will be able to do so, where that expectation outlives the actual stackframe itself?

FpUser 5y ago
Same way as GC enabled tools. At some level they all rely on massive libraries written in C.
- pjmlp 5y ago
  Depends on the OS and if the compiler toolchain is bootstraped or not. Apparently many forget C was on that role as well.
  - FpUser 5y ago
    I am a practical man and will let others fight these holy wars. I take action when the real situation changes. I'll give you this example: on desktop I've always used Delphi and lately Lazarus to develop GUI apps. Basically instead of wasting my resources on endless stream of "how to develop GUI properly" coming from MS and changing every other year ( forgive exaggeration ) all my efforts on that front were to improve the actual products. Zero problems so far. Same on the backend. I do not have complaints from my enterprise clients about my backend servers misbehaving in any ways. If that happen I'll take action. Without it I have better idea about where my business expenses are going. This does not mean that I do not use GC based tools at all. There were few cases when client specifically requested particular toolset. Since they're paying for it I do not mind. When given free reign and this is what happens 90% I do what I believe is right.
    - comma_at 5y ago
      So... what is right? What is your preferred toolset?
      - FpUser 5y ago
        I think I already answered. Delphi/Lazarus for GUI apps, C++ for backends, JS for browser, Python for maintenance tasks in rare cases when shell scripts become too complex.
- pwdisswordfish8 5y ago
  This reply makes no sense; GCs don't have to worry about a stale stackframe causing stack-allocated data to go haywire, because they're not using stack allocation to begin with. > At some level they all rely on massive libraries written in C What? How does your "C++ product [that] does not use a single explicit allocation" actually manage memory?

How does that deal with stack-allocated data that gets twiddled by some other code expecting that it will be able to do so, where that expectation outlives the actual stackframe itself?

FpUser 5y ago

Same way as GC enabled tools. At some level they all rely on massive libraries written in C.

pjmlp 5y ago
Depends on the OS and if the compiler toolchain is bootstraped or not. Apparently many forget C was on that role as well.
- FpUser 5y ago
  I am a practical man and will let others fight these holy wars. I take action when the real situation changes. I'll give you this example: on desktop I've always used Delphi and lately Lazarus to develop GUI apps. Basically instead of wasting my resources on endless stream of "how to develop GUI properly" coming from MS and changing every other year ( forgive exaggeration ) all my efforts on that front were to improve the actual products. Zero problems so far. Same on the backend. I do not have complaints from my enterprise clients about my backend servers misbehaving in any ways. If that happen I'll take action. Without it I have better idea about where my business expenses are going. This does not mean that I do not use GC based tools at all. There were few cases when client specifically requested particular toolset. Since they're paying for it I do not mind. When given free reign and this is what happens 90% I do what I believe is right.
  - comma_at 5y ago
    So... what is right? What is your preferred toolset?
    - FpUser 5y ago
      I think I already answered. Delphi/Lazarus for GUI apps, C++ for backends, JS for browser, Python for maintenance tasks in rare cases when shell scripts become too complex.
pwdisswordfish8 5y ago
This reply makes no sense; GCs don't have to worry about a stale stackframe causing stack-allocated data to go haywire, because they're not using stack allocation to begin with. > At some level they all rely on massive libraries written in C What? How does your "C++ product [that] does not use a single explicit allocation" actually manage memory?