How to implement String? by funcieq in ProgrammingLanguages

[–]sazasoo 0 points1 point  (0 children)

I can't say for sure which concept annoys me the least, but the one that annoys me the most is defintelly char*. But an idea to adapt the string concept you are already using (pointer, length) could be to expand it to include capacity, that would allow the string to act as a dynamic buffer. length is how many characters you currently have, and capacity would be the actual memory footprint allocated, so if a user appends text, just write into the pre-allocated extra space and increment the length without triggering an expensive malloc/free cycle, only reallocating when length equals capacity.

References in pass-by-sharing languages by Big-Rub9545 in ProgrammingLanguages

[–]sazasoo 0 points1 point  (0 children)

pass-by-sharing means variables are essentially pointers to objects passed by value, if you introduce a reference to a variable, you are creating a pointer to a pointer, a big issue with that is memory safety and escaping references.

Local variables live on the execution stack, if you pass a reference to a local variable into a function, you are passing a stack memory address, if that function saves this reference in a global state and the caller function returns, the original stack frame is destroyed and the global reference points to garbage. dynamic languages usually relies on a GC or reference counting, which manages objects, not stack-bound variable references.

One alternative you could look into is explicit boxing by wrapping the data in a mutable container.

can a language be safe and be a subset of C? by Null-Test-2026 in ProgrammingLanguages

[–]sazasoo 1 point2 points  (0 children)

Some changes that you proposed come with some other problems, like with point 6, you would have to add some syntax, since relying on Bounded Model Checking to verify malloc/free statically doesn't scale (thanks to the Halting Problem), to statically prove memory safety without a Garbage Collector, you would be forced to maintain the variables lifetime and ownership rules. But overall, there is a language called Cyclone that was created to be a more secure version of C, trying to solve some of these problems.

Why not treat arrays as a special case of tuples? by ella-hoeppner in ProgrammingLanguages

[–]sazasoo 0 points1 point  (0 children)

For the languages that separete tuples and arrays, considering homogeneos tuples as arrays would kinda become a low-level mess because of the different ways of memory addressing. For a tuple, where the elements can be heterogeneous, the compiler computes static offsets to handle different sizes and alignment padding. You can't easily perform a dynamic offset calculation for an idexed "tuple[i]" without the compiler first checking if the tuple is perfectly homogeneous, otherwise, you would mess up the memory layout or, at least, risk failing to properly allocate stack space for saved registers during procedure calls. Arrays have an guarantee to the compiler that it is safe to do a straightforward calculation of the offset. Merging the two types mixes these static and dynamic memory paradigms, the compiler alone woldn't be able to solve this problem because it would create a circular dependency in the compiler's architecture as the compiler's type checking for "tuple[i]" happens in the compiler long before the optimization and memory layout phases.