* * *

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

Benjiro

  • New member
  • *
  • Posts: 12
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: 1812
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: 3968
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 »
"Logically, no number of positive outcomes at the level of experimental testing can confirm a scientific theory, but a single counterexample is logically decisive."

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus