namespace problem

General FreeBASIC programming questions.
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

fxm wrote:For the variables defined in a namespace block or the static member variables in an UDT, the keywords "Typeof()" or "Sizeof()" require double parentheses around the names (with the structure name as prefix)
  • (see previous post)
dkl, must I fill a bug report?
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: namespace problem

Post by dkl »

No, it already exists: #404
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

OK
I'll just add a comment.
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

fxm wrote:
fxm wrote:For the variables defined in a namespace block or the static member variables in an UDT, the keywords "Typeof()" or "Sizeof()" require double parentheses around the names (with the structure name as prefix)
  • (see previous post)
dkl, must I fill a bug report?
dkl wrote:No, it already exists: #404
- On a similar subject, why the compiler can not return (through 'Typeof()') the types of any non-static members within TYPE/UNION?

Code: Select all

Dim As Double D
Declare Sub S (Byval As Byte)

Namespace N
  Dim As Double ND
  Declare Sub NS (Byval As Byte)
End Namespace

Type T
  Dim As Double TD
  Static As Double TSD
  Declare Sub TS (Byval As Byte)
  Declare Static Sub TSS (Byval As Byte)
End Type

Union U
  Dim As Double UD
  Static As Double USD
  Declare Sub US (Byval As Byte)
  Declare Static Sub USS (Byval As Byte)
End Union

#print typeof(D)
#print typeof(@S)
#print typeof(N.ND)    '' (error 41: Variable not declared, except with double parentheses)
#print typeof(@N.NS)
#print typeof(T.TD)    '' error 208: Illegal non-static member access
#print typeof(T.TSD)   '' (error 41: Variable not declared, except with double parentheses)
#print typeof(@T.TS)   '' error 208: Illegal non-static member access
#print typeof(@T.TSS)
#print typeof(U.UD)    '' error 208: Illegal non-static member access
#print typeof(U.USD)   '' (error 41: Variable not declared, except with double parentheses)
#print typeof(@U.US)   '' error 208: Illegal non-static member access
#print typeof(@U.USS)
- Same remark for 'Len()'/'Sizeof()'.

Added comment in #404.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: namespace problem

Post by dkl »

In general it's not possible to access fields through the type name, without a variable/object, because they're not static. But maybe we should add an exception and allow it in the context of sizeof/typeof, i.e. places that won't ever actually execute the expression, but just use it at compile-time.

I think this should be added as separate feature request, as I don't think it's related to the namespace prefix parsing issue.
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

Bug or normal behavior?

'Using (Namespaces)' does not work for defining static data members, static procedure members and non-static procedure members of UDT inside a Namespace (the full names are mandatory).
By cons, the shorten names work for accessing static data members, and calling static procedure members.

Code: Select all

Namespace One
    Dim As Integer I1 = 1
    
    Declare Sub s ()
    
    Type UDT
        Dim As Integer I2 = 2
        Static As Integer I3
        Declare Sub s1 ()
        Declare static Sub S2 ()
    End Type
End Namespace

Using One
    Sub s ()
        Print "One.s()"
    End Sub
    
    'Dim As Integer UDT.I3 = 3     '' error 131: Declaration outside the original namespace
    Dim As Integer One.UDT.I3 = 3  '' full name is mandatory
    
    'Sub UDT.s1 ()                 '' error 131: Declaration outside the original namespace
    Sub One.UDT.s1 ()              '' full name is mandatory
        Print "One.s1()"
    End Sub
    
    'Sub UDT.s2 ()                 '' error 131: Declaration outside the original namespace
    Sub One.UDT.s2 ()              '' full name is mandatory
        Print "One.s2()"
    End Sub
    
    Print I1
    
    S()
    
    Dim As UDT u
    Print u.I2
    Print u.I3
    Print UDT.I3                   '' works
    
    u.s1()
    u.s2()
    UDT.s2()                       '' works
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

This seems like it should be the normal behaviour and correct that the definition should be fully qualified, either inside a namespace block, or with the namespace identifier prefix. To have USING import symbols in to the current namespace for access, but not for the purpose of definition. I think code would be best to not allow possibility for "ambiguous symbol definition". The error message is not wrong, though some might split hairs over the difference between declaration versus definition.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: namespace problem

Post by MrSwiss »

coderJeff wrote: The error message is not wrong, though some might split hairs over the difference between declaration versus definition.
I think the term: definition, is ambiguous and better replaced with: implementation.
(if in context with: declaration)

On definition: a #Define (comes to mind, straight away), or a Const. Just my 2 cents.
(this is solely about wording, to clarify meaning, nothing else)
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

coderJeff wrote:This seems like it should be the normal behaviour and correct that the definition should be fully qualified, either inside a namespace block, or with the namespace identifier prefix
But that works for a non-member procedure declared in a Namespace but outside implemented through a 'Using namespace_name':

Code: Select all

Namespace One
    Declare Sub s ()
End Namespace

Using One
    Sub s ()
        Print "One.s()"
    End Sub
The problem is only for static data members, static procedure members and non-static procedure members (all declared in a UDT inside a Namespace).
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

fxm wrote:But that works for a non-member procedure declared in a Namespace but outside implemented through a 'Using namespace_name':

Code: Select all

Namespace One
    Declare Sub s ()
End Namespace

Using One
    Sub s ()
        Print "One.s()"
    End Sub
Oh, that is weird. I would have expected 'sub s()' to be defined in the global namespace instead of namespace One.

Check out this modified example (see bottom of listing for output):

Code: Select all

Namespace One
    Declare Sub s()
End Namespace

Using One

declare sub s()

s()
One.s()

'' undefined reference to `S@0'
'' undefined reference to `ONE::S()@0'
In this case, S() and One.S() are different symbols. I see, currently 'USING One' allows the definition of One.s() provided global 's()' is not already defined.

Therefore, I think 'USING' should not be allowed to affect definition, only to affect access. And the bug is that 'S()' can be defined after 'USING' if no global definition of s() already exists. That seems like the incorrect behaviour to me.

What do you think?
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

In C++:
One aspect of the using directive may seem slightly counterintuitive at first. The visibility of the names introduced with a using directive is the scope in which the directive is made. But you can override the names from the using directive as if they’ve been declared globally to that scope!
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

OK, let me narrow it down:

Code: Select all

namespace one
	declare sub s() '' declaration only
end namespace
using one
sub s() '' definition (and declaration?)
end sub
fxm, in the above example, what do you think? 'sub s()' is global (i.e. not in namespace one)? or respects 'using one' import of symbol names?
fxm
Moderator
Posts: 12083
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: namespace problem

Post by fxm »

Referring to the behavior described for C ++ (see my previous post), the following seems normal to me:

Code: Select all

namespace one
   declare sub s1()
   declare sub s2()
end namespace

using one

sub s1()          '' definition of one.s1()
end sub
declare sub s1()  '' .s1() declared in the scope overrides one.s1()
sub s1()          '' OK, definition of .s1()
end sub

sub s2()          '' definition of one.s2()
end sub
''declare sub s2()
sub s2()          '' error 4: Duplicated definition
end sub
Otherwise, about the 1st point:

Code: Select all

Namespace One
    Namespace Two
        Declare Sub s1 ()
    End Namespace
       
    Type UDT
        Declare Static Sub S2 ()
        Dim As Integer __
    End Type
End Namespace

Using One.Two  '' One.Two is a namespace
Using One.UDT  '' One.UDT is not a real namespace => error 3: Expected End-of-Line
Other weirdness:

Code: Select all

Namespace One
    Dim As Integer I1 = 1
    Sub s1 ()
        Print "One.s()"
    End Sub
   
    Type UDT
        Dim As Integer I2 = 2
        Declare Sub s2 ()
    End Type
    Sub UDT.s2 ()
        Print "UDT.s2()"
    End Sub
      
'    Print I1     '' error 122: Illegal inside a NAMESPACE block
      
'    s1()         '' error 122: Illegal inside a NAMESPACE block
      
    Dim As UDT u
'    Print u.I2   '' error 122: Illegal inside a NAMESPACE block
    u.s2()        '' OK ???
End Namespace
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

fxm wrote:Referring to the behavior described for C ++ (see my previous post), the following seems normal to me:
As far as I know, there is no equivalent to the fbc examples given for this behaviour in C++. The current results for fbc are kind of all over the place. My personal opinion is that USING should be for access only, not definition.

This doesn't seem correct:

Code: Select all

Namespace One: 	declare sub s() :End Namespace
Namespace Two: 	declare sub s() :End Namespace

Using One
Using Two

sub s()  '' defined as Two.s() - must check asm/c output to see.  But why?
end sub

s()      '' ambiguous symbol access
And this does not seem correct either,related to one of listings you posted, where both a namespace s() and a global s() are defined:

Code: Select all

declare sub s()
sub s()
end sub

Namespace One
 	declare sub s()
End Namespace

Using One
sub s()  '' duplicate defintion? Why?
end sub
It seems to me that the namespace resolution is inconsistent at the moment. I know there are several reported bugs related to it.
Post Reply