Will it be possible to handle memory explicitly with Kotlin Native?

enighma: I hope not.

@mg6maciej why is that?

Manual memory handling is known to be a cause of many bugs. Machines can do that better than us with ARC or GC.

That is correct, however in some performance sensitive scenarios you want to align and control your own memory. So having the ability, like you have in C# would be a win I think.

That sounds like arguing against smart pointers.. Why? What specifically can you not do

Sometimes I really want to

delete

an object before GC 🙂

@sreich There are many reasons why you’d wanna control memory explicitly. Cleaning up memory is a costly process and in a performance intensive application you want to control when it happens. Furthermore, I would also want to control how the memory is laid out so that I can maximize CPU cache hits.

Those things are not mutually exclusive though. Smart pointers for instance only guard your pointers, you can decide when and how to allocate and free just fine. If you're writing for example, c++ without smart pointers..You're writing it wrong

How would you do that in with java? Sure you can hold on to references but you have no control over when the actual GC happens. Not sure why we’re even talking about smart pointers. Because their existence does not change my initial question.

Cache coherency is possible in Java, using arrays. That's how it's done in c++ even. You can't ensure linear access unless you've a custom allocator, which is basically doing the same thing you'd do in Java for those sorts of things. But as I said, it's not as powerful. And you can't determine things like alignment and exact sizes aligning to cache lines

@sreich It’s kind of hard to reply when you post a plethora of responses, so maybe calm down? I think you have to understand that software development is not as black/white as you paints it to be. You might not understand why I asked the question and from my point of view it doesn’t look like you are interested in that either. You simply want to push your agenda of development, which is fine, but nothing I’m interested in discussing.

I am calm, just most people (mobile) reply often vs long. I don't have any agenda, I'm not sure what makes you think that. I've no stake in it one way or another. But you also didn't mention any tangible or quantifiable specifics. You kinda just hand waved it as "performance", I was asking for specifics, not to say you're wrong (because I could just as easily be) but because I'm genuinely interested to know

I think there is one case that you want full control over addresses: when you access external device and need to set these and these bits. I didn't do that since studies and it was assembler...

So like I said, I'm interested if there's something specific about modern approaches to more safe memory management, that makes them unsuitable (smart pointers). Smart pointers actually don't incur any non negligible overhead and they've been recommended by c++ best practices for a few years now (got better with c++11). But really I'd just like to know what specifics are wrong with ARC

Ok. That invalidates what I said 🙂

Smart pointers are a way of gaining some type safety (it's c++ though so it isn't pretty like kotlin null safety), basically you create them and you can either describe it as "you own it(and will auto free when the last ref gets unused" or "someone else owns it". I've used them before with I.e. opengl, which is a C API and there are methods which give you a pointer to a buffer in the driver