1.05.0

[St_W]

Don't start getting offensive

No problem, should you decide to stop, to treat everybody (except yourself), as a bloody beginner.

I'm sorry that you feel like that, but I can ensure that this isn't and never was my intention.

The need to document stuff, that isn't self-evident to everybody (specially Beginners), does not mean, because some more advanced people know it, it should not be done.

I agree to some extent, but we always have to balance compactness vs. extensive descriptions of every possible detail. IMHO the language reference is not the place where trivial questions should be answered or beginner's issues should be discussed - such things are fine but long detailed textual descriptions belong into tutorials, programmer's manuals, books, ... I'm against blowing up the language reference with redundant, trivial or self-explaining material, that makes extracting the essential information more difficult (as the text gets longer and longer).

To get back to the thread topic: all I was saying in my last posts was that I think that this essential information is already documented, i.e. a compact description explaining preprocessor commands (http://www.freebasic.net/wiki/wikka.php ... PreProcess) and a short description of control flow commands (http://www.freebasic.net/wiki/wikka.php ... ontrolFlow). Maybe the former could be formulated a bit better to explicitly stress that this happens at compile time.

[fxm]

As St_W wrote, from the main FreeBASIC manual menu (DocToc), and in the "'Language Documentation / Other" paragraph, there is a link (Preprocessor) to a general page on the preprocessor commands.

[MrSwiss]

... there is a link (Preprocessor) to a general page on the preprocessor commands.

Thanks, gentlemen, that's what I've been locking for. However, in the "offline Doc." (*.pdf),
I could not find it, for some reason. (Indexing?)

I also agree with keeping Doc. as tight/concise as possible, but adding a short remark,
stating a Main-Difference, especially, if it applies to "all" in the Chapter, seems worth wile.

It's done, all over Doc., with respect to "dialect" differences, so why not, with respect of
Preprocessor vs. Processor? At the Preprocessor Page. I'd suggest, dkl's short explanation.

As you all know, such really "good/helpful" input, is easily lost, in the Forum (not so, in Doc.).

[Tourist Trap]

As St_W wrote, from the main FreeBASIC manual menu (DocToc), and in the "'Language Documentation / Other" paragraph, there is a link (Preprocessor) to a general page on the preprocessor commands.

Just a small remark, no criticism or anything. Just about the logic.
The preprocessor commands have a different logic than the normal code commands, so this is not logical, in my opinion, to try to infere or deduce too much rules by importing them from the world of the normal commands and exporting them in the world of the preprocessor's ones.
Sometimes it's quite difficult (like with the variables evaluation versus text replacement), but sometimes it's just obvious. For me, the keywords marked by the # have not to behave like the others, neither do the keywords marked by __ (double underscore), that's why they are marked so distinctively after all. (it even helps a lot that some details are different in order to make this clear that preprocessor is different, for instance the lack of #THEN keyword is quite useful though it could look surprising - my claim is that it's a great hint in order to show how to reason "logically" according to the language inner - and sometimes subtle - logic).

[fxm]

... there is a link (Preprocessor) to a general page on the preprocessor commands.

Thanks, gentlemen, that's what I've been locking for. However, in the "offline Doc." (*.pdf),
I could not find it, for some reason. (Indexing?)

In the "doc.chm", this page is at index: Preprocessor

[MrSwiss]

Thx, fxm - got it, using search (I'm using kchmviewer), since I've kicked out IE.

[Jonge]

In one of my projects I have put some WinAPI code into a namespace to avoid name clashes like this:

Code: Select all

Namespace Win32

	#Include "windows.bi"
	#Include Once "win/commdlg.bi"

...

End Namespace

This worked fine on FB 1.02.1 Win32, but gives me an error with the latest 1.05.0 release.

Code: Select all

I now get this error:
C:\Dev\FreeBASIC-1.05.0-win32\inc\win\winnt.bi(336) error 122: Symbols defined inside namespaces cannot be removed, found '_rotl' in '#undef _rotl'

On these lines:

In winnt.bi:
#undef _rotl
#undef _rotr
declare function _rotl cdecl(byval Value as ulong, byval Shift as long) as ulong
declare function _rotr cdecl(byval Value as ulong, byval Shift as long) as ulong

In winerror.bi:
#undef __IN__WINERROR_

So I wonder if this is a bug in the compiler/.bi files, or if I have to change my code?

EDIT:
I see the WinAPI bi files has been updated after 1.02.1 so that's why I get an error now.

[fxm]

Yes, it's not due to the compiler revision but to the WinAPI *.bi revision with your usage of 'Namespace':

.....
(Note: #undef should not be used to undefine variable or function names used in the current function scope. The names are needed internally by the compiler and removing them can cause strange and unexpected results.)
.....

[dkl]

The new Windows API binding was pretty complex, and it has some #undefs. In some places they're used to override stuff from CRT headers... but honestly ultimately they could probably be solved out.

On the other hand, wrapping unrelated .bi files in namespaces isn't supported. It only works thanks to the Extern blocks, but anything outside will have its external name changed by the namespace, breaking compatibility/expectations.

[Jonge]

On the other hand, wrapping unrelated .bi files in namespaces isn't supported.

Ok, I was a bit worried back when I wrote the code, but it seemed to work =)

[dkl]

As an alternative to the namespace, I like to put all Windows API code in one or more modules (separately compiled .bas files) completely separated from the other parts of the program.

That way windows.bi won't be #included everywhere, but only in there, which avoids the namespace pollution and speeds up compile times by avoiding having to re-read windows.bi for each module.

[Solbianca]

Hello there,

I think that wstring type has a bug of the surrogate pair conversion. When it convert code point into a surrogate pair, the high surrogate has a wrong value. Probably the operation does not subtract &h10000ul from code point.

Test Code:

Code: Select all

type SurrogatePair
    as ushort high
    as ushort low
end type

declare function ToSurrogatePair(byval code as ulong) as SurrogatePair
declare function ToUnicode(byval high as ushort, byval low as ushort) as ulong


dim as ulong x = &h292B1ul

dim as SurrogatePair pair = ToSurrogatePair(x)
dim as wstring*3     wst1 = wchr(pair.high) + wchr(pair.low)

print "Unicode: "; hex(x)

print
print "To Surrogate Pair: "; hex(pair.high), hex(pair.low)
print "String: "; wst1
print "Length: "; len(wst1)
print "To Unicode: "; hex(ToUnicode(pair.high, pair.low))


dim as wstring*3 wst2 = "  " '' insert the &h292B1ul character.

print
print "To Surrogate Pair: "; hex(asc(wst2, 1)), hex(asc(wst2, 2))
print "String: "; wst2
print "Length: "; len(wst2)
print "To Unicode: "; hex(ToUnicode(asc(wst2, 1), asc(wst2, 2)))

sleep
end


'' ::::::::
function ToSurrogatePair(byval code as ulong) as SurrogatePair
    code -= &h10000ul

    dim as const ushort high = cushort(code \   &h400ul + &hD800ul)
    dim as const ushort low  = cushort(code mod &h400ul + &hDC00ul)

    return type(high, low)
end function

'' ::::::::
function ToUnicode(byval high as ushort, byval low as ushort) as ulong
    return &h10000ul + (culng(high) - &hD800ul) * &h400ul + (culng(low) - &hDC00ul)
end function

Oops, this forum does not supporting the extended partition of Unicode...

[dkl]

Hello,

that's a good catch, thanks. The hint about missing subtraction of &h10000 was exactly right. I've added the change here in Git.

[Solbianca]

@dkl
Thank you for fixing it :3