Forum > General
Is the modern memory management really so bad in Pascal?
Benjiro:
https://www.reddit.com/r/programming/comments/6no60t/pascal_programming_in_21st_century_visual_studio/
--- Quote ---is the modern memory management really so bad in Pascal?
http://castle-engine.io/modern_pascal_introduction.html#_manual_and_automatic_freeing
is like 1990's again -- even simple things like owned pointers (unique_ptr) and refcounted pointers (shared_ptr) are missing. The replacements (manual free's and free notifications) have A LOT of manual boilerplate. Also, everything is horribly thread-unsafe.
Is there a better example of memory management in a modern pascal?
--- End quote ---
Somebody asked a interesting question on a Reddit thread and frankly, i am not qualified to answer that person. Anybody with more experience able to answer that?
skalogryz:
--- Quote from: Benjiro on July 17, 2017, 08:51:02 pm ---
--- Quote ---is the modern memory management really so bad in Pascal?
http://castle-engine.io/modern_pascal_introduction.html#_manual_and_automatic_freeing
is like 1990's again -- even simple things like owned pointers (unique_ptr) and refcounted pointers (shared_ptr) are missing.
--- End quote ---
--- End quote ---
Definitely a lot of emotions is given in this reddit post.
Refcounted entities such as strings and/or dynamic arrays are not mentioned.
...btw, the article itself calls ref-counted COM-interfaces "ugly" ones. (see section 9.4)
Overall, sounds like an invitation to another flame-war.
Could we argue with better products instead of words?!
Thaddy:
Well, in FPC memory-managers are pluggable So half of which what is there refers to a complete and utter misunderstanding of the subject.
Slight incomplete summary:
- FPC's default MM favors size over speed. It focusses on memory use. (buckets and slot re-use) Fragments very little with lots of small allocations and de/re-allocations
- FPC has also cmem, which trades size for speed, it focusses in a minimalistic way on fast allocation/re-allocation. Very basic, but can speed things up in some scenario's. Fragments very quickly.
- And even a Boehm garbage collecting MM. Well, obviously... not for everybody
- Or anything you want, like my commm unit (super slow, but comes in handy with COM in general).
- and of course FPC Includes a heapmm that allows for easy leak detection.
Basically we can plug in anything we want. There's no such thing as "the" memorymanager.
AlexK:
--- Quote from: Benjiro on July 17, 2017, 08:51:02 pm ---
--- Quote ---is the modern memory management really so bad in Pascal?
is like 1990's again -- even simple things like owned pointers (unique_ptr) and refcounted pointers (shared_ptr) are missing. The replacements (manual free's and free notifications) have A LOT of manual boilerplate. Also, everything is horribly thread-unsafe.
Is there a better example of memory management in a modern pascal?
--- End quote ---
Somebody asked a interesting question on a Reddit thread and frankly, i am not qualified to answer that person. Anybody with more experience able to answer that?
--- End quote ---
C++ uses textual #include files from 1970-s.
C++ compiler knows only about one file it compiles. All the info about project structure must reside in a build system(CMake, Automake, Scons, Waf, etc).
"Modern memory management"...
C++ is parsable only by its compiler. Static analysis of C++ is extremely difficult. Clang tools fixed some inconveniences of a development process with C++.
What is static analysis? It's like another compiler that doesn't generate code, but analyses it by some criteria.
It can replace automatic memory management. It can convey automatic code quality audit, find deprecated features, propose optimizations. Anything imaginable that humans do with existing code.
One of the main advantages/features of Object Pascal is that it's suitable for static analysis.
Rust language for example, made memory management static analysis a standard part of its compiler.
In the end of 1980s Lispers created one official standard out of many separated implementations, that is ideal to this days - Common Lisp.
Object Pascal nowadays is only at a "Free" stage, not Common. Slow development and small user community that isn't really interested or motivated in fixing some grey areas of the language(function pointers).
SymbolicFrank:
The most important reason for C++ to have shared_ptr and unique_ptr is, that there is no try..finally. So, in many cases, it is really hard (or even impossible) to clean up resources in all cases.
Another partial fix in C++11 is that you can have functions and methods specify what exceptions they could throw, but that mechanism is broken as well.
So, they have it the wrong way around: the MM of C++ always has been broken, and shared_ptr and unique_ptr are only fancy and futuristic improvements for people who still live in the ancient C++ past.
On another note: the Threading model as designed by Microsoft is also quite broken, shared_ptr and unique_ptr aren't going to fix that either. For threads, sharing is always bad. Don't do it.
Navigation
[0] Message Index
[#] Next page