Where do you find it ? Not the master.fxm wrote:changelog.txt (today):
Study of symbol lookups in namespaces and types
Re: Study of symbol lookups in namespaces and types
Re: Study of symbol lookups in namespaces and types
https://sourceforge.net/p/fbc/code/ci/m ... ngelog.txt
or
https://github.com/freebasic/fbc/blob/m ... ngelog.txt
or
in the distribution of the last build of fbc 1.09.
or
https://github.com/freebasic/fbc/blob/m ... ngelog.txt
or
in the distribution of the last build of fbc 1.09.
Re: Study of symbol lookups in namespaces and types
The update was not done today but 12 days ago. Misinterpreted....fxm wrote:changelog.txt (today):
Re: Study of symbol lookups in namespaces and types
Excuse me.
I confused with daily build.
I confused with daily build.
Re: Study of symbol lookups in namespaces and types
I found a compiler bug around name look-up (Aborting due to runtime error 12 ("segmentation violation" signal)) not due to the fbc 1.09 changes:
To also take into account.
Code: Select all
Namespace M
Sub ok() : Print "OK" : End Sub
End Namespace
Type UDT
Declare Sub test()
Dim As Integer __
End Type
Sub UDT.test()
Using M
This.ok()
End Sub
Re: Study of symbol lookups in namespaces and types
You mean that it should throw a different error because of This?
If I understand the code correctly, This.ok tries to find the member ok in UDT. Without This. there's no error:
If I understand the code correctly, This.ok tries to find the member ok in UDT. Without This. there's no error:
Code: Select all
Namespace M
Sub ok() : Print "OK" : End Sub
End Namespace
Type UDT
Declare Sub test()
Dim As Integer __
End Type
Sub UDT.test()
Using M
ok()
End Sub
dim u as udt
u.test()
Re: Study of symbol lookups in namespaces and types
A TYPE can be declared inside a NAMESPACE, but you can't declare a TYPE inside a TYPE. (angros47 was requesting that feature so that fbc could interface with some g++ libraries.)Munair wrote:I always use TYPES as a way of structuring module code. That's why I was wondering about the necessity of an additional namespace feature. Are there declarations that can be part of namespaces but not TYPES?
Re: Study of symbol lookups in namespaces and types
Do you have an example?SARG wrote:This morning I got an error using 1.09. It took me a bit of time before understanding it.
By error there was a dot before a variable name : '.typ'.
No error with 1.08 and it's working fine but with 1.09 this error happens : undefined symbol.
I guess that changes made for namespaces/types cause this new behaviour.
I forgot to synchronize sourceforge.net. github and sourceforge both now have latest changes (pushed today).
Re: Study of symbol lookups in namespaces and types
Drat.fxm wrote:I found a compiler bug around name look-up (Aborting due to runtime error 12 ("segmentation violation" signal)) not due to the fbc 1.09
I see what is happening, yes.
Yes, and erroneously finds it, thinking it is an inherited member of 'UDT'. Because in the current context after 'using M', 'M.ok()' has been imported in to 'UDT', well in the current scope, anyway.Munair wrote:If I understand the code correctly, This.ok tries to find the member ok in UDT.
The segfault happens because fbc tries to construct a call to M.ok() with the instance pointer 'this', and since the compiler hasn't planned for that, it craps out. IN the debug version of fbc, it throws an error on a failed assert.
Re: Study of symbol lookups in namespaces and types
Seems like the same old difficulty between C and C++ libs, as demonstrated here.coderJeff wrote:A TYPE can be declared inside a NAMESPACE, but you can't declare a TYPE inside a TYPE. (angros47 was requesting that feature so that fbc could interface with some g++ libraries.)Munair wrote:I always use TYPES as a way of structuring module code. That's why I was wondering about the necessity of an additional namespace feature. Are there declarations that can be part of namespaces but not TYPES?
Re: Study of symbol lookups in namespaces and types
What I mean is that without NAMESPACE, every TYPE has to have a unique name in the entire source. That might be OK if you control all the source. If you don't control all the source, NAMESPACE may help.
Can't do that with TYPES only in fbc currently (independently of any g++ desires).
Code: Select all
namespace library1
type T '' some plain old struct
__ as integer
end type
end namespace
namespace library2
type T extends object '' something fancy
end namespace
dim x as library1.T
dim y as library2.T
Re: Study of symbol lookups in namespaces and types
BTW, I tested it with FBC 1.08 and it gives the same error: "Aborting due to runtime error 12 ("segmentation violation" signal)" (copied from Geany). So it's not just 1.09.coderJeff wrote:Yes, and erroneously finds it, thinking it is an inherited member of 'UDT'. Because in the current context after 'using M', 'M.ok()' has been imported in to 'UDT', well in the current scope, anyway.Munair wrote:If I understand the code correctly, This.ok tries to find the member ok in UDT.
The segfault happens because fbc tries to construct a call to M.ok() with the instance pointer 'this', and since the compiler hasn't planned for that, it craps out. IN the debug version of fbc, it throws an error on a failed assert.
Re: Study of symbol lookups in namespaces and types
I pushed changes to fbc/master that fix #948 Overriding class members doesn't work inside methods of further-extended subclassesfxm wrote:To sum up, the unqualified name look-ups for future fbc 1.09 version should verify the priority hierarchy as follows:
- (1) current namespace/type
- (2) base types (by 'Extends'), ranked from closest to furthest in inheritance hierarchy
- (3) parent namespaces, ranked from closest to furthest in ancestry hierarchy (including global namespace: always furthest in hierarchy)
- (4) imported namespaces (by 'Using'), without hierarchy between them
I added quite a few tests to the test suite. It was kind of tricky at first to test namespaces directly in the test-suite because the framework is based on ... namespaces. :)
A couple of examples that show changes from fbc-1.08 (simplified from test-suite entries)
1)
Code: Select all
dim shared A as integer = 2
type P extends object
A as integer = 1
declare sub proc()
end type
sub P.proc()
? __FUNCTION__
? A
end sub
type C extends P
declare sub proc()
end type
sub C.proc()
? __FUNCTION__
? A
end sub
type C2 extends C
declare sub proc()
end type
sub C2.proc()
? __FUNCTION__
? A
end sub
dim z as C2
'' fbc-1.08 fbc-1.09
cast(P, c).proc() '' 1 1
cast(C, c).proc() '' 2 1
z.proc() '' 2 1
Code: Select all
type P extends object
A as integer = 1
declare sub proc()
end type
sub P.proc()
? __FUNCTION__
? A
end sub
type C extends P
A as integer = 2
declare sub proc()
end type
sub C.proc()
? __FUNCTION__
? A
end sub
type C2 extends C
declare sub proc()
end type
sub C2.proc()
? __FUNCTION__
? A
end sub
dim z as C2
'' fbc-1.08 fbc-1.09
cast(P, c).proc() '' n/a 1
cast(C, c).proc() '' n/a 2
z.proc() '' n/a 2
Re: Study of symbol lookups in namespaces and types
Yes, I understand.coderJeff wrote:What I mean is that without NAMESPACE, every TYPE has to have a unique name in the entire source. That might be OK if you control all the source. If you don't control all the source, NAMESPACE may help.Can't do that with TYPES only in fbc currently (independently of any g++ desires).Code: Select all
namespace library1 type T '' some plain old struct __ as integer end type end namespace namespace library2 type T extends object '' something fancy end namespace dim x as library1.T dim y as library2.T
Re: Study of symbol lookups in namespaces and types
coderJeff wrote:Do you have an example?SARG wrote:This morning I got an error using 1.09. It took me a bit of time before understanding it.
By error there was a dot before a variable name : '.typ'.
No error with 1.08 and it's working fine but with 1.09 this error happens : undefined symbol.
I guess that changes made for namespaces/types cause this new behaviour.
Code: Select all
Dim Shared As Integer I
Print .I '' OK
Dim As Integer J
Print .J '' error 8: Undefined symbol, J in 'Print .J' with fbc 1.09
'' OK with fbc 1.08