FLTK headers for FreeBasic OOP (no C wrapper)

[angros47]

Looks like you were right....

Code: Select all

#inclib "stdc++"
#inclib "fltk"
#inclib "fltk_forms"



extern "c++"
type Fl extends object
	declare static function run_ alias "run"() as double
end type


type Fl_Group  extends object
	dummy(1000) as byte
	declare sub end_ __thiscall alias "end" ()
end type

type Fl_Window  extends Fl_Group
	declare constructor __thiscall(w as long, h as long, title as const zstring ptr)

	declare virtual destructor __thiscall

 	declare sub show __thiscall(argc as long, argv as zstring ptr ptr)

end type
end extern


dim w as Fl_Window = Fl_Window(940,380,"test")
w.end_()

w.show(0,0)
fl.run_()

This seems to work under Win32.

Now, I have a question: do I have to add "thiscall" to every single line, at this point, or is there a simpler solution? Like, a setting to specify that "thiscall" has to be the default calling convention?

[coderJeff]

Now, I have a question: do I have to add "thiscall" to every single line, at this point, or is there a simpler solution? Like, a setting to specify that "thiscall" has to be the default calling convention?

ha, I totally knew that would be your next question.

yes, as it is now, __thiscall needs to be explicitly given everywhere it is needed. Mainly because it was an unfinished feature (and will remain so unless x86 gas emitter is improved), and my trivial tests while working on it are nothing compared real use cases by users. Feedback is important.

My intent was that after getting feedback that '__thiscall' basically works, was to make it default for extern "c++" / win32 / x86 / non-static member procedures. And, if it does break binary compatibility for any users, they can give '#cmdline "-z no-thiscall"' to completely disable the thiscall calling convention.

Let me see what I can do.

[angros47]

So, if I understand, as soon as it will work the code I have already written would be able to work under Windows 32 bit with no issues?

Because in such a case, I won't modify it to add the thiscall to every line (there are thousands of them, and it would make the source code uglier, harder to understand and to maintain, and more prone to bug), since I would have to remove it soon anyway. For now, test the example I have just sent you (and I invite D.J.Peters to do the same), and consider it my first feedback about it

In these years I have kept asking you for unsupported features, and I impressed at how much support you provided. But I am glad to see how FreeBasic has grown, and how much has become possible now. I hope that soon the FLTK header could be included in the FreeBasic headers: in the past, many users have stated how FreeBasic would need an official GUI library, and I still think that FLTK would be a good candidate, because it's the only library that works on every platform (DOS included)

[coderJeff]

So, if I understand, as soon as it will work the code I have already written would be able to work under Windows 32 bit with no issues?

In theory, no issues. I have researched the thiscall calling convention many times, but it's always confusing to me; either the explanation is incomplete or it is just poorly written, idk. I find that I have to run lots of little test cases through disassembly just to figure out what's going on under the hood. I may miss some edge cases. I haven't investigated our handling of fb's built-in OBJECT or RTTI yet, so could be some surprises there.

The goal is that ideally your code stays the same without any funky #define's and it just works for all the targets (with some limitations like -gen gas, etc).

[angros47]

Well, then, do you think it's time to give it a test run, enabling __thiscall by default, to see what happens with the fltk header?

Also, it is just my personal opinion, but I have the impression that the ABI support for OOP under windows is poor (or at least poorly documented) because Microsoft planned to use the OLE/COM interface, instead of it, to use OOP libraries from different languages.
The OLE/COM technology allowed to build an OOP interface pretty quickly, but at the price of requiring the system registry, to keep trace of the different classes and their interfaces.

[marcov]

I have the impression that the ABI support for OOP under windows is poor (or at least poorly documented) because Microsoft planned to use the OLE/COM interface, instead of it, to use OOP libraries from different languages.

There is no such thing as an universal ABI for OOP under Windows. E.g. gcc derivates had their own ABI, different from VS, and different again from BCB.

Also exporting massive amounts of symbols is a drain on the runtime linker. (KDE had problems with this in the passed, implementing a prelink system, and Windows also only has prelink system since Windows XP)

[coderJeff]

Well, then, do you think it's time to give it a test run, enabling __thiscall by default, to see what happens with the fltk header?

ok, I've pushed changes to fbc/master.
I tested your headers (unmodified) with a simple example I found on this thread on win32 x86 ... and it didn't crash.
Excitement?

I will probably post more details and usage about __thiscall in New Page __THISCALL

Briefly:
- __thiscall is enabled by default for extern "c++" / win32 / x86 / non-static member procedures.
- can now also define procedures in fbc with the __thiscall calling convention (not just declare & call as before - I added the missing code generation to gas backend).
- you will have an easier time if the procedure declaration and definition are both inside extern "c++" blocks (so the default __thiscall will be used)

aw, that cleared up a few long standing TODO's of mine (but also identified a few more which I added to the project todo.txt)

[fxm]

- can now also define procedures in fbc with the __thiscall calling convention (not just declare & call as before - I added the missing code generation to gas backend).

_thiscall must be only used at the member procedure declaration level, or also at the member procedure definition level if it exists ?

[angros47]

That's a great news! Did you manage to get a window to appear?

Since some headers already include the "alias" for char (that is supported only in 1.10), maybe I should soon drop compatibility for version 1,09, and make the headers support only version 1.10 or later (this would mean using the nested TYPEs, for example)

I have the impression that with my attempts to port the headers to FreeBasic I have used some w.i.p. features not supposed to be ready, yet, and I have exposed some issues.

Thank you for your constant support

[coderJeff]

That's a great news! Did you manage to get a window to appear?

I did get a window to appear; with a button. I could test a more complex example if you have one.

If it were up to me, I'd like you to just go for the new features and find out where fbc 1.10.0 breaks. That helps me prioritize the next effort, and also some real testing that I would likely never do. Often, the tests that I write are trivial and specific compared to the code that users want to write. There is some work still to be done on nested named types and __thiscall features, but I think the main parts in place.

[angros47]

Is a building of the last version available for download?

[angros47]

I did get a window to appear; with a button. I could test a more complex example if you have one.

Try this:

Code: Select all

#include once "Fl_Window.bi"
#include once "Fl_Button.bi"
#include once "Fl_Menu_Bar.bi"
#include once "Fl_Text_Editor.bi"

'private constructor Fl_Menu_Bar (x as long, y as long, w as long, h as long, l as const zstring ptr)
'	base(x,y,w,h,l)
'end constructor

dim w as Fl_Window = Fl_Window(440,380,"Window")
	dim b as Fl_button = Fl_button(10,30,150,30,"This is a button")
	dim Menu as Fl_Menu_Bar = Fl_Menu_Bar(0, 0, 440,20)
	Menu.add "File/New"
	Menu.add "File/Open"
	dim t as Fl_Text_Buffer ptr= new Fl_text_buffer()
	dim text as Fl_Text_Editor=Fl_Text_Editor(180,30,250,300)
	text.buffer(t)
w.end_()

w.show


fl.run_

The commented lines are needed in the DOS version, and not in the Linux version, so I am not sure if they are needed in the Win32 version, in case, just uncomment them

[coderJeff]

Try this:

That's perfect, thanks.

I originally wrote the new win32/x86 calling convention inside extern "c++" so that:
- default for non-static procedure is __thiscall
- default for static procedure is cdecl
- and would recommend putting both declaration and definition inside the extern "c++" block.
And,
- 'static' on the declaration is obligatory (as before)

But, I see I've got some work to do to make this a little more use friendly:
- 'static' on the definition should be optional, but the logic I wrote for '__thiscall' isn't matching up, even if the definition is inside the extern "c++"
- I'm now contemplating if I should try and make the 'static/non-static' and 'cdecl/__thiscall' just auto-magically work regardless if the definition is inside or outside the extern "c++" by just implicitly following the declaration (both static and call convention).

[coderJeff]

But, I see I've got some work to do to make this a little more use friendly:

I made some changes to how fbc handles default calling conventions (which I hope is a general improvement to fbc overall).

On win32 -gen gas using latest fbc as of 2022-10-30

[angros47]

Great!