Could someone make a list of FreeBASIC GUI libraries/frameworks?

[Munair]

FreeBASIC would be greatly improved if it would allow object instantiation, just as FreePascal and other languages:

Code: Select all

type MyType
  ...
end type

dim mt as MyType ' only type association

mt = new MyType(10) ' fire constructors etc...
if mt <> nil then
  ...
end if

And please don't come with hacks and 'workarounds' to demonstrate it can. The problem is that FreeBASIC intentionally does not allow NULL pointers, as CoderJeff explained in an earlier discussion, according to him "pointers should always point to something." It simply means that FreeBASIC isn't equipped to do things like that, which puts advanced GUI development out of reach.

The "type extends object" construct is more like a work-around itself and should have been implemented with the keyword "class" instead IMO to distinguish between 'normal' types and class objects.

[dodicat]

Munair
Most languages require you to initialize a variable, fb sets a default, but defaults can be overridden with any.

Code: Select all

type udt extends object
  as long x,y,z
  declare constructor
  declare constructor(as long,as long,as long)
end type

constructor udt
print __function__
y=100
end constructor

constructor udt(xx as long,yy as long,zz as long)
print __function__
x=xx
y=yy
z=zz
end constructor



dim as udt x=any  ''' only type association

print x.x,x.y,x.z  ''' get duff values, no good to anybody.(as in c, pascal . . .
print "Press a key . . ."
sleep

'initialize either way.
x=udt
'x.constructor

print x.x,x.y,x.z
print "Press a key . . ."
sleep
x=udt(1,2,3)
print x.x,x.y,x.z
sleep

 
 

[paul doe]

...
And please don't come with hacks and 'workarounds' to demonstrate it can. The problem is that FreeBASIC intentionally does not allow NULL pointers, as CoderJeff explained in an earlier discussion, according to him "pointers should always point to something." It simply means that FreeBASIC isn't equipped to do things like that, which puts advanced GUI development out of reach.
...

It seems to me that you're confusing a pointer with a reference. FreeBasic does allow null pointers, what it doesn't allow is null references (as understood by, say, Visual Basic or Java; hence the dim byref weirdness). In that sense, 'classes' work more akin to C++ than to the aforementioned languages. To change it now would imply a complete redoing of the the typing mechanism (and of course the need to implement proper garbage collection).

The most irritating aspect of FreeBasic for me would be the lack of proper interfaces, and a way to express which interfaces a class implements. Say:

Code: Select all

interface _
  Foo
  
  declare sub _
    someOp()
end interface

interface _
  Bar
  
  declare sub _
    anotherOp()
end interface

class _
  FooBar extends SomethingElse
  
  implements _
    Foo, Bar
  
  /'
    Constructors, destructors, et al
  '/
end class

[Munair]

...
And please don't come with hacks and 'workarounds' to demonstrate it can. The problem is that FreeBASIC intentionally does not allow NULL pointers, as CoderJeff explained in an earlier discussion, according to him "pointers should always point to something." It simply means that FreeBASIC isn't equipped to do things like that, which puts advanced GUI development out of reach.
...

It seems to me that you're confusing a pointer with a reference. FreeBasic does allow null pointers, what it doesn't allow is null references (hence the dim byref weirdness). In that sense, is more akin to C++ than to, say, Visual Basic or Java. To change it now would imply a complete redoing of the the typing mechanism (and of course the need to implement proper garbage collection). Not that it cannot be done, but the devs implied before that they want to do things differently.

Well perhaps I should have said "null reference", but the line is thin and basically another name for the same thing (something that points to something). So from a FB perspective - the way pointers and references are handled - yes, they are 'different'. Unfortunately, "dim byref" is not the only weirdness. Take for example fixed length strings that are still null-terminated, making them unsuitable for use in UDT's. The language has become a mix of classic QB and C, which doesn't speak in its favour.

[paul doe]

...
Well perhaps I should have said "null reference", but the line is thin and basically another name for the same thing (something that points to something).
...

Yes and no. It depends to what you're trying to apply it to. References are indeed a different concept that just a 'raw' pointer (called 'unmanaged pointers' in .Net, for example). A pointer is just that, a pointer. A reference, on the other hand, is a more complicated concept and its semantics would depend on the underlying language, not only on whether they are implemented or not (as with pointers).

...
So from a FB perspective - the way pointers and references are handled - yes, they are 'different'. Unfortunately, "dim byref" is not the only weirdness. Take for example fixed length strings that are still null-terminated, making them unsuitable for use in UDT's. The language has become a mix of classic QB and C, which doesn't speak in its favour.

Do note that, albeit the FreeBasic's semantic for a 'reference' is simplistic, this doesn't imply that it is the same on other languages. Just wanted to point out that there are differences between the two concepts here (in spite of FreeBasic's a-reference-is-a-pointer-that-can't-be-null approach).

But yes, the dialect is a kind of 'Frankenstein Monster' at the moment. The real problem is simply one of too much baggage: while still maintaining some degree of 'compatibility' with its root language (QB) is nice, I think that the days of prioritizing compatibility over progress are long gone, and it just became a burden for the devs now (as Munair wisely pointed out on other threads).

EDIT: Bah, I accidentally wrote 'pointers' where I meant 'references' (see underlined text above).

[marcov]

...
Well perhaps I should have said "null reference", but the line is thin and basically another name for the same thing (something that points to something).
...

Yes and no. It depends to what you're trying to apply it to. Pointers are indeed a different concept that just a 'raw' pointer (called 'unmanaged pointers' in .Net, for example). A pointer is just that, a pointer. A reference, on the other hand, is a more complicated concept and its semantics would depend on the underlying language, not only on whether they are implemented or not (as with pointers).

I'm not sure if that is really the difference Munair is encountering here. I doubt Munair does pointer math with his classes or other weird unsafe tricks, and references in C# and Java can also be NULL. The only difference maybe is that they can't be stale due to GC.

But if you can assign a reference to another one in FB, and the system doesn't prohibit stale references, it is yet another thing

[Munair]

I'm not sure if that is really the difference Munair is encountering here. I doubt Munair does pointer math with his classes or other weird unsafe tricks

You are right. With the BasicStudio project I had to resort to the use of pointers in a way I didn't like and I'm not referring to passing pointers to GTK.

The SharpBASIC project is currently written in FB, but so far not a single pointer type has been declared... I will save that for the time when SharpBASIC becomes self-hosting.

[PaulSquires]

But yes, the dialect is a kind of 'Frankenstein Monster' at the moment. The real problem is simply one of too much baggage: while still maintaining some degree of 'compatibility' with its root language (QB) is nice, I think that the days of prioritizing compatibility over progress are long gone, and it just became a burden for the devs now (as Munair wisely pointed out on other threads).

I agree with this as well. I would certainly not be adverse to a decision to carve off all legacy features and baggage to an FB Classic compiler that would be feature frozen. Strip it all away from the main FB compiler going forward leaving a cleaner code base that could be more easily built upon. (which is easy for me to say as I am not a core developer or user of non #lang FB features. I imagine I may not be in the majority with this opinion).

[Imortis]

But yes, the dialect is a kind of 'Frankenstein Monster' at the moment. The real problem is simply one of too much baggage: while still maintaining some degree of 'compatibility' with its root language (QB) is nice, I think that the days of prioritizing compatibility over progress are long gone, and it just became a burden for the devs now (as Munair wisely pointed out on other threads).

I agree with this as well. I would certainly not be adverse to a decision to carve off all legacy features and baggage to an FB Classic compiler that would be feature frozen. Strip it all away from the main FB compiler going forward leaving a cleaner code base that could be more easily built upon. (which is easy for me to say as I am not a core developer or user of non #lang FB features. I imagine I may not be in the majority with this opinion).

I have thought about this a lot as well. Problem is we have a lot of people who agree the compiler should move forward, but no real consensus on how that should happen. Also, the people who are capable of making that happen are not very inclined or don't have the time required to make it happen.

[marcov]

IMHO the problems are more in core concepts like the prevalence of the preprocessor, and header based compilation unit model.
Cutting some legacy QB features won't fix much.

[Imortis]

IMHO the problems are more in core concepts like the prevalence of the preprocessor, and header based compilation unit model.
Cutting some legacy QB features won't fix much.

I am curious about this. Can you point me to a resource on the header based compilation model and alternatives?

[marcov]

IMHO the problems are more in core concepts like the prevalence of the preprocessor, and header based compilation unit model.
Cutting some legacy QB features won't fix much.

I am curious about this. Can you point me to a resource on the header based compilation model and alternatives?

C#-Java, Pascal/Delphi all have different models. C# and Java have no separation between declaration and implementation (header and source), afaik just like VB didn't. How that exactly works (if they have a quick parse ability for using, or if they rely on stored state) I don't know.

In Pascal/Delphi you do have difference, but interface and implementation they are intrinsically linked(*), and importing a file doesn't reparse the header (but is loaded from caches in binary format)

Search e.g. on unit or module system on this forum. It is not the first time (I brought it^H^H^H^H ) it came up.

(*) the most recent C++ standard also supports some module system, but I haven't

[Lost Zergling]

The speed of the pointers is an essential element, and the FB pointers have already been compared in speed to C (by Dodicat and others). I think if the compiler had to take into account differentiated references, it would be slower. Perhaps for full support object syntax, a different abstraction for references is necessary, but chances are that it would not be compatible with the existing one and that it would thus be slower. In the same vein, the zstring type has a termination character because it has no descriptor (the problem is not just zero, it is that the length is not saved in memory , except that for a fixed size data structure this can be managed via typing, and this is obviously linked to performance).

Munair wrote : Take for example fixed length strings that are still null-terminated, making them unsuitable for use in UDT's.

In lzle, I use zstring in udt and this is not a problem, thus it is according to my point of view an important feature (#Lang FB).
When you use a description of a "high-level" data structure, or let's say more simply object, you describe the data, their persistence, their size, as well as all the associated structure which characterizes its behavior. But, unless the conceptualization itself is dedicated that way (garbage collection, as pointed out by Paul Doe) you have no control over the underlying, precisely because the purpose of typing is to free you from this task. You cannot therefore describe data of fixed size and incriminate the syntax to try to obtain the same advantages on variable data while keeping the high level advantages of the objects code & data structure description.

[jj2007]

IMHO the problems are more in core concepts like the prevalence of the preprocessor, and header based compilation unit model.
Cutting some legacy QB features won't fix much.

True. I have no stakes in this since I am more an outside observer than a frequent FB user. My main problems are:
- what exactly is the market niche of FreeBasic?
- why would anybody use a BASIC dialect that looks more and more like C++?
- which kind of user needs the C++ features, and why would they use FreeBasic instead of C++?
- why is this forum so crammed full of threads discussing the setup problems when trying to make xyz compile?

[aurelVZAB]

I am smilar "user" like JJ but he ask interesting questions:

- what exactly is the market niche of FreeBasic?
: i am not sure what that might be.
- why would anybody use a BASIC dialect that looks more and more like C++?
: yes indeed why ?
- which kind of user needs the C++ features, and why would they use FreeBasic instead of C++?
: i don't know which ..because i don't see big amount of C++ OOP users here ?
- why is this forum so crammed full of threads discussing the setup problems when trying to make xyz compile?
: compilation types is too confusing ,is really nececery to have all that command line options?