FreeBASIC 1.08 Development

For other topics related to the FreeBASIC project or its community.
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 13:47

I'm going to try and fit in some development discussion. I'll attempt to address some of this in next post.

caseih wrote:
coderJeff wrote:Another language that uses same strategy is D language, and they have decent write up of the reasoning behind the approach. Interfacing to C++.
Does this method allow D to access a fairly complicated class library like Qt? It would appear so, provided enough of the class definitions were translated. FB can call a C++ mangled function, but since it didn't know anything about C++ vtables last time I tried it, it couldn't handle any real C++ library where inheritance was used.

It would require way too much developer resources, but embedding both a C and C++ compiler (and preprocessor) into FB would be awesome. Then one could just include a C or C++ header file directly and have those symbols exposed to the FB program.


I've actually not much worked with D. What I was most interested in, was the author's motivations for doing some things different than c++. Even in the early years of fbc oop development, we were arriving at some design decisions on our own that parallelled some of the goals if D.

I feel I should mention marcov's contributions to this community. I'm not sure if he's even tried fb. It doesn't matter though because his remarks and comments are usually on point due some of the similar challenges and experiences with free pascal.
Juergen Kuehlwein
Posts: 270
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Oct 19, 2019 14:07

@Tourist Trap

from my part I'm only sensitive to the consistency of the syntax and behaviour of any possible new feature. If you can intuit what the feature could be, or how it should work, and say "this is how it has to be", then it will be a good addition. If it doesn't work as usual, or has a different logic compared to the surrounding stuff, and/or simply hurts the intuition, then it will seem to me bad addition.


Yes, i agree. I was speaking of basic features for general use, not every new addition must become part of the global namespace. But it should not be forbidden to add new key words to FB, just because it might raise a naming conflict in existing user code somewhere. If there is a substantial gain for the language, it should outweigh possible problems.


JK
marcov
Posts: 2793
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Oct 19, 2019 14:11

coderJeff wrote:
I feel I should mention marcov's contributions to this community. I'm not sure if he's even tried fb.


Not for production or so. I played with it for a while when helping someone on IRC with the first FB ports to FreeBSD (2008ish?).

I also look at source from time to time, like gfxlib during the "backend" thread (we have a "graph" dos left-over drawing library that is somewhat similar, but much less maintained) and the rest of the runtime during the "runtime in FB" thread, a subject that is also close to my heart (and actually was the subject of my first question about FB in 2005 or so)

My interests are like yours in the D case, what are the reasons behind certain decisions/course ?

It doesn't matter though because his remarks and comments are usually on point due some of the similar challenges and experiences with free pascal.


More with the native backends though, then with the gcc direction. That is further from my frame of reference, because FPC was earlier and the state of cygwin/mingw tooling less, that was simply not an option.
jj2007
Posts: 1260
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: FreeBASIC 1.08 Development

Postby jj2007 » Oct 19, 2019 14:44

coderJeff wrote:I can't figure out your objective presenting it this way.
Jeff,

I do not have any stakes here. I have my own Basic dialect, definitely not meant for public use (it's assembler), and I don't need FB.

But I have a lot of sympathy for FreeBasic. There is a lot of goodwill here, and a lot of enthusiasm. It hurts me that it is going down the drain, mainly because of the general trend saying Basic is bah! (over which we have no control), but also because of the confusion that gets created around this community's attempts to a) add C++ features, and b) make FB work with several IDEs and a dozen "toolchains". Which are all C/C++ compilers btw; once upon a time languages compiled themselves, or at least they were written in assembly.

Remember the "B" stands for "beginner". I am not exactly a beginner with my 35+ years of BASIC experience, but even I get seriously pi**ed off when, in order to compile a nice little snippet, I have to search the whole forum for finding the "right" version of the required header file, and afterwards I need to start a dialogue with the author and several other members to find out why it still throws cryptic error messages. It's a big mess. There is not even a universally accepted installer for Windows, including a universally accepted IDE.

IMO it would be a great advantage if FB could
- kick out all "toolchains" except one
- define an absolutely clear path structure defining non-ambiguously where FB.exe expects, relative to its own location, the various libraries and header files
- adopt one IDE (and I know this would hurt the authors of several other good IDEs)
- or adopt one default set of command line options that works with everything*).

Sorry to be so rude, but it's really a pity that FB risks to disappear, like so many other Basic dialects.

*) I see the objection "so how, for example, should the compiler know whether it's a console or a GUI application?". My IDE counts the number of keywords in the source that are console-specific and compares it to the GUI-specific ones. If that fails (on very rare occasions), you can override it with an option in the source, like 'OPT_Susy console. Never had a problem with that in the last ten years.
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 16:09

jj2007, I have much better idea where you coming from, thank-you.

To address a couple things specifically:
jj2007 wrote:the confusion that gets created around this community's attempts to a) add C++ features,

Not specifically C++ features, rather OOP features. I'll come back to this, and give explanation.

and b) make FB work with several IDEs and a dozen "toolchains". Which are all C/C++ compilers btw; once upon a time languages compiled themselves, or at least they were written in assembly.

It was always fb's intent to work on multiple platforms. So, yes, if interested in a particular target only, this looks like madness.

IMO it would be a great advantage if FB could
- kick out all "toolchains" except one
- define an absolutely clear path structure defining non-ambiguously where FB.exe expects, relative to its own location, the various libraries and header files
- adopt one IDE (and I know this would hurt the authors of several other good IDEs)
- or adopt one default set of command line options that works with everything*).

I feel this is constructive feed back. These are concrete goals that can build a case for, or discover the limitations of or conflicts with other goals.

I don't mind if anyone wants to take the initiative to discuss these items more. Maybe in a new topic? Or perhaps wait until this part of the discussion dies down and then continue in here?
marcov
Posts: 2793
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Oct 19, 2019 16:38

jj2007 wrote:- kick out all "toolchains" except one


Counterproductive. People that don't take part in development shouldn't tell people that actually do something to stop.

- define an absolutely clear path structure defining non-ambiguously where FB.exe expects, relative to its own location, the various libraries and header files


Fine. I would widen it to intermediate user documentation. How do I compile and install my own FB. This is important because the intermediate users are important for (1) testing with quality, detail feedback (2) the occasional patch (3) a stage between ordinary users and developers. A percentage might become devels one day.

Around 2007 I had the same issue with FPC. Many newer users wanted to take the next step, but lacked the resources. This was a problem because due to a relative slow release cycle people were reporting bugs for a version that was quite old. So I wrote this the FPC buildfaq to encourage new users to track development closer.

It also describes into detail how the compiler finds it files, something to keep in mind for the "default parameters" question further down.

- adopt one IDE (and I know this would hurt the authors of several other good IDEs)


Don't set anything in stone forever. That rewards short term thinking too much. Also the problem is that the most advanced IDEs are usually bound to one platform (and usually that means Windows).

But actually having a default option delivered with the installation might be a good thing. It gives the user the feeling of completeness. But I'd make it the choice per major development cycle per target. That is a better tradeoff between rewarding short term development goals (an usable IDE now) and long term. Targets are typically something like Dos, Windows, OS X and general *nix.

It took nearly ten years for the logic choice, lazarus, to become the actual default choice for users. (lazarus started 1998, and the bulk of the users migrated only in the 2005-2007 timeframe. Lazarus acquired a win32 native GUI in late 2003, and that was only released formally in 2005, before it was GTK only, this was probably a large part of the shift in user preferences)

- or adopt one default set of command line options that works with everything*).


We use a configuration file, written by the (platform specific) installer. If you don't want the compiler to be soiled by state, consider a frontend binary that does this (reading the configfile with parameters and then call the real compiler).

I see the objection "so how, for example, should the compiler know whether it's a console or a GUI application?". My IDE counts the number of keywords in the source that are console-specific and compares it to the GUI-specific ones. If that fails (on very rare occasions), you can override it with an option in the source, like 'OPT_Susy console. Never had a problem with that in the last ten years.


The problem is that the console vs gui is not a black-white difference. Even on Windows GUI apps can open consoles. Basically on Windows you can "just" set a bit to not open a console. You can even start as a console app, and then become gui only. Vice versa (first gui and then console) is more difficult, since the terminal would be only temporary (*)

On *nix, the apps themselves must actively close the console to become "gui only". But many just leave the console open for debug output (with the proper switch)

(*) note to self. Make some examples of such apps.
jj2007
Posts: 1260
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: FreeBASIC 1.08 Development

Postby jj2007 » Oct 19, 2019 16:52

coderJeff wrote:It was always fb's intent to work on multiple platforms. So, yes, if interested in a particular target only, this looks like madness.
This is indeed a challenge, I understand that. Windows is difficult enough, Linux with its multiple flavours must be worse (I've never tried "it" seriously).

On top of my wishlist:
- clear folder structure as mentioned above
- an installer that puts FB into this folder structure
- get rid of command line options as much as possible (i.e. let the FB compiler autodetect what are good options to be passed to the C/C++ compiler)
- if such autodetect fails, a #pragma equivalent to put options into the source, so that a member who copies a source from this forum can compile it independently of the IDE he uses; ideally, in 99% of all cases fbc.exe somefile.bas should work out of the box
- one sticky post in this forum that contains a few dozen links to the latest version of any library, header file etc posted by members
jj2007
Posts: 1260
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: FreeBASIC 1.08 Development

Postby jj2007 » Oct 19, 2019 17:10

marcov wrote:It took nearly ten years for the logic choice, lazarus, to become the actual default choice for users
What is Lazarus?
The problem is that the console vs gui is not a black-white difference. Even on Windows GUI apps can open consoles.
Yes. Most of my GUI apps use -subsystem:console until they have matured. On Windows, the only real problems are 1. console applications that contain commands asking for a keypress and get erroneously compiled as GUI (they hang), and 2. console apps that print something and get erroneously compiled as GUI (they apparently do nothing, and that can be very frustrating for a beginner). But on Windows at least, autodetecting is not difficult, and an override option in the source can be helpful in certain cases. If the compiler's autodetector sees ambiguity, a warning may be useful.
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 17:23

To get an understanding of current development it may be helpful to know (review) what has already been done to get a perspective on where we are now.

1) QB Roots
Undoubtedly the look and feel of the language is based on QB. In attempt to accommodate the spectrum of users, this has evolved in to 3 dialects
- QB
- FBLITE
- FB
Each has their advantages and disadvantages.

2) FreeBASIC on multiple platforms
An overall goal of the project, from the beginning is cross platform availability. And wherever possible, cross platform compatibility. Source code compiled for multiple targets should have the same results. Not always possible, and we try to document the differences.

3) Not inventing everything from scratch
From early days to now, fbc uses tools we did not create ourselves:
- gnu AS - assembler
- gnu LD - linker
- gnu AR - static libraries
- gnu GROF - profiler
- gnu GDB - debugger
- gnu DLLTOOL - shared libraries
- GoRC - resource compiler
- a C runtime for low level interface to the system

For the 3 "main" targets win/linux/dos, we are tied to binutils, and the c runtime for that target.

On one hand, we are at the mercy of others when it comes to using these tools which presents it's own challenges. On the other we do not need to spend resources developing and maintaining all these tools. And it also allows us to achieve cross platform availability.

Design decision was to use gnu AS (32 bit code) and related tools, and not worry about any other, like MASM, NASM, FASM, and any of their related tools. In theory, it's possible to write an emitter (or modify the existing one) for multiple assemblers, but it would take significant amount of dedication from an interested developer.

4) Using GCC to get 64-bit and other architectures
The choice here was either, a) write new assembler emitter from scratch to add one more target. Or b) write an architecture independent assembler of sorts from scratch, Or c) write a C emitter from scratch utilizing gcc's multiple platform availability.

Obviously, gcc then becomes a dependency of the project which presents challenges, like not all same gcc versions available on all targets. However, not a tool we need to maintain.

gcc is used like an assembler. No human would generate the C code that fbc feeds to gcc. The C code lets gcc generate the appropriate platform specific assembler, and that's about it.

5) LLVM, emscripten, and other emitters.
I don't know enough about these targets to comment. The general idea though, is to make fbc available on additional targets.

To be continued...
Juergen Kuehlwein
Posts: 270
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Oct 19, 2019 17:31

I partially second jj2007´s wishlist

- a clear (and documented) folder structure
- i don´t need an installer, but one zip file containing everything in place, including the preferred gcc toolchain (32 and 64 bit)
- a means for having command line options inside the soure code (i did that for my own IDE too)
- more and more specific error messages, sometimes it´s really hard to understand what´s wrong

There is much more on my list, but this is what would i missed most when starting with FB


JK
angros47
Posts: 1535
Joined: Jun 21, 2005 19:04

Re: FreeBASIC 1.08 Development

Postby angros47 » Oct 19, 2019 17:59

A lot of people here have a lot of ideas and suggestions to improve FreeBasic. I have a message for all of them: please, stop talking about your ideas, and start coding them!

We aren't short of people with "ideas". We need people able to implement them. I have suggested for years to add the support to openGL in the graphic library, no one paid attention. When I did the work myself, I found a lot of help in testing it, and in integrating it with the next version. Same happened with OpenB3D: when I tried to involve people in a team job, to port it from BlitzMax to FreeBasic, several people liked the idea, but no one did anything to help. After I ported it, I got some people to submit patches and bugfixes.

FreeBasic is free software: not free beer. If anyone thinks they could just ask for a feature, or a change, and have it implemented for free, no, sorry, it's not how it works. It works more like wikipedia: you want something? You make the necessary changes.
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 19:16

Continuing...

6) Bindings for C libraries and shared libaries (DLL)
With fb's runtime written in C and dependent on C run time library for support, it is necessary that fbc be able to generate code that can bind (link) to C libraries. And with possibility for shared libraries, the binding must follow the system's standard. There is no inventing our own format here.

So naturally, a lot of effort went in to making fbc compatible with C calling conventions and shared library calling conventions at the binary level which was absolutely required just to get fbc to work.

7) Namespaces, Function Overloading, Types with methods, constructors, etc.
For all these features to work, same named symbols in fbc source need to be differently named at the binary level. What is often referred to as name decoration or name mangling. If I remember correctly, in the early days, I think there was some experimenting with custom naming schemes. Sometimes it didn't work out too well and would get duplicate definitions at link time.

Choice is either to design (invent) our own naming scheme and calling conventions, or use some existing standard.

This is where the Itanium C++ ABI comes in. Regardless of how fbc implements features at the source level, we follow this standard at the binary level. We can still create fbc specific features that follow the standard yet may not have an equivalently expressible construct in c++.

As far as fbc code compilation goes:
- asm in gas emitter
- C code in gcc emitter (using gcc as a high level assembler)
- fbc does not generate c++ code and does not invoke g++

8) Binding to c++ (gnu g++) libraries
Where the OOP features of fbc and OOP features of c++ are similar in concept, there is the potential that fbc can bind directly to c++ libraries. And a good way of testing if fbc is following the c++ ABI standard correctly, is to write tests that try binding to c++ generated code.

There is no guarantee or intent that there be an equivalent mapping of every feature between the 2 languages. But, by following the C++ ABI we have a pretty good chance that we won't conflict with our own future development, and as a nice to have feature, we can directly bind some c++ libraries.

---
I'm almost to the point where can discuss current issues and some stuff I've been working on.
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 19:32

caseih wrote:FB can call a C++ mangled function, but since it didn't know anything about C++ vtables last time I tried it, it couldn't handle any real C++ library where inheritance was used.


I think so: for single inheritance only. I haven't tested it much. Here's an example that calls a derived method though a base pointer on both the fbc side and g++ side. Have no idea how well data layouts hold up on various compilers. 64-bit only since 32-bit, at least on windows requires thiscall calling convention, which fbc does not have (more on that next post).

c++ library, compile with 'g++ -c cxx.cpp -fno-rtti'.

Code: Select all

class A
{
   public:
   virtual int func( int x, int y );
};

int A::func( int x, int y )
{
   return x + y;
}

class B : A
{
   public:
   int func( int x, int y );
};

int B::func( int x, int y )
{
   return x * y;
}

int proc( A *obj, int x, int y )
{
   return obj->func( x, y );
}


basic main program, compile with 'fbc-64 main.bas cxx.o'

Code: Select all

extern "c++"
   type A extends object
      declare virtual function func( x as long, y as long ) as long
   end type
   
   type B extends A
      declare virtual function func( x as long, y as long ) as long
   end type

   declare function proc( byval obj as A ptr, x as long, y as long ) as long
end extern

dim x as A ptr = new A
dim y as B ptr = new B
dim z as A ptr = y

print x->func(3,4)
print y->func(3,4)
print z->func(3,4)

print proc( x, 3, 4 )
print proc( y, 3, 4  )
print proc( z, 3, 4  )

delete x
delete y
angros47
Posts: 1535
Joined: Jun 21, 2005 19:04

Re: FreeBASIC 1.08 Development

Postby angros47 » Oct 19, 2019 19:44

Last time I tried, some versions ago, with OpenB3D, FreeBasic was able to call the methods from a C++ class in a DLL. I was trying to build a set of include files to be able to use OpenB3D directly, and not through wrapper. A missing feature was the total incompatibility with C++ strings (if a C++ function accepts a string as a char*, FreeBasic can pass it as a zstring ptr, but if the string is a string class, there is no solution
angros47
Posts: 1535
Joined: Jun 21, 2005 19:04

Re: FreeBASIC 1.08 Development

Postby angros47 » Oct 19, 2019 22:05

Also, I have a question for coderJeff: any plan for generics?

In case, how would syntax be? I saw how it is in RapidQ:
http://macosa.dima.unige.it/om/prg/guidarq/chapter10.html#108

Code: Select all

    TYPE NewClass<DataType> EXTENDS QOBJECT
        N AS DataType
    END TYPE

    DIM MyClass1 AS NewClass<INTEGER>
    DIM MyClass2 AS NewClass<STRING>


and it looks pretty intuitive, more than in C++

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest