High level memory programming paradigm

General discussion for topics related to the FreeBASIC project or its community.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: High level memory programming paradigm

Post by caseih »

You might be splitting hairs. RAII is both a tool and a programming paradigm that enables memory safe programming without GC. Programmers can still leak memory if they want/improperly code destructors. "Resources" include much more than just memory, which is where the real power comes. Could be file handles that close properly, etc. But it is the primary tool by which C++ programmers manage memory and it works very well at that. And when you say RAII for managing memory only works for trivial cases, you're just plain wrong. Also RAII's allows deterministic management of memory, which is really critical for some things like embedded programming.

In recent versions of Java, the language has adopted some syntax that enables something similar to RAII, at least in regards to the "resource acquisition" and guaranteed destruction aspect of it. It's called "try with resource." It doesn't actually release memory necessarily (the GC does that still), but it does guarantee that resources acquired get properly destroyed, which is something Java has always lacked in the past. It's very similar to Python's context manager protocol.

Getting back on topic, currently FB's object model does implement much of the RAII paradigm. Thus I do not see what a GC would add to FB, nor how it would actually integrate with FB. FB does lack important things like smart pointers, which form an important part of the RAII programming model, but C++ didn't have those either for decades.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: High level memory programming paradigm

Post by marcov »

caseih wrote:You might be splitting hairs.
RAII predates smart pointers (which were original a STL construct). So yes, if you make hairs big, expect some splitting :-)

That alone makes your whole definition of RAII revisionist, at best.
RAII is both a tool and a programming paradigm that enables memory safe programming without GC.
So RAII= NOT GC brrr. That is horribly broad, and IMHO incorrect.

RAII initializes static structs/classes (that for some reason warrant that treatment, e.g. by defining the default construct/destructor)

Code: Select all

void  bla()
{ someobject a;  // a is initialized by prologue code here. And only for objects.

 // do operations on a, but these operations are not allowed to add pointers to global state.

// epilogue calls destructor automatically here, and "a" is no more.
}
The lifetime of a is roughly equal to the bla() scope. You can pass it to functions in the body section, but they can't add it to e.g. collections. The classic example (and purpose/advantage) of RAII is that someobject can be some dynamically allocated vector or even tree, and that will work fine in such cases without much manual intervention.

As soon as you start adding using new() and add to global datastructures, that goes out of the window. You can of course cheat and have a few global data structures that you manually free just before the end of the program, but that won't help.

For that you need newer principles like GC or ref counting(eitehr implemented by template like the original smart pointers, or in language like the later standard or e.g. Delphi/FPC for certain types)
But it is the primary tool by which C++ programmers manage memory and it works very well at that. And when you say RAII for managing memory only works for trivial cases, you're just plain wrong. Also RAII's allows deterministic management of memory, which is really critical for some things like embedded programming.
And batch, note that I said batch, and the function bla() above is exactly such example. Now add a pointer to a to some global collections that is not aware of smart pointers, and exit bla(), and then try to access a, what happens? Or New it, and then add the object to the collection
In recent versions of Java, the language has adopted some syntax that enables something similar to RAII, at least in regards to the "resource acquisition" and guaranteed destruction aspect of it. It's called "try with resource." It doesn't actually release memory necessarily (the GC does that still), but it does guarantee that resources acquired get properly destroyed, which is something Java has always lacked in the past. It's very similar to Python's context manager protocol.
Read the URL. The construct is to avoid eating up exceptions in the old equivalent try.finally construct, which already took care of memory or resources. (and of course shorthands always instinctively get the thumbs up). Try finally is as old as the road to Rome, and also predates e.g. smart pointers.

Getting back on topic, currently FB's object model does implement much of the RAII paradigm. Thus I do not see what a GC would add to FB, nor how it would actually integrate with FB. FB does lack important things like smart pointers, which form an important part of the RAII programming model, but C++ didn't have those either for decades.
Yes, but that due to manual memory management, the programmer keeping track of references and ownership and freeing everything with hard work. Not RAII automated memory management. Delphi/FPC do the same without RAII nor GC and barely smart pointers.

All have their place and their downsides. GC eats memory, scales badly with threads (few GCs are wholly multi threaded and under global locks). Smart pointers add overhead and can't deal with cycles and other mutual reference cases(*), and manual resource management is tedious and errorprone (though a bit of administration and conventions really help there). Moreover GC is not uniform and there are multiple kinds.

In this whole list of technologies RAII is more or less one of those manual memory management mitigation strategy for a policy of such conventions integrated into a language. But before async programming really took off.
Lost Zergling
Posts: 534
Joined: Dec 02, 2011 22:51
Location: France

Re: High level memory programming paradigm

Post by Lost Zergling »

Obviously, from my point of view, raii is closer to a competitor than to a solution, but this does not prevent indeed the concepts from converging or intersecting.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: High level memory programming paradigm

Post by caseih »

We're clearly speaking past each other. Yes I'm very well aware of the details of how RAII works and its history having dabbled in c++ for many years as one of my primary languages, and also what recent things have been added to the language and paradigm. Also I stated very clearly that C++ did not have smart pointers for decades and people got along fine, although they are a tremendous addition that I've grown to love recently. I used RAII precepts in my C++ programming years ago before smart pointers to manage memory and other resources very successfully.

Yes I know what try with resources is and how it is similar and different from RAII. I also clearly stated that Java's try with resources concept is not about memory management, but rather resource management. For example if you open are writing a file and an exception occurs, you want to make sure the file is closed properly or some other clean up is performed, which was hard to do reliably and safely before this construct was introduced. In my opinion Java did not borrow this from C++ as much as they borrowed it from Python. In any language with exceptions, doing proper cleanup after an exception occurs has always been fragile without this sort of facility. C++ of course never had that issue.

I don't like to assume anything, but it seems like you've not really used C++ for a full project, and in particular not used the RAII features of C++ as a memory management tool. As to your scope issues, yes I can see what you're talking about and you're not wrong. However in practice, the issues don't actually occur in most real C++ programs because of a concept called copy constructors which FreeBASIC also has. C++ programmers sidestep the out-of-scope destruction issue entirely by passing and returning objects by value at will, copying them when necessary. Thus an object is deleted and freed when it goes out of scope, but the copy lives on to be returned from a function, or passed to another function. When I first saw this, I thought that would be horribly slow and inefficient. But in the real world it works very well and is quite fast. So fast, in fact, that you rarely notice any performance issues. Of course sometimes it is still necessary to share an actual reference, such as when two different objects need to access a third object, and modern C++'s smart pointers facilitate that within the RAII paradigm, which always was a hole in the paradigm before. All while maintaining determinism allowing a person to reason about the system.
Last edited by caseih on Jul 09, 2021 19:10, edited 1 time in total.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: High level memory programming paradigm

Post by caseih »

Lost Zergling wrote:Obviously, from my point of view, raii is closer to a competitor than to a solution, but this does not prevent indeed the concepts from converging or intersecting.
If you're referring to FreeBASIC, no, RAII is not a competitor. It is a solution, and one that's already implemented in FB. You just need to use it. FB also has copy constructors too, which I did neglect to speak to before @marcov's last comment. They are a critical part of it. I guess it's so common in doing OOP in C++ I forgot to mention it and wondered why marcov kept bringing up the scope issues. My apologies for missing it.

My C++ experience barely touches on anything past C++11. I read today that C++11 offers move constructors which might mean copy constructors are unnecessary, especially when working with template classes. Should offer some performance improvements. Although it makes C++ even more complex difficult to learn.

Anyway, I'm done. RAII is a valid technique for managing memory that makes GC unnecessary for many things. And FreeBASIC already supports it, so you can play around with it right now. I'm not sure if FB creates automatic copy constructors for your types, but I assume it does, allowing you to pass your type instances around by value without really thinking about allocations and deallocations.
Lost Zergling
Posts: 534
Joined: Dec 02, 2011 22:51
Location: France

Re: High level memory programming paradigm

Post by Lost Zergling »

@caseih : RAII is a solution because some modern languages tend to be 'multi-paradigm' (ie : Rust), RAII is also indeed a competitor, for the same reason !
I will not try to argue with Marcov around automatic GC, I believe GC programming shall be imperative, manual or half automated, instructed directly by programmer.
Just a solution among others.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: High level memory programming paradigm

Post by caseih »

For sure. The nice thing about FB is it is a multi-paradigm language.
Post Reply