Recent

Author Topic: Is the modern memory management really so bad in Pascal?  (Read 8515 times)

Benjiro

  • Guest
Is the modern memory management really so bad in Pascal?
« on: July 17, 2017, 08:51:02 pm »
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?

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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Is the modern memory management really so bad in Pascal?
« Reply #1 on: July 17, 2017, 08:59:29 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.
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?!
« Last Edit: July 17, 2017, 10:14:04 pm by skalogryz »

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Is the modern memory management really so bad in Pascal?
« Reply #2 on: July 17, 2017, 09:15:35 pm »
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.
« Last Edit: July 17, 2017, 09:29:56 pm by Thaddy »
Specialize a type, not a var.

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: Is the modern memory management really so bad in Pascal?
« Reply #3 on: August 03, 2017, 06:28:29 am »

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?

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?

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).
« Last Edit: August 03, 2017, 06:31:53 am by AlexK »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Is the modern memory management really so bad in Pascal?
« Reply #4 on: August 03, 2017, 08:57:05 am »
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.


marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Is the modern memory management really so bad in Pascal?
« Reply #5 on: August 03, 2017, 11:20:48 am »

FPC/Delphi has quite a lot of refcounted types already, and he doesn't even mention it. True, we don't have refcounted pointer, but we use pointer much less.

Yeah, somebody who has an axe to grind, and isn't really interested in pascal or the answer, he is just looking to vent some halfbaked opinion or to plug something else.


Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Is the modern memory management really so bad in Pascal?
« Reply #6 on: August 03, 2017, 12:04:28 pm »
Actually we have a (actually several) library based smart pointer type.... Which is in effect the same as a C++ smartpointer, published it on the forum already...
E.g. http://forum.lazarus.freepascal.org/index.php/topic,37524.msg252382.html#msg252382

And Maciej and Sven are busy to put the infrastructure in place to do it even more elegant. But my version is very close in use to a C++ smartpointer.

Also note that Object Pascal (both Delphi and Freepascal) supports all of the *specialized* memory allocation methods that some parts of C++ libraries use by means of libraries or TObject members. E.g. override TObject.Newinstance.
https://www.freepascal.org/docs-html/rtl/system/tobject.newinstance.html
http://docwiki.embarcadero.com/Libraries/Berlin/en/System.TObject.NewInstance

Regarding memory allocation and instantiation Object Pascal can do anything that C++ can, including stack allocation, if required, within the same meta-framework architecture boundaries...

It is just that only advanced Object Pascal users use or need these techniques. C++ programmers tend to be a little more reliant on those techniques, so more often really need it and must use it.

Also note that shared_ptr and unique_ptr are fancy macro's, not part of the language.... Maybe FreePascal can improve on its macro expansion, but that is another subject..
« Last Edit: August 03, 2017, 12:42:37 pm by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018