Poll your PB-wishlist ...

[Patrice Terrier]

If they had enough personal, I believe there would be a new 32 or also wanted a 64 bit compiler out here already.

A new 32-bit compiler, why not (current TASM version should help doing the conversion).
As for us, fortunatly the current 16-bit compiler works fine, even on VISTA, and it produces plain lean 32-bit code.
Now does a 32-bit version of the compiler will be able to produce directly 64-bit executable, that is another question.

I think that, if the R&D team is too small, one solution would be to accept the help of other peoples who can help on a specific topic, and work closer with them.

Most of us are getting old (except me) thus waiting for version 12 could take a long time, even if Mister R&D is in good health, then I must say long live to him!   
Amen.

[Charles Pegge]

The old Intellectual property barriers are breaking down very rapidly, as software development becomes a community enterprise. I think it is a very good strategy to accept outside help from wherever it comes. It should not matter that PB inc is a commercial organisation.

[Theo Gottwald]

I think that, if the R&D team is too small, one solution would be to accept the help of other peoples who can help on a specific topic, and work closer with them.

This is one of the strong sides of PureBasic. The developer (Fred) always accepted and honoured help from the community.
Actually important part of the package itself are developed by community members.

And in fact the PB community is not worth.
We have SED-Editor, PrePBEd, all the stuff from Jose etc.

Anyway if you buy PB today, you still get that old fashioned Editor, instead at least a PrePBEd Version with Tabs or a version of SED - Joses well made Editor.
Personally i believe this is a very important point where PowerBasic could improve.
Just let the communty take part in the official developement and help to speed things up.

[Paul Squires]

My biggest concern about PB is not with the compiler but with the rate of change in the compiler (too slow). In this day and age of Internet, everything is moving faster. It seems that you need to accelerate your development times and release more product, more often, or you will be left behind by competitors. I look at a compiler like FreeBASIC and marvel at how much functionality is already present in a compiler that is less than a few years old. Maybe it is time to revisit that "no vaporware" policy. Is it really helping or hurting?

[Paul Squires]

... another thing that I have asked for in the past: Allow dynamic strings in TYPE structures. Having this built into the compiler to handle is much easier than having to use ASCIIZ Ptr's and manual create the memory, assign the string, and then free the memory when finished with it.

[Eros Olmi]

Paul,

I would like too to have dynamic strings inside UDT.

For those in need to have something similar, using DIM ... AT you can quite easily use dynamic strings inside any UDT
Yes, it remain the problem to free the string when all is done.

Example:

Code Select Expand


'---Define some LONGs in place of strings
type MyUDT
  aString1 as long
  aString2 as long
end type

'---Define a UDT variable
dim MyVar as MyUDT

'---Define a dummy string that in reality is a place holder pointer pointing to the LONG inside the UDT
dim DummyString as string at varptr(MyVar.aString1)

'---Do what you need with DummyString like any other standard dynamic string
DummyString = "abcdef"
DummyString = repeat$(10, DummyString)
...

'---The bad part, free allocated string data manually
remove MyString



[Theo Gottwald]

Code Select Expand

Allow dynamic strings in TYPE structures
@Paul: I strongly second that. Is something I often miss.

@Eros: I know there are some sorts of workarounds, anyway none of these can substitue a clean implementation in the compiler, you know.

Reason: Using Types you can easily programatically duplicate "Real world data" into data structures.
And dynamic strings are perfect if you do not want to care for the amount of data you may get.
Together it would be a good team.

[Edwin Knoppert]

I would like to add: classes.
Constructor and deconstructor.
Would also solve the dynamic string in structure

[Paul Squires]

Another thing that I wished for: Built in statements for allocating/freeing blocks of memory so you don't have to use your own wrappers around WinAPI functions. For example, new BASIC functions like, MEMALLOC and MEMFREE or similar. Hell, we have pointers but pointers really shine when the programmer can dynamically create and destroy blocks of system memory on-the-fly.

[Theo Gottwald]

Just noticed that this topic is the second strongest topic in this sub-forum.
Also we can count on 11 votes already, that shows that the most missed features are classes/Objects and COM-Support.
And I am not the only one who would want to live without DECLARING things to the compiler.
Its enough complicated, that we have to declare everything to the german tax-office. :-)