Is this principle could be also allowed outside a Type block, in order to be able to separate the reference declaration and the reference assignment? I think that the principle should be allowed inside type block only. Because, when use outside type block, it don't meet the requirement of reference...

Yea, I suppose a rule like "all references must be assigned in the constructor" could work. It's probably better than adding a new syntax, and the compiler can do some basic checking to ensure all references are assigned at least once in the constructor. You'd just have to be careful not ...

If FB initializes normal fields too without calling of the copy/assign operator, we need the member initializer like C++. Do you have any good ideas about that? I thought about that in my own way. type Foo public: constructor(byref n as const Bar) '' init constructor. ... private: as Bar value = any...

I think that FB does't need a new syntax for it. For example, use ANY keyword. type Foo public: declare constructor(byref n as const integer, byref m as integer) private: as const integer constValue = any '' no initialize yet. byref as integer byrefValue = any '' no initialize yet. end type construc...

@dkl
Thank you for fixing it :3

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: type SurrogatePair as ushort high as ushort lo...

@dkl @fxm The reason for this is that if the base class has a Let overload, then the derived class must have one too, otherwise assignment would be broken: the base's Let operator wouldn't be called when assigning objects of the derived class. Now I get it! The compiler generated the error because o...

Hi, This class can not inherit. type Foo public: declare constructor() declare destructor() ... private: declare operator let(byref as const Foo) ... end type Result: error 201: Illegal member access, Foo.operator.let The derived class is copying the object of the base class internally. Why? Thanks,

Hi,
Yes, I confirmed that the problem was solved.
Thank you again :D

As you're japanese (it seems) the string $$__compilinfo__$$.... is stored in the exe with an Unicode format. But fbdebugger is searching the string in Ascii format (in the memory area where the constants are stored). For information, when loading the variable named compil_info a function is called ...

Hi,
Oh, I'm sorry to have caused you trouble.

Try this:
http://fileup.jp/up/9590.zip.html
It is no password.

Umm... It is surely strange.

File: http://fileup.jp/up/9589.zip.html
Download pass: abc
(I'm sorry with a Japanese server)

I try it a little more in various ways.
Thanks

I'm using v1.03.0, 32bit and GAS backend. The variable 'comil_info' in the proc/var tab is getting the information, but the compile info dialog does not display it. The test code: dim as string compil_info="$$__COMPILINFO__$$"+__FB_VERSION__+"/"+__FB_BUILD_DATE__+"/"+__...

Not so hard ;-) Now position/size of the main window are saved when exiting and restored when restarting. Good job! the debugger found the own place to stay. I added the following code or your specified code into my source code, but I wasn't able to get the information. Is a way wrong? if so, It is...

Hi SARG,
It works without problems on my PC too, but I found a indication bug in `compile info`.
I wish that the debugger memorizes the position of the own window, if possible.

Thanks