Allow structure pointers as return types

[Mistrel]

Currently we can only define an ambiguous integer type to denote structure pointers as return types:

Code: Select all

Declare.i FuncA()

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:

Code: Select all

Debug FuncA()\value

[IceSoft]

You are not alone:
viewtopic.php?f=3&t=60185&hilit=structure+pointers

PureBasic team never understand what the feature really is

[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

[skywalk]

You are not alone:
viewtopic.php?f=3&t=60185&hilit=structure+pointers

PureBasic team never understand what the feature really is

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

[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.

[Mistrel]

... 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.

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)