1.05.0

For other topics related to the FreeBASIC project or its community.
St_W
Posts: 1476
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: 1.05.0

Postby St_W » Jul 09, 2016 2:43

MrSwiss wrote:
St_W wrote: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.

MrSwiss wrote: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
Posts: 9178
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: 1.05.0

Postby fxm » Jul 09, 2016 5:22

As St_W wrote, from the main FreeBASIC manual menu (/wiki/DocToc), and in the "'Language Documentation / Other" paragraph, there is a link (Preprocessor) to a general page on the preprocessor commands.
MrSwiss
Posts: 3259
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: 1.05.0

Postby MrSwiss » Jul 09, 2016 7:18

fxm wrote:... 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
Posts: 2762
Joined: Jun 02, 2015 16:24

Re: 1.05.0

Postby Tourist Trap » Jul 09, 2016 9:00

fxm wrote:As St_W wrote, from the main FreeBASIC manual menu (/wiki/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
Posts: 9178
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: 1.05.0

Postby fxm » Jul 09, 2016 9:48

MrSwiss wrote:
fxm wrote:... 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
Posts: 3259
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: 1.05.0

Postby MrSwiss » Jul 09, 2016 11:07

Thx, fxm - got it, using search (I'm using kchmviewer), since I've kicked out IE.
Jonge
Posts: 129
Joined: Jul 17, 2012 17:51
Location: Norway
Contact:

Re: 1.05.0

Postby Jonge » Jul 13, 2016 21:49

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
Posts: 9178
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: 1.05.0

Postby fxm » Jul 14, 2016 18:29

Yes, it's not due to the compiler revision but to the WinAPI *.bi revision with your usage of 'Namespace':
undef wrote:.....
(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
Site Admin
Posts: 3209
Joined: Jul 28, 2005 14:45
Location: Germany

Re: 1.05.0

Postby dkl » Jul 14, 2016 19:01

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
Posts: 129
Joined: Jul 17, 2012 17:51
Location: Norway
Contact:

Re: 1.05.0

Postby Jonge » Jul 14, 2016 20:25

dkl wrote: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
Site Admin
Posts: 3209
Joined: Jul 28, 2005 14:45
Location: Germany

Re: 1.05.0

Postby dkl » Jul 15, 2016 16:09

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
Posts: 34
Joined: Feb 11, 2010 7:14

Re: 1.05.0

Postby Solbianca » Oct 05, 2016 10:07

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
Site Admin
Posts: 3209
Joined: Jul 28, 2005 14:45
Location: Germany

Re: 1.05.0

Postby dkl » Oct 05, 2016 17:51

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
Posts: 34
Joined: Feb 11, 2010 7:14

Re: 1.05.0

Postby Solbianca » Oct 05, 2016 21:07

@dkl
Thank you for fixing it :3

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 29 guests