FreeBASIC and C++

[PaulSquires]

Hi everyone, this question has been nagging at me for some time. I have absolutely no problem at all with the C generated backend for FB and it allows us to leverage the optimizations of gcc. I routinely read posts here about how various libraries can not easily work with FB because it relies heavily on C++ classes.

My question: Why not make the FB backend output C++ instead of C in order to allow easier C++ interfacing? Also, maybe then the compiler can more easily be extended to tap into powerful C++ constructs like templates, etc?

I'd be interested about the communities thoughts on this? The power of C++ with the simplicity of BASIC.

(Before I'm told, I do know that there are other BASIC's out there that translate their syntax to C++ but I am heavily invested in FB and see this as a means to moving forward the language in a faster/easier fashion)

[angros47]

My question: Why not make the FB backend output C++ instead of C in order to allow easier C++ interfacing? Also, maybe then the compiler can more easily be extended to tap into powerful C++ constructs like templates, etc?

Try writing such a back end, and then we could check if it is useful or if it is a waste of time.

Seriously, this kind of question assumes that rewriting a large portion of the compiler just to see if it works better would be something done everyday

[PaulSquires]

Try writing such a back end, and then we could check if it is useful or if it is a waste of time.

Seriously, this kind of question assumes that rewriting a large portion of the compiler just to see if it works better would be something done everyday

Thanks.

[Imortis]

My question: Why not make the FB backend output C++ instead of C in order to allow easier C++ interfacing? Also, maybe then the compiler can more easily be extended to tap into powerful C++ constructs like templates, etc?

Try writing such a back end, and then we could check if it is useful or if it is a waste of time.

Seriously, this kind of question assumes that rewriting a large portion of the compiler just to see if it works better would be something done everyday

Having never looked at the backend code directly, I can neither confirm nor deny this line of reasoning. I was under the impression that the reason they did not just write FB as a C++ front end was because v1ct0r did not want to make FB reliant on C/C++ for output. I kind of agree with this philosophy. While it might be faster (debatable, really) to make a compiler that just outputs the C++ code we need and let C++ handle the exe generation, linking, etc, I prefer that we have a bit more autonomy than that. To be honest, I kind of feel like the C backend was a poor choice, since it does not work 100% with existing FB features (most notably to me, variadic functions). I may change my mind if it ever gets fixed so there are no restrictions.

[counting_pine]

I've not looked into it much, but my feeling is that FreeBASIC likes to keep a tight control on its code. So it decides how datatypes should be arranged internally, how objects are created/destroyed, etc. It has to do this so the GAS emitter will work.

If we wanted to add things like templates/exceptions to FB, it would be nice if we could just emit all the code as high-level C++, but it would mean FB would have to sacrifice a lot of knowledge/control about how things work internally, and that would be a big design change.

[marcov]

My question: Why not make the FB backend output C++ instead of C in order to allow easier C++ interfacing? Also, maybe then the compiler can more easily be extended to tap into powerful C++ constructs like templates, etc?

This is an often heard misconception about backends. A compiler must understand everything it does first, and only then generates code. So changing to a more powerful backend does not automatically add those features to the frontend or guarantees flawless interoperation.

And even if you fixed the frontend, the C++ backend also won't automatically give you flawless C++ interfacing (example: if FB "adds" something to classes, or instantiates them a special way for its own purposes. Then you still can't pass C++ classes to places that expect FB classes because the "extra" or special instantiation is missing etc etc)

Such issues take away the ability to make a FB a language in itself, and the backend possibilities would enormously limit you in defining the FB language, and in time will only make it a (very) thin shell over C++.

And then your powerusers will walk away because they get basically the same deal as with C++, with just a much smaller community.

The case of C (*) is slightly different, the used subset of C is fairly small, and equivalent to a fairly common abstraction of a procedural language. (and keep in mind even in this simple case, the exceptions like variable amount of parameters are known problems NOW in FB).

I agree a bit with Imortis here, but I think it can be resolved. The problem is not the work, but making hard choices instead of trying to patch it up in a way that retains the illusion of 1:1 mapping.

I would separate Basic level variadic parameters from C level variadic parameters, and treat that as separate constructs. And maybe not allow defining C level variadic functions in FB. (only FB level variadic parameters)

But with C those are the exceptions. Doing what you propose with C++ would make you find such issues at every turn.

I'd be interested about the communities thoughts on this? The power of C++ with the simplicity of BASIC.

So unless you really make Basic basically C++ with long keywords, this doesn't help much. And even then you can better work with a simple postprocessor rather than a full blown compiler.

(Before I'm told, I do know that there are other BASIC's out there that translate their syntax to C++ but I am heavily invested in FB and see this as a means to moving forward the language in a faster/easier fashion)

Exploiting more from a backend will invariable need to align the language to make this possible (so change FB to suit 1:1 translation to C++), so that would void your investments. You can't pile up random technologies and hope to keep them unchanged.

(*) Or something like Pascal. I wouldn't recommend it, but technically FPC as backend is equivalent. Less targets, slightly larger procedural abstraction

[PaulSquires]

Excellent answers - thanks guys. Makes a lot of sense now that I see it from those perspectives.

[St_W]

I don't know if you've aver looked into the GCC backend code or the intermediate C code generated by the C emitter - if not, I'd suggest to take a look if you're interested - you'll see that FB doesn't use a lot of features from the C compiler, but implements most features itself instead. For example FreeBasic enums are incompatible with C enums and the C emitter doesn't use C enums for representing FB enums. The same applies to many other features and most certainly would also apply to classes and templates. Thus, even if you use a C++ compiler as backend, its class and template features cannot be used for FreeBasic if we want to stay binary compatible with existing versions of FB and other emitters.

C++ compatibility is hard to do in general as there is no standardized ABI for C++. So if you need C++ compatibility you should compile everything with the same C++ compiler (and compiler version). In that situation it would be easier to just use C++ as your programming language.

[Munair]

I for one feel very comfortable with FB's C compatibility. It's ideal for Linux programming. ;-)