PureBasic Forums - English

I would personally like to see more types:
Plus Double Precision Floats and Strings >64k

Thats it i think from me!

Did i miss anything?

To be able to write PureBasic Libraries in PureBasic, this way you can kinda protect your code and use the optional parameters feature.

> Strings >64k

And how big? 1 MB? (and the we have topics like Strings bigger tha 1MB) As i know Strings work with a buffer with a fixed length. And i don't want that a simple program like this: need 20 MB Ram, because somebody set the limit to 10 MB (as i know two buffers for strings are reserved!)
Then start about 3-5 PB-Programms and 60-100 MB is reserved for Strings. What a waste of memory!

I think, that 64K is engouth. Strings are for sentence, not for complete documents or as buffer for datas. For this case use AllocateMemory() and your own routines (and i think, that your routines are then faster).

But before we discuss about this again and again:
For all, who can't program:

What about a compiler-Command: So everybody can set the Stringbuffer to the size, which they need.

GPI wrote:What about a compiler-Command:

Code: Select all

StringBufferLength 10*1024*1024

So everybody can set the Stringbuffer to the size, which they need.

That sounds great. I still know how to program, but I would find that very useful.

varname.c[length]

why not add it as a variable instead of as a struct field?

var.c[5] = "12345"

it's effectively a fixed length string (which i would kill for)

Plus Double Precision Floats and Strings >64k

Yes reliable float and double calculus and one and only STR() for all variable types. I would like to forget about STRF()...

Personally I'd like to see strings with no hard limit like that.. I suppose most languages that have a string type do have a hard limit of some sort but generally I'd think it was big enough to not be an issue. A friend just told me that VB's were 2 gig (not that we want to mimic VB!).

Also all the internal buffers of the string functions will have to be brought up to work on strings larger than 64000 bytes too. That limit is reached before the actual string size comes into play most of the time.

Also for 4.0 - thread safe strings!!!

It would be useful to have a more mature 3D-Engine with more PanTiltRoll-Camera-moving-commands to a crumb and a better Sound-Lib with multichannel, internetstreaming and DSP-chains, but these things are not really important for me. It's really the basics, that should be optimized, or completed, or whatever, so espacially doubles (I mean int64) and other variable types, and all of them in signed and unsigned (!) should be implemented. I was fumed of the signed int32-limitation by anger several times.

Because I use PB a lot for Maths I really would love those new types.
If the basics of PB would be stable with this stuff implemented, it would be a perfect basis for developing neverseen-creative 3D(or any other)-stuff combined together with complex algorithms and perhaps it would be the first choice and quiet tip on universities for start.

Pleease, first the coolest basics, than the coolest overhead.

If the basics of PB would be stable with this stuff implemented, it would be a perfect basis for developing neverseen-creative 3D(or any other)-stuff combined together with complex algorithms and perhaps it would be the first choice and quiet tip on universities for start.

Please, first the coolest basics, then the coolest overhead.

Yes, the potential for PB could be huge!

Totally in accordance with Kale and FroggerProgger.

Whenever no-loose of PB executeables size and speed, ehhmmmm?

@Blueznl

I agree this:

varname.c[length]

why not add it as a variable instead of as a struct field?

var.c[5] = "12345"

it's effectively a fixed length string (which i would kill for)

is needed and you can do this:

part.c = var.c[2]
to just extract the '2' out of var.c above (see quote)

And your string routines will be FASTER, NO conversion on API calls!! Code will be easier (not for FRED i am afraid) And the size of the exe file will drop! Beter garbage collection! Better protection (on Pentuim processers) on poking OUTSIDE your string!! Must I go on on this? Better everything!!

@Kale, UNICODE?? (blah) remember ONE character is TWO BYTES!! So with var.u you only have 32k of string space!! And who needs that! It is peronally an joke from MS gone bad!! Did enyone noticed that the (FIRST) press release on UNICODE strings was on april FIRST!! I do not know the year, but noticed the DATE of this, later I heard that Bill G. was very angry but liked the idea (stupid!!!!) Just lazy programmers!! The rest of your VARS i like and as BluezNl said "die for"....


@FRED how about this? New VARS for version 4.0 (any day now??) and FIXED length string. Even if it means seperate routines!! We can add and 'F' or 'C' or 'X' allthough the 'x' is better for UNICODE strings. Personally I would like the 'C' for Character string!!

So like (now):

Result$ = Mid(String$, StartPosition, Length)

will be:

Result.c = MidC(String.c, StartPosition, Length)
or:
Result.c = CMid(String.c, StartPosition, Length)

The latter is better since the C in FRONT is noticed FIRST!!

or better maybe??

Result.c = Mid.c(String.c, StartPosition, Length)

(notice the MidC() and CMid() and the last the mid.c() [ the dot])

Jan

jan, languages should make sense so if you have

var.c[5] = "12345"

then the following doesn't make much sense:

a.s = var.c[2]

as var.c fixed length strings are strings, they could be treated in all other aspects as strings, so instead you could use

a.s = mid(var.c,2,1)

so there would be no need for:

Result.c = MidC(String.c, StartPosition, Length)
Result.c = CMid(String.c, StartPosition, Length)

Doubles are essential, there is really no work-around for many applications.

I'd like to see strings that can contain chr(0). This would greatly simplify the handling of binary files.

let's all sing together: var.c... fixed length strings that can contain ascii zeroes... lalalalala (now all we need is a proper tune)

geoff wrote:I'd like to see strings that can contain chr(0). This would greatly simplify the handling of binary files.

I think, that Fred want to make strings compatible with the System-Default and in nearly all API-Commands strings are terminated with Null (and i think, that C-"strings" are also Null-Terminated).

But i know from Omikron-Basic (Atari-ST): There is a Length-Flag before a string in the memory, so the Length is stored there. So it is possible to use all chars...