OOP: If not now, when?
FB will always remain free, don't worry, the names says it all, the "Free" it's not only as in "freedom/libre" but as in "as-beer/gratis".
OO will be a bit easier to implement when the GCC frontend move is done, because then we can reused the GCC's mangling routines without too much trial-and-error attempts or taken non-official docs into account, and also reuse it's pre-made multi-platform exception handler.
Internally FB must follow the C++ ABI or nobody will be able to use any C++ libs compiled with GCC ever, unless somebody wrap them, what could take ages. Also because GDB (the debugger) is pretty dependent on the C++ ABI, not been able to debug OO applications would make it almost useless.
OO will be a bit easier to implement when the GCC frontend move is done, because then we can reused the GCC's mangling routines without too much trial-and-error attempts or taken non-official docs into account, and also reuse it's pre-made multi-platform exception handler.
Internally FB must follow the C++ ABI or nobody will be able to use any C++ libs compiled with GCC ever, unless somebody wrap them, what could take ages. Also because GDB (the debugger) is pretty dependent on the C++ ABI, not been able to debug OO applications would make it almost useless.
-
- Posts: 5494
- Joined: Sep 12, 2005 20:06
- Location: California
Well, integrating a 60K LOC project into a 400K one when both are completely procedural/imperative and when the official documentation is missing and the non-official one is outdated because the internal interfaces were completely changed and you have to hack yourself the other (not really commented) 100K LOC front-ends to find what should be done.. you get the picture.
The GCC's pseudo garbage-collector done on its tree nodes doesn't help either, a helper module written in C will be needed because of that.
But at least i won't have to deal with high-level optimizations that took one decade and thousands of testers to get done, neither write new emitters to other cpu's, there are dozen of them to use right now if the rtlib is ported too. Also cross-compilation will become easier, if you can stand waiting 50 minutes to GCC build itself 3 times :).
The GCC's pseudo garbage-collector done on its tree nodes doesn't help either, a helper module written in C will be needed because of that.
But at least i won't have to deal with high-level optimizations that took one decade and thousands of testers to get done, neither write new emitters to other cpu's, there are dozen of them to use right now if the rtlib is ported too. Also cross-compilation will become easier, if you can stand waiting 50 minutes to GCC build itself 3 times :).
Integrating OOP into fb would be really cool, but we should be patient and wait :)
Victors way will take longer than doing something like FB only OOP (something like in D, there the D classes aren't compatible to C++ classes, so they have to be wrapped), but we will really gain all the possibilities gcc offers (as far as I know, you can write for example something in freepascal, use the gcc frontend to compile it and use it with your C code, or even use it with your D code).
And if someone really can't wait, than someone could use/write a preprocessor, that uses fb's possibilities to simulate OOP. That means parsing your code and changing templates/classes & co. into normal basic code to compile. But the coder won't even notice this extra step. All the OOP stuff would be handled by the preprocessor.
Victors way will take longer than doing something like FB only OOP (something like in D, there the D classes aren't compatible to C++ classes, so they have to be wrapped), but we will really gain all the possibilities gcc offers (as far as I know, you can write for example something in freepascal, use the gcc frontend to compile it and use it with your C code, or even use it with your D code).
And if someone really can't wait, than someone could use/write a preprocessor, that uses fb's possibilities to simulate OOP. That means parsing your code and changing templates/classes & co. into normal basic code to compile. But the coder won't even notice this extra step. All the OOP stuff would be handled by the preprocessor.
FreeBasic and GCC
When FreeBasic is converted to use GCC, will Windows users have to download the GCC package?
Nope, the libraries, include files and external tools will still the same as now, just fbc.exe will be modified and yeah, it will be almost 9x bigger than now (about 4mb), but that's a small price to pay to be portable to dozen of different platforms and have optimizations that no other BASIC ever had - neither VB6 using the VC++ back-end.
english is not my native language, so i don't fully understand some things, so i want to clear them out.
if i'm getting the whole thing around FB and GCC, the coder will write a program using FB syntax and then FB will translate it, so it can be compiled with GCC.
am i right? if not, can someone tell me what's all this stuff around GCC?
if i'm getting the whole thing around FB and GCC, the coder will write a program using FB syntax and then FB will translate it, so it can be compiled with GCC.
am i right? if not, can someone tell me what's all this stuff around GCC?
-
- Posts: 775
- Joined: Jul 01, 2005 18:45