3 ms·

That secondary stack is cool! I want it for my C++ programs, particularly std::string which always heap alloc. begin return "Forty Two"; end Get_Answer;

touisteur 3y ago
Yes the secondary stack is this thing that make many (most?) heap allocations inexistant in Ada. So when you're talking about memory safety to an Ada dev as if it was the biggest pain, they might look strangely at you. Yes indeed, heap allocated pointers are a PITA but we don't use so many of them. In 16 years as an kinda embedded dev on multiple MLOC codebases, I can count on my fingers the times I had to reach to pointers (and unchecked_deallocation) and didn't have a safer alternative (usually Controlled scoped pointer types, but also containers, indefinite types, and if really stuck reference-counted things if really you must murky the scope - but I'd flag the last one as 'need to show why you can't just copy the data around' at code review...). Not saying it's not missing but I wish we spent more energy on automated proof of absence of runtime errors, large-scale whole-system static analysis, and even more stringent runtime or compilation checks. And better tooling/language support around network, threading, and distributed processing, improved test and coverage tools.
touisteur 3y ago
You're returning a string which size might be known at compile time through inter procedural analysis. Too easy. The secondary stack would better be used for 'functions returning objects, of which you don't know the size, at call time'. function Any_Number (A : Natural) return String is begin if A = 42 return "A = Quarante Deux"; end if; return "A =" & A'Image; end Any_Number; Or for those allergic to begin/end function Any_Number (A : Natural) return String is (if A = 42 then "A = Quarante Deux" else "A =" & A'Image);

touisteur 3y ago

Yes the secondary stack is this thing that make many (most?) heap allocations inexistant in Ada. So when you're talking about memory safety to an Ada dev as if it was the biggest pain, they might look strangely at you. Yes indeed, heap allocated pointers are a PITA but we don't use so many of them. In 16 years as an kinda embedded dev on multiple MLOC codebases, I can count on my fingers the times I had to reach to pointers (and unchecked_deallocation) and didn't have a safer alternative (usually Controlled scoped pointer types, but also containers, indefinite types, and if really stuck reference-counted things if really you must murky the scope - but I'd flag the last one as 'need to show why you can't just copy the data around' at code review...). Not saying it's not missing but I wish we spent more energy on automated proof of absence of runtime errors, large-scale whole-system static analysis, and even more stringent runtime or compilation checks. And better tooling/language support around network, threading, and distributed processing, improved test and coverage tools.

touisteur 3y ago

You're returning a string which size might be known at compile time through inter procedural analysis. Too easy. The secondary stack would better be used for 'functions returning objects, of which you don't know the size, at call time'. function Any_Number (A : Natural) return String is begin if A = 42 return "A = Quarante Deux"; end if; return "A =" & A'Image; end Any_Number; Or for those allergic to begin/end function Any_Number (A : Natural) return String is (if A = 42 then "A = Quarante Deux" else "A =" & A'Image);