namespace problem

General FreeBASIC programming questions.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

fxm wrote:
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':
OK, I'm trying to convince myself that unqualified (shortened) names would be OK after USING statement as a feature. While we do follow c++ naming rules for external linkage (ABI), the namespace/using concept is within the compiler only, so we don't necessarily have to copy c++ in every respect.

Here we should probably get an ambiguous symbol definition, as we don't reliably know if we are defining P() or N.P():

Code: Select all

declare sub P()

namespace N
	declare sub P()
end namespace

using N
sub P()
end sub
I have a few other cases I was playing with, but I am kind of thinking, it would be better to design the correct behaviour, and then go from there, to either fix bugs or add the features.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

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
This should be fixed now. It's possible to use fully qualified names without the double parentheses.
#404 len/sizeof type parsing eats namespace prefix
fbc: preserve namespace prefix when parsing len/sizeof (sf.net 404) #201
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: namespace problem

Post by coderJeff »

OK, this is added now. Len / sizeof udt member

Can use Len|Sizeof|Typeof on non-static members. I've tested mostly simple use cases. So will need to see how it holds up to more complicated syntax. In cases where variable and type have name, for example dim t as T, the type name takes precedence.

In earlier versions of fbc, this syntax was not possible, so should not break any existing code:

Code: Select all

'' compiled with fbc 32-bit

type T
	s as string
end type

print sizeof(T)     '' 12
print len(T)        '' 12

print len(T.s)      '' 12
print sizeof(T.s)   '' 12
print len((T).s)    '' 0
print sizeof((T).s) '' 12

dim t as T
t.s = "hello"

print sizeof(t)     '' 12
print len(t)        '' 12

print len(t.s)      '' 12
print sizeof(t.s)   '' 12
print len((t).s)    '' 5
print sizeof((t).s) '' 12

dim x as T
x.s = "hello"

print sizeof(x)     '' 12
print len(x)        '' 12

print len(x.s)      '' 5
print sizeof(x.s)   '' 12
print len((x).s)    '' 5
print sizeof((x).s) '' 12
But as can see from above example, still have some work to do to remove the ambiguities where variable and type have same name.
Post Reply