Page 1 of 1
Allow structure pointers as return types
Posted: Sun Jul 15, 2018 5:59 am
by Mistrel
Currently we can only define an ambiguous integer type to denote structure pointers as return types:
It's impossible to know by looking at this declaration that a pointer is being returned. Or what structure it will point to. Its members are also inaccessible until it is assigned to a variable.
It would go a long way to improve upon self-documenting code in PureBasic if we could identify the type of pointer being returned by a function:
Code: Select all
Structure Struct
value.i
EndStructure
Procedure.Struct* FuncA()
EndProcedure
This would also provide simplified calling when the caller is not responsible for freeing the memory:
Re: Allow structure pointers as return types
Posted: Mon Jul 16, 2018 7:20 am
by IceSoft
You are not alone:
viewtopic.php?f=3&t=60185&hilit=structure+pointers
PureBasic team never understand what the feature really is
Re: Allow structure pointers as return types
Posted: Mon Jul 16, 2018 9:03 am
by infratec
... where the caller is not responsible for freeing the memory:
Why?
The memory is allocated inside the procedure (in your example). Who should free it in your opinion?
And when?
It is freed when the program is terminated but not earlier.
So if you call your procedure in a loop, you get out of memory (if you do it often enough).
Bernd
Re: Allow structure pointers as return types
Posted: Mon Jul 16, 2018 3:03 pm
by skywalk
The code from your post works on v562 x64. Did it not prior? I understand the pointer has no type, so treat it like void and name the pointer as you like. Ex. *myptr_structurenamehere
Re: Allow structure pointers as return types
Posted: Mon Jul 16, 2018 10:57 pm
by mk-soft
It is actually normal that no whole structures with content are returned.
It is also passed in other languages the pointer to the data, or a pointer is passed as a parameter where the data is entered.
So it is a question of the definition of the return value.
Re: Allow structure pointers as return types
Posted: Tue Jul 17, 2018 5:01 am
by Mistrel
infratec wrote:... where the caller is not responsible for freeing the memory:
Why?
I felt "where" when appropriate but I've changed it to "when" to be clearer. The expectation being that the memory will be freed at some point but is NOT by the caller; merely accessed.
infratec wrote:So if you call your procedure in a loop, you get out of memory (if you do it often enough).
Imagine that returned pointer is always the same. It's not allocating any more memory each time it's returned because it always points to the same place.
Giving this a lot of thought, I think that out of all the possible enhancements to PureBasic, extending support of return types to pointers (and interfaces by extension) would give us a lot of added flexibility. I'm already doing things like this to help improve my code's readability:
Code: Select all
Macro POINTER
i
EndMacro
Macro MAP_NODE_POINTER
POINTER
EndMacro
Structure Map_Node
*Left.Map_Node
*Right.Map_Node
...
EndStructure
Declare.MAP_NODE_POINTER Map_CreateNode(_IN Key.MAP_KEY, _IN Value.MAP_VALUE)
Of course I can't actually access the Map_Node result without first assigning it to something. This is merely a standard I use for self-documenting my code.
For structures we could have this:
Code: Select all
Structure Map_Node
*Left.Map_Node
EndStructure
Declare.Map_Node* Map_CreateNode(_IN Key.MAP_KEY, _IN Value.MAP_VALUE)
And for interfaces we could have this:
Code: Select all
Interface Node
getLeft.Node()
EndInterface
Declare.Node CreateNode(_IN Key.MAP_KEY, _IN Value.MAP_VALUE)