Abstract/Virtual destructor/method behaviour

For other topics related to the FreeBASIC project or its community.
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Dec 31, 2014 6:17

fxm wrote:.....
How explain that?
- How the polymorphism (using inheritance and virtuality) is broken by the lack of definition of the assign let operator, the '+=' operator, the '@' operator and the 'cast' operator in UDT2, when that works for the member methods even un-defined in UDT2.
- This is as if implicit non-virtual operators in UDT2 override the base operators!
- But no, I think that for UDT2, only an implicit copy let operator and an implicit destructor (both non virtual) are created by compiler.
- So how to explain this behavior?

When these four operators are well defined as virtual in UDT2 (as the destructor, but not the method because useless), the polymorphism works well for the six:
.....

Apart from the case of virtual destructor and the copy let operator where this behavior is explicable (nevertheless this could perhaps be improved), I consider that this behavior for all other virtual member operators is a bug, and I think I will fill a bug report.
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Jan 10, 2015 6:48

dkl thank you to work on the covariance for the revision 1.02.0 of fbc:
- Feature request:
289
- Commits:
[4a68ba]
[e321f5]

1. Covariance on return type in overriding:
OK for the overriding (by returning pointer or reference).
NOK for assigning the return type (by returning pointer or reference).
The main interest of covariant return type in polymorphism is to avoid casting at assignment!

Code: Select all

Type A
  Dim As Integer dummy
End Type

Type B Extends A
End Type

Type Parent Extends Object
  Declare Virtual Function f () As A Ptr
End type
Function Parent.f () As A Ptr
  Print "Parent.f() As A Ptr"
  Return New A
End Function

Type Child Extends Parent
  Declare Virtual Function f () As B Ptr Override
End type
Function Child.f () As B Ptr
  Print "Child.f() As B Ptr"
  Return New B
End Function


Dim As Child ch1

Dim As Parent Ptr ppc = @ch1
Dim As B Ptr pbb = ppc->f()

Sleep
Delete pbb
Compiler output:
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(28) error 180: Invalid assignment/conversion in 'Dim As B Ptr pbb = ppc->f()'

2. Covariance or contravariance on parameter type in overriding:
NOK for covariance on parameter type (for pointer or reference).
NOK for contravariance on parameter type (for pointer or reference).
Looking at the commit [4a68ba]:
type A extends object
end type

type B extends A
end type

declare sub f( byref as A )
dim p as sub( byref as B ) = @f

This pointer assignment can be allowed, because in a p() call, a B object
has to be passed. It will be passed to f() which expects an A. It's ok
because a B is an A.
(of course, the opposite direction would not be safe)
I thought with surprise (because not requested by me as the covariance on parameter type) that the contravariance on parameter type could work at overriding level at least, but no:

Code: Select all

Type A
  Dim As Integer dummy
End Type

Type B Extends A
End Type

Type Parent Extends Object
  Declare Virtual Sub s (Byref b0 As B)
End type
Sub Parent.s (Byref b0 As B)
  Print "Parent.s(Byref As B)"
End Sub

Type Child Extends Parent
  Declare Virtual Sub s (Byref a0 As A) Override
End type
Sub Child.s (Byref a0 As A)
  Print "Child.s(Byref As A)"
End Sub


Dim As A a1
Dim As B b1
Dim As Child ch1

Dim As Parent Ptr ppc = @ch1
ppc->s(a1)

Sleep
Compiler output:
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(16) error 222: Not overriding any virtual method, found 'Override' in 'Declare Virtual Sub s (Byref a0 As A) Override'
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(28) error 57: Type mismatch, at parameter 2 of sub(as PARENT, as B) in 'ppc->s(a1)'
Last edited by fxm on Jan 12, 2015 11:39, edited 10 times in total.
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Jan 10, 2015 9:13

Remark on point 1):
(see also https://sourceforge.net/p/fbc/feature-r ... /289/#6751)
- To authorize the covariance overriding , the type check at compile time must be relaxed to accept not only the return type corresponding to the first abstract/virtual function declaration but also all subtypes corresponding to the overriding function declarations.
- In order to keep a safe typing, a runtime type checking code could be added by compiler in order to return a runtime error message if there is no compatiblity between return type and caller use (super-derived usage forbidden at caller level).
- I think that for comparing (at runtime) the type used by caller with those of the hierarchy of return types, it is necessary that all have a Run-Time Type Information (RTTI).
- It might be well to already impose this condition at compilation time (the virtual function return types derived from 'Object') to accept the covariance overriding.

Code: Select all

Type A Extends Object
End Type

Type B Extends A
End Type

Type C Extends B
End Type

Type Parent Extends Object
  Declare Virtual Function f () As A Ptr
End type
Function Parent.f () As A Ptr
  Print "Parent.f() As A Ptr"
  Return New A
End Function

Type Child Extends Parent
  Declare Virtual Function f () As B Ptr Override
End type
Function Child.f () As B Ptr
  Print "Child.f() As B Ptr"
  Return New B
End Function

Type GrandChild Extends Child
  Declare Virtual Function f () As C Ptr Override
End type
Function GrandChild.f () As C Ptr
  Print "GrandChild.f() As C Ptr"
  Return New C
End Function


Dim As Child ch1

Dim As Parent Ptr ppc = @ch1
Dim As A Ptr pa = ppc->f()  '' must be allowed at compile time and runtime
Dim As B Ptr pb = ppc->f()  '' must be allowed at compile time and runtime
Dim As C Ptr pc = ppc->f()  '' must be allowed at compile time but not at runtime

Sleep
Delete pa
Delete pb
Delete pc
Compiler output:
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(40) error 180: Invalid assignment/conversion in 'Dim As B Ptr pb = ppc->f()'
.....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas(41) error 180: Invalid assignment/conversion in 'Dim As C Ptr pc = ppc->f()'

For override procedures in C++:
- I think that the covariance on return type (pointer or reference) works and fully (including when assigning).
- No covariance/contravariance on parameter.


[edit]
- On Jan 11, 2015: remark complemented.
Last edited by fxm on Jan 12, 2015 11:40, edited 1 time in total.
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Jan 11, 2015 15:09

fxm wrote:Remark on point 1):
(see also https://sourceforge.net/p/fbc/feature-r ... /289/#6751)
- To authorize the covariance overriding , the type check at compile time must be relaxed to accept not only the return type corresponding to the first abstract/virtual function declaration but also all subtypes corresponding to the overriding function declarations.
- In order to keep a safe typing, a runtime type checking code could be added by compiler in order to return a runtime error message if there is no compatiblity between return type and caller use (super-derived usage forbidden at caller level).
- I think that for comparing (at runtime) the type used by caller with those of the hierarchy of return types, it is necessary that all have a Run-Time Type Information (RTTI).
- It might be well to already impose this condition at compilation time (the virtual function return types derived from 'Object') to accept the covariance overriding.
.....

Referring to the above example:
In this precise case of pointer return, functionally, the compiler could replace the user code:

Code: Select all

Dim As A Ptr pa = ppc->f()  '' must be allowed at compile time and runtime
Dim As B Ptr pb = ppc->f()  '' must be allowed at compile time and runtime
Dim As C Ptr pc = ppc->f()  '' must be allowed at compile time but not at runtime
with:

Code: Select all

#macro runTimeCompatibilityTest(objectPointer)
  If Not *Cast(Object Ptr, objectPointer) Is Typeof(*objectPointer) Then
    Error 1
  End If
#endmacro

Dim As A Ptr pa = Cast(C Ptr, ppc->f())  '' allowed at compile time
  runTimeCompatibilityTest(pa)           '' allowed at runtime
Dim As B Ptr pb = Cast(C Ptr, ppc->f())  '' allowed at compile time
  runTimeCompatibilityTest(pb)           '' allowed at runtime
Dim As C Ptr pc = Cast(C Ptr, ppc->f())  '' allowed at compile time
  runTimeCompatibilityTest(pc)           '' not allowed at runtime

Code: Select all

Child.f() As B Ptr
Child.f() As B Ptr
Child.f() As B Ptr

Aborting due to runtime error 1 (illegal function call) at line 48 of .....\FBIde0.4.6r4_fbc1.02.0\FBIDETEMP.bas::()
dkl
Site Admin
Posts: 3210
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Abstract/Virtual destructor/method behaviour

Postby dkl » Jan 11, 2015 21:57

Yea, the case with overriding with contravariant parameters isn't working yet, because it's not finding the virtual based on the override's signature. The lookup is currently based on the one used for overloading, so that's probably the reason.

Contravariant parameters should be working in procedure pointer assignments though.

I only implemented the "trivial" cases, while working on the procedure pointer type checking. It was half-way implemented already (function results), although it was a bit buggy. I have no clue about the non-trivial cases that require runtime checks though.
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Jan 11, 2015 22:24

Ok.
I well understood that those new features are not completed and that this remains to be done with respect to virtuality/polymorphism is not easy.
But why to have closed the feature request #289?
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Mar 07, 2015 21:42

dkl

At the text end of commit [4a68ba], the link is erroneous because it points to the bug #289 instead of the new feature #289 !
counting_pine
Site Admin
Posts: 6180
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Abstract/Virtual destructor/method behaviour

Postby counting_pine » Mar 07, 2015 23:15

It's just a plain-text commit message. The link is automatically provided by SourceForge. It's a helpful feature when bug reports are referenced, but unfortunately here it's kind of confusing.

I can't speak for dkl, but I've never tailored a commit message to take advantage of SF's formatting, although it's nice when it happens (properly). It's not part of the specification for commit messages though, and it's not portable.

Here's the same commit on Github, which does a bit of magic interpretation of its own: https://github.com/freebasic/fbc/commit/4a68bac

In any case, once a commit is part of the public repo history, you can't change it without doing something fairly drastic. The only thing you could do if you found it really confusing would be to put a comment about it on the bug report, explaining it's erroneously linked in a commit, and linking to the feature request.
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Apr 17, 2015 8:59

Type 'ObjectPlus', an extension of the built-in 'Object' type

Type 'ObjectPlus' provides 4 member functions allowing to extend the RTTI resources for all types derived from 'ObjectPlus':
- typeNameString(Byval baseIndex As Integer = 0) As String:
to get the instance type name or the name of any of its base-types,
- typeNameHierarchy () As String:
to get the type names inheritance hierarchy,
- typeNameEqual(Byref typeName As String) As Integer:
to get true if the instance type name is the same than the passed string,
- virtualProcPtr(Byval virtualIndex As Integer) As Any Ptr:
to get a pointer to any virtual procedure of the instance type.

ObjectPlus.bi:

Code: Select all

' ObjectPlus.bi
'
'--------------------------------------------------------------------------------------------------------
'
' Vptr/Vtable/RTTIinfo diagram
'
'                                     Vtable
'                             .---------------------.
'                         (-2)|    reserved (0)     |               RTTIinfo
'    Instance of UDT          |---------------------|       .-----------------------.
'  Extending ObjectPlus   (-1)|   Ptr to RTTIinfo   |--->(0)|     reserved (0)      |    Mangled Typename
' .-------------------.       |---------------------|       |-----------------------|       .--------.
' |Vptr: Ptr to Vtable|--->(0)|Ptr to virt. proc. #1|   (+1)|Ptr to Mangled Typename|--->(0)| Length |
' |-------------------|       |---------------------|       |-----------------------|       | (ASCII)|
' |  typeNameString() |   (+1)|Ptr to virt. proc. #2|   (+2)| Ptr to Base RTTIinfo  |--.    |    &   |
' |  typeNameEqual()  |       |---------------------|       |_______________________|  |    |Typename|
' |  virtualProcPtr() |   (+2)|Ptr to virt. proc. #3|                                  |    | (ASCII)|
' |-------------------|       :- - - - - - - - - - -:   _______________________________|    |________|
' |UDT member field #1|       :                     :  |
' |UDT member field #2|       :                     :  |            Base RTTIinfo
' |UDT member field #3|       :                     :  |      .----------------------------.
' :                   :       :                     :  '-->(0)|        reserved (0)        |
' |___________________|       |_____________________|         |----------------------------|
'                                                         (+1)|Ptr to Mangled Base Typename|--->
'                                                             |----------------------------|
'                                                         (+2)| Ptr to Base.Base RTTIinfo  |--.
'                                                             |____________________________|  |
'                                                                                             V
'--------------------------------------------------------------------------------------------------------

Type ObjectPlus Extends Object
  Declare Function typeNameString (Byval baseIndex As Integer = 0) As String
  Declare Function typeNameHierarchy () As String
  Declare Function typeNameEqual (Byref typeName As String) As Integer
  Declare Function virtualProcPtr (Byval virtualIndex As Integer) As Any Ptr
End Type
 
  Function ObjectPlus.typeNameString (Byval baseIndex As Integer = 0) As String
  ' Member function to get the instance type name or the name of any of its base-types
  ' (baseIndex = 0 to get the type name of the instance)
  ' (baseIndex = -1 to get the base-type name of the instance, or "" if not existing)
  ' (baseIndex = -2 to get the base-base-type name of the instance, or "" if not existing)
  ' (.....)
    Dim As String S
    Dim As ZString Ptr pz = Cptr(Any Ptr Ptr Ptr, @This)[0][-1] ' Ptr to RTTIinfo
    For I As Integer = baseIndex To -1
      pz = Cptr(Any Ptr Ptr, pz)[2]                             ' Ptr to Base RTTIinfo
      If pz = 0 Then Return s
    Next I
    pz = Cptr(Any Ptr Ptr, pz)[1]                               ' Ptr to Mangled Typename
    Do
      Do While (*pz)[0] > Asc("9") Orelse (*pz)[0] < Asc("0")
        If (*pz)[0] = 0 Then Return S
        pz += 1
      Loop
      Dim As Integer N = Val(*pz)
      Do
        pz += 1
      Loop Until (*pz)[0] > Asc("9") Orelse (*pz)[0] < Asc("0")
      If s <> "" Then S += "."
      S += Left(*pz, N)
      pz += N
    Loop
  End Function
 
  Function ObjectPlus.typeNameHierarchy () As String
  ' Member function to get the type names inheritance hierarchy
    Dim As String s = This.typeNameString()
    Dim As Integer i = -1
    Do
      Dim As String s0 = This.typeNameString(i)
      If s0 = "" Then Exit Do
      s &= "->" & s0
      i -= 1
    Loop
    Return s
  End Function

  Function ObjectPlus.typeNameEqual (Byref typeName As String) As Integer
  ' Member function to get true if the instance type name is the same than the passed string
    Dim As String t = Ucase(typeName)
    Dim As ZString Ptr pz = Cptr(Any Ptr Ptr Ptr Ptr, @This)[0][-1][1] ' Ptr to Mangled Typename
    Dim As Integer i = 1
    Do
      Do While (*pz)[0] > Asc("9") Orelse (*pz)[0] < Asc("0")
        If (*pz)[0] = 0 Then Return -1
        pz += 1
      Loop
      Dim As Integer N = Val(*pz)
      Do
        pz += 1
      Loop Until (*pz)[0] > Asc("9") Orelse (*pz)[0] < Asc("0")
      If i > 1 Then
        If Mid(t, i, 1) <> "." Then Return 0 Else i += 1
      End If
      If Mid(t, i, N) <> Left(*pz, N) Then Return 0 Else pz += N : i += N
    Loop
  End Function

  Function ObjectPlus.virtualProcPtr (Byval virtualIndex As Integer) As Any Ptr
  ' Member function to get a pointer to any virtual procedure of the instance type,
  ' depending on its virtual/abstract declaration number
  ' (virtualIndex = 0 to get pointer to the first declared virtual/abstract procedure of instance type)
  ' (virtualIndex = 1 to get pointer to the second declared virtual/abstract procedure of instance type)
  ' (.....)
    Return Cptr(Any Ptr Ptr Ptr, @This)[0][virtualIndex] ' Ptr to virt. proc.
  End Function

Example of UDT inheritance structure extending 'ObjectPlus' instead of only 'Object', in order to use these 4 resources in addition to those from the pure RTTI:

Code: Select all

#Include "ObjectPlus.bi"

Namespace MyUDT

  Type Parent Extends ObjectPlus
    Declare Virtual Function vf (Byref s As String = "") As String
    Declare Function Parent_vf (Byref s As String = "") As String
  End Type
 
    Virtual Function Parent.vf (Byref s As String = "") As String
      Return s & "Parent.vf() with @This=" & @This
    End Function
 
    Function Parent.Parent_vf (Byref s As String = "") As String
      Dim As Parent p0
      Dim As Function (Byref As ObjectPlus, Byref As String) As String vp0
      vp0 = p0.virtualProcPtr(0)
      Return vp0(This, s)
    End Function

  Type Child Extends Parent
    Declare Virtual Function vf (Byref s As String = "") As String Override
    Declare Function Child_vf (Byref s As String = "") As String
  End Type
 
    Virtual Function Child.vf (Byref s As String = "") As String
      Return s & "Child.vf() with @This=" & @This
    End Function
 
    Function Child.Child_vf (Byref s As String = "") As String
      Dim As Child c0
      Dim As Function (Byref As ObjectPlus, Byref As String) As String vc0
      vc0 = c0.virtualProcPtr(0)
      Return vc0(This, s)
    End Function
 
  Type GrandChild Extends Child
    Declare Virtual Function vf (Byref s As String = "") As String Override
    Declare Function GrandChild_vf (Byref s As String = "") As String
  End Type
 
    Virtual Function GrandChild.vf (Byref s As String = "") As String
      Return s & "GrandChild.vf() with @This=" & @This
    End Function
 
    Function GrandChild.GrandChild_vf (Byref s As String = "") As String
      Dim As GrandChild gc0
      Dim As Function (Byref As ObjectPlus, Byref As String) As String vgc0
      vgc0 = gc0.virtualProcPtr(0)
      Return vgc0(This, s)
    End Function

End Namespace

'--------------------------------------------------------------------------------------------------------

Using MyUDT
Dim As GrandChild gc

Print "'" & gc.typeNameString() & "'"
Print "'" & gc.typeNameString(-1) & "'"
Print "'" & gc.typeNameString(-2) & "'"
Print "'" & gc.typeNameString(-3) & "'"
Print "'" & gc.typeNameString(-4) & "'"
Print

Print "'" & gc.typeNameHierarchy() & "'"
Print

Print gc.GrandChild_vf("On GrandChild instance @gc=" & @gc & ", execute ")
Print gc.Child_vf("On GrandChild instance @gc=" & @gc & ", execute ")
Print gc.Parent_vf("On GrandChild instance @gc=" & @gc & ", execute ")
Print

Print "MyUDT.GrandChild:", gc.typeNameEqual("MyUDT.GrandChild")
Print "MyUDT.Child:",, gc.typeNameEqual("MyUDT.Child")
Print "MyUDT.Parent:",, gc.typeNameEqual("MyUDT.Parent")
Print "ObjectPlus:",, gc.typeNameEqual("ObjectPlus")
Print "Object:",, gc.typeNameEqual("Object")
Print

Sleep

Code: Select all

'MYUDT.GRANDCHILD'
'MYUDT.CHILD'
'MYUDT.PARENT'
'OBJECTPLUS'
'OBJECT'

'MYUDT.GRANDCHILD->MYUDT.CHILD->MYUDT.PARENT->OBJECTPLUS->OBJECT'

On GrandChild instance @gc=1244912, execute GrandChild.vf() with @This=1244912
On GrandChild instance @gc=1244912, execute Child.vf() with @This=1244912
On GrandChild instance @gc=1244912, execute Parent.vf() with @This=1244912

MyUDT.GrandChild:           -1
MyUDT.Child:                 0
MyUDT.Parent:                0
ObjectPlus:                  0
Object:                      0


[edit]
- Formatting.
- Added 'typeNameHierarchy () As String' member function.
Last edited by fxm on Jan 10, 2016 21:14, edited 10 times in total.
D.J.Peters
Posts: 8023
Joined: May 28, 2005 3:28
Contact:

Re: Abstract/Virtual destructor/method behaviour

Postby D.J.Peters » Apr 17, 2015 9:26

very interesting thank you for sharing.

Joshy
D.J.Peters
Posts: 8023
Joined: May 28, 2005 3:28
Contact:

Re: Abstract/Virtual destructor/method behaviour

Postby D.J.Peters » Apr 18, 2015 8:06

Code: Select all

'                                     Vtable
'                             .---------------------.
'                         (-2)|    reserved (0)     |               RTTIinfo             Mangled Typename
'    Instance of UDT          |---------------------|       .-----------------------.       .--------.
'  Extending ObjectPlus   (-1)|   Ptr to RTTIinfo   |--->(0)|     reserved (0)      |       | Length |
' .-------------------.       |---------------------|       |-----------------------|       | (ASCII)|
' |Vptr: Ptr to Vtable|--->(0)|Ptr to virt. proc. #1|   (+1)|Ptr to Mangled Typename|--->(0)|    &   |
' |-------------------|       |---------------------|       |-----------------------|       |Typename|
'                                                                                           | (ASCII)|
'                                                                                           |________|
Hello fxm
Is is posible to use the mangled typename section in the diagram
to fake the missing C++ bool name mangling in FreeBASIC ?

Joshy
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Apr 18, 2015 12:36

A question that goes far beyond my competence!
dkl (Jul 28, 2013) wrote:The encoding of UDT names, <length> <identifier>, is simply the C++ name mangling. The length is needed in mangled symbol names to be able to demangle them without amgiuity, since the original identifier is included aswell and could otherwise be confused with characters that are given special meaning in the name mangling scheme. This doesn't really matter for the identifiers stored in the rtti tables, it's just that GCC stores the mangled name, so I did the same for fbc to be compatible. But there's no rule about that, I think. Using the mangled name is good though because it means that namespaces will automatically be handled and encoded too, so structures with the same identifier but from different namespaces won't be treated as equal by the Is operator which is based around comparing these type identifiers from the RTTI tables. (However, currently that part is broken in fbc, it doesn't encode namespaces into UDT mangled names yet, but gcc does)
Since fbc rev 1.00.0, the namespace structure is now encoded in the RTTI block where is the UDT name, and the IS operator works with namespaces.

Details on the encoding of typename in the RTTI block:
- The mangled typename is a Zstring (ended by the null character).
- Each component of the full typename is preceded by its number of characters encoded in ASCII itself.
- When the type is inside at least one namespace, the mangled typename string begins with an additional "N" and ends with an additional "E".

Test program:

Code: Select all

Type myUDT Extends Object
End Type

Namespace myNamespace
  Type myUDT Extends Object
  End Type
End Namespace

Namespace myNamespace
  Namespace myNamespaceNested
    Type myUDT Extends Object
    End Type
  End Namespace
End Namespace


Dim As ZString Ptr pz

Dim As myUDT u
pz = Cptr(Any Ptr Ptr Ptr Ptr, @u)[0][-1][1] ' pointer to mangled typename
Print *pz
Print

Dim As myNamespace.myUDT nu
pz = Cptr(Any Ptr Ptr Ptr Ptr, @nu)[0][-1][1] ' pointer to mangled typename
Print *pz
Print

Dim As myNamespace.myNamespaceNested.myUDT n1n2u
pz = Cptr(Any Ptr Ptr Ptr Ptr, @n1n2u)[0][-1][1] ' pointer to mangled typename
Print *pz
Print

Sleep


RTTI name mangling in FreeBASIC:

5MYUDT
(for 'myUDT')

N11MYNAMESPACE5MYUDTE
(for 'myNamespace.myUDT')

N11MYNAMESPACE17MYNAMESPACENESTED5MYUDTE
(for 'myNamespace.myNamespaceNested.myUDT')

(Is the prefix "N" and the suffix "E" from namespace?)
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » May 22, 2015 8:05

fxm wrote:RTTI name mangling in FreeBASIC:

5MYUDT
(for 'myUDT')

N11MYNAMESPACE5MYUDTE
(for 'myNamespace.myUDT')

N11MYNAMESPACE17MYNAMESPACENESTED5MYUDTE
(for 'myNamespace.myNamespaceNested.myUDT')

(Is the prefix "N" and the suffix "E" from namespace?)

One of the problems with name mangling is that the C++ standard does not define how names have to be mangled; thus every compiler mangles names in its own way. Some compilers even change their name mangling algorithm between different versions.

In FreeBASIC, the name mangling seems to be issued from gcc (g++).
I found this web page (http://stackoverflow.com/questions/1605 ... sing-typei):
.....

Code: Select all

#include <iostream>
#include <typeinfo>

namespace foo { namespace bar {
    enum Frob {};
    class Frobnicate {};
    Frob frob;

    template <typename T> void Meh() { throw T(); }
} }

int main () {
    std::cout << typeid(foo::bar::Frob).name() << '\n'
              << typeid(foo::bar::Frobnicate).name()  << '\n' 
              << typeid(foo::bar::frob).name() << '\n'
              << typeid(foo::bar::Meh<int>).name() << '\n'
              << typeid(foo::bar::Meh<float>).name() << '\n'
    ;
}
N3foo3bar4FrobE
N3foo3bar10FrobnicateE
N3foo3bar4FrobE
FvvE
FvvE

.....
fxm
Posts: 9529
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Abstract/Virtual destructor/method behaviour

Postby fxm » Jul 25, 2015 6:31

I wonder if the name mangling is the same in FreeBASIC 64-bit as in 32-bit version.
Could someone test the 64-bit version, by running my little code in the above post: viewtopic.php?p=207004#p207004?

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest