New command "IsMemoryID(*memoryID)

[walbus]

With all due respect for the efforts
If it doesn't correspond to proper programming, check your application for memory leaks during development.
A clean application does not need any features to check if the allocated memory has been released again.

[mk-soft]

That's how I see it.
My code may be useful for debugging purposes.
where the error occurred.

I have change my code. Is now only active at Debugging-Mode

[walbus]

Well, the only memory leaks I've been not exactely able to locate so far were not caused by me self

[Kurzer]

@walbus:

If it doesn't correspond to proper programming, check your application for memory leaks during development.

That is correct and that is what I am already doing. But should this be a justification for declaring my suggestion unnecessarily?

With this explanation, any bug could be declared unnecessary if there is a workaround for it. "The bug doesn't have to be fixed, you can use this workaround, because it will get you there.

My suggestion should be a suggestion to improve PureBasic, no more and no less. Ultimately, Fred has to decide whether the suggestion makes sense or not. And according to freak's statement he has already decided that, which is why I don't understand why so much is still being discussed here. ; -)

There can't be any IsMemoryID() function, because you can and must release simple and very fast the memory with FreeMemory() and then write it to Nirvana

Such a function therefore makes no sense

Apart from the fact that your statement would also apply to the following commands... IsFile(), IsWindow(), IsGadget() and so on, what exactly does hurts you if PB internally robusten the memory allocations / freeing by using a MemoryNumber instead of an Address?

Your reasoning ".... because you can and must release simple and very fast the memory with FreeMemory()" is incomprehensible. How many times per second do you want to allocate or free memory to justify that it would be too slow with my suggested methode? Incidentally, it would also be simple too if you would use a memory number. The Freememeory() function would not differ from the current one except that a MemoryNumber is passed as a parameter instead of an address.

@mk-soft: thanks for you effort creating some nice macros.

[walbus]

Well, I see no problem in discussing it,
such forums are therefore called discussion forums.
Every unnecessary function slows down a system
The primary act around creating fast applications is based on simplification and omission of unnecessary things
This begins in the small and ends on a large scale
Smaller sums up quickly to big if one does not work deliberately

[Fred]

There is use cases where your need a lot of small memory allocations, and adding an extra linked list element for every allocation is way too much.If you want to create your own list for example, you will end up with twice the memory used and a lot of memory fragmentation. It was working like that before (AllocateMemory(#Buffer, Size) but it wasn't convient (as you basically only need the pointer anyway), was slow and memory intensive.

[Kurzer]

Fred, thank you for the first-hand information (which freak has already published).

Since you as the programmer of PureBasic have already had experience with a memory number, your decision to remove this old feature is completely legitimate and understandable to me.

I am not a stubborn man and I like to be taught better things when the explanations are plausible and understandable to me. So thank you for your statement regarding your experiences with this topic.


Walbus, apologize for being so critical, but I don't know you personally and I can't tell whether you have real experience with the memory stuff behind the scenes or whether you're just talking about without real background.