FreeBASIC 1.08 Development

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

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 23:00

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


There is this work that v1ctor did early 2018: https://github.com/freebasic/fbc/pull/69
I just haven't had time to go through it. I regularly rebase it on current master, though.

It has an example of a generic list. Even though it's only with macros, it does form a kind of concept or skeleton for a generics feature. The compiler needs to help it along more to make the usage more natural.

I notice on the forum how users are creating pseudo-generics/templates with #macros. However, they are often convoluted and fragile. I have no specific plans for generics in the works, but I'm not against it either.
coderJeff
Site Admin
Posts: 3343
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 19, 2019 23:49

Continuing my ramblings on bindings and stuff...

In case everything else I posted is TLDR;
- fbc can natively bind to C code and some C++ code
- fbc follows itanium C++ ABI where possible
- fbc feeds asm to gnu assembler
- fbc feeds C code to gcc (using gcc like as high level assembler).

So here's the chain of events that bring me to working on C++ bindings:

1) While working on JK's ustring stuff, I still have general issues with this added ustring.bi + tests #161. If someone asks, I will explain more.

2) More specifically was the LEN() overload. which got mentioned in this thread: Len() can't be 'overloaded'

3) Which led to these 2 bug reports:
#903 Operator cannot be a member function (TODO)
#902 Overloaded operators do not respect namespace

4) I thought #903 would be pretty quick to deal with and started a PR:
fbc: add static operator to user defined types #149

5) At which point, I started to test how well our ABI follows itanium C++ ABI and realized that on 32-bit windows, we don't have "thiscall" calling convention. So I started working on "thiscall" calling convention and writing more ABI tests.

6) So I got a pretty decent amount of this finished, but still have some challenges left to resolve. There's quite a few things that work correct with the ABI with respect to c++, and a few things that don't.

7) I was also trying to collect information for this topic Hello fxm :-) => for updating the ASM documentation page on wiki. Which has a decent amount of info but is missing loads, like returning TYPEs (structs) from functions, hidden parameters, and so-on.

----
So what does this have to do with old/new users, beginners, average users, etc?
Absolutely nothing ... in the short term.
In the long term, stability, I'm fairly confident.

Probably not interesting or exciting to anybody but me.

OK, I'm done expanding this train of thought on my own. Can still ask any questions though. Especially if I totally missed an important user remark somewhere.

So while following c++ abi is not required for fbc's development right now. I'm in a position to at least attempt to get it correct right now. Might open some doors down the road in the unforeseen future. Don't know until we get there.
marcov
Posts: 3020
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Oct 20, 2019 9:38

I, for a while, had some code that could plain C wrappers from C++ classes for use at work. (Delphi), but as more and more of the SDKs I used(*) dropped plain C compatibility, I ran into the same thing as Angros47. Very few C++ classes that only use plain C types and other classes as arguments and returnvalues. Strings, templates etc.

Once they dropped C compatibility, usually the C++ interfaces also started to use more and more STL, templates etc.

(*) I'm doing machine vision, so these were mostly industrial camera interfacing SDKs.
Last edited by marcov on Oct 20, 2019 11:06, edited 1 time in total.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Oct 20, 2019 10:35

So to summarize this (if i got it right), it´s not about making FB a C++ clone, it´s about enabling FB to link to C++ libraries too, which more and more are becoming standard over plain C libraries.

Making FB more C++ compatible is beyond my expertise, but for sure, if a language doesn´t keep up with modern standards, it will die.

While working on JK's ustring stuff, I still have general issues with this added ustring.bi + tests #161. If someone asks, I will explain more


i´m asking right now :-)


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

Re: FreeBASIC 1.08 Development

Postby marcov » Oct 20, 2019 11:09

Juergen Kuehlwein wrote:So to summarize this (if i got it right), it´s not about making FB a C++ clone, it´s about enabling FB to link to C++ libraries too, which more and more are becoming standard over plain C libraries.


Concretely it is about calling C++ methods. Maybe constructors/destructors too (IOW instantiating C++ objects, and/or using the in a RAII manner)

Making FB more C++ compatible is beyond my expertise, but for sure, if a language doesn´t keep up with modern standards, it will die.


These are not standards. Every library creator can do something else, so contrary to plain C (*), the result is not universal. So it is just opinion where it is heading.

And while I also see the trend towards increasing C++ and decreasing C interfaces, the resulting C++ interfaces are rarely simply an OO form of C. But I mostly interface commercial, not Open Source software.

(*) well non trivial C macros are very hard to automatically interface. So C is not universally usable from other languages too. But better than C++.
coderJeff
Site Admin
Posts: 3343
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 20, 2019 11:23

Yes, we are not making a c++ clone. Where there is a same construct between fbc & c++, I am attempting to make those binary compatible and write unit tests for it. By following a standard(*) I'd like to allow future expansion on bindings. I'm not working to create full compatibility since it is not needed for other fbc growth. Also, I'm not limiting fbc's growth to only what c++ can support; for example, c++ has some weird rules about what you can and can't do with overloaded operators, but I can see in fbc that we can unambiguously resolve usage, so fbc will have some operator overloading features available that are independent of c++. In other words, it's not a primary goal to interface directly to c++, but I don't want to throw the possibility away if it isn't conflicting with other project goals.

(*) yeah, "standard" is whatever species of alien c++ compiler trying to work with.
angros47
Posts: 1755
Joined: Jun 21, 2005 19:04

Re: FreeBASIC 1.08 Development

Postby angros47 » Oct 20, 2019 12:00

The interesting thing is that FreeBasic strings are closer to C++ strings than to C strings (a descriptor that holds data about the string size and its address). Still, there is no way to FreeBasic and C++ to "talk" without using the older, and less powerful format of zero terminated strings.

I wonder... is there a "standard" format for c++ strings, or each compiler does it in its own way? (like... can GNU C++ pass a string to a library compiled in Microsoft C++?)
coderJeff
Site Admin
Posts: 3343
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 20, 2019 12:34

coderjeff wrote:I still have general issues with this added ustring.bi + tests #161

Yes, I'd like to finish this PR off; it's fairly close to the top of my todo list to get this finished and merged in.

Originally, the 'ustring.bi' was pretty much copy+paste from Jose's WinFBX followed by some hack+slash. It might be in use for quite a while so I think it is worth taking it's development as far as is reasonably possible before formally adopting it's use, rather than just throwing it out there because it "works".

I think need to explore what this thing is and why we are adding it:
- probably a long time before var-len wstring is natively supported by fbc
- would be helpful to users to have an equivalent even if implemented as an #include
- would help development in other areas of var-len wstring support
- we are not building a framework or data type system

What we want here is a place holder that will work a lot like a native var-len wstring would work. Which for symmetry, should likely have many similar characteristics as already existing STRING:
- minimal field: data, length, size
- null descriptor if no string is allocated
- fixed growth rate (STRING uses 12.5%)
- similar operations allowed or restricted as STRING
- declaration separate from implementation (especially if supporting code is large)

As is 'ustring.bi' has these extra characteristics:
- pre-allocates 260 bytes, even for empty strings
- growth rate field is stored with every string
- implicit conversion construction like 'dim x as ustring = 1'
- executable code in the include (duplicates code in multi-module compilations)
- the actual type is FB_USTRING.DWSTR, but has `#define ustring FB_USTRING.DWSTR` indirection
- overloads CAST() AS ANY PTR allowing ustring to be passed to any pointer type without warning/error.
- no awareness of CONST qualifiers

I'd kind of like to get 'ustring.bi' down to just the minimum needed. Simple use, easy to maintain & document, etc.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Oct 20, 2019 13:38

Ok, let´s make it clone of the STRING type as far as possible!

I don´t insist on a default of 260 bytes (260 bytes = %Max_Path in Windows) seems a reasonable choice and more allocated memory means less time consuming reallocate and copy oprations. It´s the usual tradeoff between space and speed. If you have another/better preference - just do it.

"Growsize" is a private member currently and could be dropped in favor of a hardcoded value - no problem

implicit conversion construction ( 'dim x as ustring = 1'): not absolutely necessary, but handy (instead of 'dim x as ustring = wstr(1)'). It doesn´t do any harm in my view, but could be dropped too (STRING doesn´t accept this syntax either).

duplicates code in multi-module compilations: i don´t see how this can be avoided, except putting it to the RTL (and this effort is, what we definitly wanted to avoid). On the other hand returning wstrings (this is what we currently do) we cannot have embedded nulls in wide strings (with STRINGs we can), this is a (maybe acceptable) inconsistency.

ustring indirection: this is absolutly necessary in my view for possible later changes (what we currently have is maybe not something, which will stay forever. We know, what we would have to do to fix it for good, but we fear the effort). If people code "FB_USTRING.DWSTR" and there is actually an intrinsic wide string type coming, there will be (justified) complains. With this indirection ("USTRING"), you will be able to change the define under the hood, and you will have a good chance most users won´t even notice it.
... and "USTRING" much more conforms to the existing naming convention (STRING, ZSTRING, WSTRING), much more than "FB_USTRING.DWSTR"

Any Ptr: actually there was a discussion with José about this and he said, it wouldn´t work in some cases, if you dropped it. I tried myself and could verify this. But then i didn´t investigate any further why and maybe how to make "any ptr" obsolete. Sorry i´m currently of no help here.

Const qualifiers: to be honest, i understand the concept, but i didn´t need or miss it the last 40 years of BASIC programming. It may be of help in certain situations , it may make code easier to read and understand, it may help to write better (less errors) code, but it may be a nuisance for a (FB) developer too to make it work under all circumstances. There are still other areas, where this doen´t work as expected, as far as i know. I´m of no help here either. Maybe a warning in the documentation? "Don´t rely on the const qualifier when using USTRINGs, there are cases, where "const" doesn´t work as expected"


JK
coderJeff
Site Admin
Posts: 3343
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Oct 20, 2019 14:18

Juergen Kuehlwein wrote:ustring indirection: this is absolutly necessary in my view for possible later changes (what we currently have is maybe not something, which will stay forever. We know, what we would have to do to fix it for good, but we fear the effort). If people code "FB_USTRING.DWSTR" and there is actually an intrinsic wide string type coming, there will be (justified) complains. With this indirection ("USTRING"), you will be able to change the define under the hood, and you will have a good chance most users won´t even notice it.
... and "USTRING" much more conforms to the existing naming convention (STRING, ZSTRING, WSTRING), much more than "FB_USTRING.DWSTR"

I understand. That means that "USTRING" is a placeholder for fbc's var-len wstring data type in the future. Which means that "USTRING" eventually will be become reserved word. That's an important choice to get correct right now. It will likely be in use forever.

from unicode variable length string type?:
dkl wrote:1. The name "WString" is already used for null-terminated wstrings. We need a new name for wstring descriptors, to be able to differentiate between descriptor and string data. In case of String/ZString, we have String=descriptor, ZString=string data. It needs to be UString or DWString or something like that...


So, I'd probably recommend TYPE USTRING AS FB.DWSTRING instead of the #define
- USTRING maps to FB.DWSTRING now, but an internal built-in type later
- FB.DWSTRING also remains available later, in case users decide to extend the object, add their own features etc.

By introducing USTRING as an #include it give users some time to know that it will become a reserved word in future without immediately breaking any of their code now.

Because, eventually, we will break some user code, I found this existing usage of USTRING usage on this forum:
ustring: Dynamic zstring library.
caseih
Posts: 1562
Joined: Feb 26, 2007 5:32

Re: FreeBASIC 1.08 Development

Postby caseih » Oct 20, 2019 14:57

I think allocating memory for even an empty ustring is just fine. Might even be desired when interacting with C-based APIs, or win32 API calls.

I know FB string does not allocate memory for an empty string and I've always felt this was a bug, since it leads to passing NULL pointers to C APIs expecting char *. In other words in interacting with other languages, it is not a normal convention to have a NULL pointer represent a zero-length string. So a bit of an impedance mismatch there. I can think of no problems to any existing FB code if the empty string representation was changed in some future version of the FB runtime.
Juergen Kuehlwein
Posts: 284
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Oct 20, 2019 15:02

I understand. That means that "USTRING" is a placeholder for fbc's var-len wstring data type in the future. Which means that "USTRING" eventually will be become reserved word

Yes! This is what i wanted you understand all the time. (maybe my fault: language problems, not my native tongue, wording, ...) "USTRING" is perfect, "DWSTRING" should be avoided, because it is used in the compiler´s code.

... eventually, we will break some user code ...

From your other post:
Whatever I accept, someone will be disappointed

In Germany there is a saying: if you want scrambled eggs, you must break an egg


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

Re: FreeBASIC 1.08 Development

Postby angros47 » Oct 20, 2019 15:09

I have read more about the coroutines, and the recent implementation in C++. So far, they seem something that can be easily done with setjmp and longjmp... am I missing something? What does the recent implementation in C++ do, to make them easier/more practical to use?
caseih
Posts: 1562
Joined: Feb 26, 2007 5:32

Re: FreeBASIC 1.08 Development

Postby caseih » Oct 20, 2019 15:19

@angros47, perhaps we should start a new topic for this.
Josep Roca
Posts: 501
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: FreeBASIC 1.08 Development

Postby Josep Roca » Oct 20, 2019 15:28

Because, eventually, we will break some user code, I found this existing usage of USTRING usage on this forum:
ustring: Dynamic zstring library.


Now you will understand why I did use CWSTR for my class. I was almost certain that it will never be used as a keyword :)

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 7 guests