Dim Byref syntax

[fxm]

dkl,

I think that all base-type references will be compatible with polymorphism, as now the passed by base-type references to procedures and the returned base-type references from functions (in addition to base-type pointers and dereferenced base-type pointers).

But will we able to define arrays of references (and also arrays of base-type references compatible also with polymorphism)?

Code: Select all

Dim As Integer I1
Dim As Integer I2
Dim As Integer I3

'' array of integer references
Dim Byref As Integer RI(1 To 3) = {I1, I2, I3}

'or

Type Parent Extends Object : End Type
Type Child1 Extends Parent : End Type
Type Child2 Extends Parent : End Type
Type Child3 Extends Parent : End Type

Dim As Child1 c1
Dim As Child2 c2
Dim As Child3 c3

'' array of base-type references to derived-type objects, compatible with polymorphism
Dim Byref As Parent RP(1 To 3) = {c1, c2, c3}

[fxm]

dkl,

I suppose that FreeBASIC will internally implement the references like pointers, but with auto-dereferencing viewed from the user.
So, is that the compiler will allocate the same amount of memory for storage as for a pointer, and place the object address into that storage (similar principle as my macro)?

And what about the other question in my above post (on arrays of references)?

[St_W]

I wonder me that the byref stuff is on the to do list.

Some of us waiting years of much more important things.

Joshy

Code: Select all

SCREENRES w,h,d,,FB.GFX_RESIZEABLE
' or
SCREENCONTROL SET_WIN_RESIZEABLE,1

dim waiting as BOOL

class FreeBASIC extends BASIC, QBASIC
....

Maybe you do consider these features _more_ important than the byref stuff, but that is your opinion and definitely not true for everyone.
Of course multiple inheritance would be a nice feature, but maybe interfaces (as in C#/Java) may even be a better solution? Either one is probably quite a lot of work to implement, especially if it should be binary compatible with g++ (in the case of multiple inheritance).
The boolean datatype of course would also be a nice feature for C/C++ compatibility, but is not really needed in the BASIC ecosystem.
The gfxlib2 was intended for (fixed aspect-ratio) games and thus I would consider a resizable window feature not that important. Of course for different use cases (e.g. simple GUI) it would be nice, but I don't think gfxlib2 is the right library to use for that - there are better libs for these use cases like fltk, wx, gtk, ...

One feature that I personally would consider more important is e.g. built-in Unicode support. So you see that the importance rating of features largely differs depending on the requirements and expectations of the user.

Nethertheless I am happy about each new feature that is added to the compiler / ecosystem as long as it does not cause useless bloat. This is not the case for this byref stuff in my opinion. Already some years ago, I wished I could so such things in FB.

[fxm]

It is natural that each has a different order of priority in its various wishes for new features (eg I put also at first place the multiple interfaces).

But by cons, everyone should agree that the existing bugs corrections should always be a very high priority, and it seems that in recent times the pace of corrections has fallen considerably, perhaps because the transition to 64-bit, resulted in a very heavy workload!

[dafhi]

@dkl - could you make these non const?

[dkl]

With my current implementation you could reassign references by doing:

Code: Select all

@ref = @othervar

i.e. the same that's already possible with Byref parameters.

[fxm]

Perhaps that both correspond to the same existing workaround to modify a Const Ptr, as following:

Code: Select all

Dim As Integer I=123, J=456

Dim As Integer Const Ptr pi = @I
Print *pi

'pi = @J    '' error 118: Cannot modify a constant, before '=' in 'pi = @J'
'*@pi = @J  '' error 118: Cannot modify a constant, before '=' in '*@pi = @J'
@*pi = @J
Print *pi

Sleep

Code: Select all

 123
 456

[Tourist Trap]

What do you think about the syntax? I like it because it matches the syntax for Byref parameters, and Byref function results, and it doesn't require a new keyword...

A possible alternative that I saw suggested on this forum a while ago, by adding the Ref keyword:

I would make a remark, even not as a hardcoder, but since I understand what you are talking about because this is a common concept in vb.net. For what I've been used with, pure value types like Integer should in no case directly be turned Ref unless they get encapsulated in a UDT before, itself being then declared as Reference type.

The first reason I see to that is that you would never have doubt when reading the code about an integer value that you wouldn't remember if it was defined as ref or as value. If its type comes to be named IntegerRefUDT, things are immediatly more clear.

A reference can be thought of as a constant pointer with automatic dereferencing (the compiler will apply the '*' operator for you).

What I'm saying doesn't interfer anything with pointers. But that's a nice thing that pointers with their weird syntax are known to deal directly with addresses and not values. I mean this keeps track on how the computer works. And apparently, people who have learnt C seems to take advantage of it.

So in my very humble opinion, reserve As Ref or ByRef declarator for UDT. ( Or an intermediate solution is to start by implementing this to UDT only in a first time, since doing so would increase immediatly FB compatibility with oo languages where UDT are generally As Ref. Witch would be fine.)

[fxm]

With my current implementation you could reassign references by doing:

Code: Select all

@ref = @othervar

i.e. the same that's already possible with Byref parameters.

It will be therefore possible to reassign a reference, what we can not do with a variable but only with a dereferenced pointer!

An example, always with my macro simulating the reference declarations, and an UDT to control the successive constructions & destructions of objects handled with one only reference:

Code: Select all

#macro DimByRef (typename, ref, obj)
  Dim As typename Const Ptr ptr##ref = @(obj)
  #Define ref (*ptr##ref)
#endmacro


Type UDT
  Declare Constructor ()
  Declare Destructor ()
  Dim As Integer I
End Type

Constructor UDT ()
  Static As Integer nb
  nb += 1
  This.I = nb
  Print "UDT.Constructor()", @This, This.I
End Constructor

Destructor UDT ()
  Print "UDT.Destructor()", @This, This.I
End Destructor


'Dim Byref As UDT ru = *New UDT
DimByRef(UDT, ru, *New UDT)
Print ru.I
Delete @ru
Print

@ru = New UDT
Print ru.I
Delete @ru

Sleep

Code: Select all

UDT.Constructor()           3351904        1
 1
UDT.Destructor()            3351904        1

UDT.Constructor()           3351904        2
 2
UDT.Destructor()            3351904        2

[fxm]

First tests after the "Merge branch 'dimbyref'", with reference variables only:
- Ok for predefined variables.
- OK for simple UDTs
- Almost OK for UDTs with virtuality/polymorphism.

One case does not works:
- If we declare a base-type reference used to refer to a derived-type object, but the base-type having an abstract method!
=> error 305: UDT has unimplemented abstract methods

Example for this error:
(if we put in comment the first line, the abstract method in base-type is replaced by a virtual method, so the program works well with polymorphism OK)

Code: Select all

#define base_with_abstract_method

Type Parent Extends Object
  #ifdef base_with_abstract_method
  Declare Abstract Sub s ()
  #else
  Declare Virtual Sub s ()
  #endif
End Type
#ifndef base_with_abstract_method
Virtual Sub Parent.s ()
  Print "Parent"
End Sub
#endif

Type Child1 Extends Parent
  Declare Virtual Sub s ()
End Type
Virtual Sub Child1.s ()
  Print "Child1"
End Sub

Type Child2 Extends Parent
  Declare Virtual Sub s ()
End Type
Virtual Sub Child2.s ()
  Print "Child2"
End Sub


Dim As Child1 c1
Dim As Child2 c2


'' base-type reference used to refer to derived-type object, compatible with polymorphism
Dim Byref As Parent RP1 = c1
'' base-type reference used to refer to derived-type object, compatible with polymorphism
Dim Byref As Parent RP2 = c2

RP1.s()
RP2.s()

Sleep

Compiler output:
.....\FBIde0.4.6r4_fbc1.04.0\FBIDETEMP.bas(36) error 305: UDT has unimplemented abstract methods, found 'RP1' in 'Dim Byref As Parent RP1 = c1'
.....\FBIde0.4.6r4_fbc1.04.0\FBIDETEMP.bas(38) error 305: UDT has unimplemented abstract methods, found 'RP2' in 'Dim Byref As Parent RP2 = c2'

Dim Byref As Parent RP1 = c1
RP1.s()
should work as:
Dim As Parent Ptr PP1 = @c1
PP1->s()

[fxm]

Other remark:
Dim Shared Byref ...
Static Byref ...
Static Shared Byref ...
each compiles, but crashes at execution when accessing the reference:
Aborting due to runtime error 12 ("segmentation violation" signal)

Only 'Dim Shared Byref ...' should be allowed and should work (for defining global references)?

[dkl]

Hi,

Dim Shared Byref seems to work fine for me; could you post the code that crashes?

This seems to work here on linux-x86:

Code: Select all

dim shared i as integer = 123
dim shared byref ri as integer = i
print ri
ri = 456
print ri

type Parent extends object
	s as string
	declare virtual function f() as string
end type

function Parent.f() as string
	function = "Parent"
end function

type Child extends Parent
	declare virtual function f() as string
end type

function Child.f() as string
	function = "Child"
end function

dim shared x as Child
dim shared byref rx as Child = x
print rx.f()

[fxm]

Excuse me, fake manipulation on my part.
I forgot to also put Shared for the variable!

[dkl]

Ok, shared/static references to stack variables will trigger an error now.

[fxm]

Is this safe?
I think so.

Code: Select all

Dim Byref As Zstring RZ = "Zstring"
Print RZ