PureBasic Forums - English

Hi,

the new chaos of Str()-functions is very annoying and not pure. Look at this code: For every variable I must check the type... and the results without the second function parameter are bad.

-----------------------

Look at FreeBasic. Thats pure! And the results are ok: Clear, simple and really 'pure'....

-----------------------

My wish: a single Str()-Function for all types with optional parameter like this:

I agree! Although I don't like the idea of a secon parameter - just one, standard Str() function will do.

Ok, or two procedures:

Str(value) for integers (byte, char, word, long, quad)
StrR(value [, decimals]) for reals (float, doubles)

@Lebostein,
You are not right! This is pure!

PURE-SPEED !!!!

My wish to @Fred:
Let it be as it is.

But If (fred) want he can write an additional (overloaded) function for our lazy programmers

Hey, Mr. Shrek. It was a suggestion!!! I want to see here a factually discussion and no obscenities!

Pro:
- limited set of functions and easy way to use

Contra:
- losing of speed (the only reason to slow down is the check of the type)

Lebostein wrote:Hey, Mr. Shrek. It was a suggestion!!! I want to see here a factually discussion and no obscenities!

Where is the obscenities ?

Well, you got half your wish (no obscenities) and perhaps the start to a complete wish-fulfillment.

We could do an 'all in one' function, but it will make a slow down and bloat the call to every 'normal' Str() functions (ie: when no quad/double/floats are involved). Also the Str() function itself will be much bigger.

That's very true. Ah well, it wouldn't be too hard to write our own wrapper function, right?

Humour a tyro.

With an numeric expression, it is evaluated according to internal rules and conversions by the compiler, which knows the type needed step by step, I assume? These conversions are not handled by the final exe, are they? (Because that would add runtime overhead, surely?)

If so (compiler, not exe, converts) then with something like Str(exp), the current type of expression (the last conversion, so to speak) would be known by the compiler. Could it not then, behind the scenes, just use the StrX that applied?

There are already functions for the various types, so this should add no overhead to the final program, only the compiler is involved in deciding which flavour of Str to use?


Also, wouldn't this be less overhead from the compiler point of view than having to build in checks to handle things like StrF(myDouble.d) or StrQ(myFloat.f) for every permutation of StrX call verses actual data type?


Given my vast experience in writing compilers I am probably way off course, but the above seems to make sense. Anyhow, just curious.


Edit:
Removed the worst of the bad grammer. Live with the rest.

Fred wrote:Also the Str() function itself will be much bigger.

but there could be added a StrL() function and/or Str could become Str(val[,type]).

oooooooo i feel a wish coming up....

* BURP *

yep, there it is

fred, could we get a...
oh i would *love* that!

(hmm, a preprocessor could also handle it, but that would not improve portability)

MLK wrote:but there could be added a StrL() function and/or Str could become Str(val[,type]).

Yes! that sounds good.
Then normally you can use Str(val) easy to use,
and if you have any speed critical application you can specify the type with Str(val, type) keeping high speed.

joske wrote:

MLK wrote:but there could be added a StrL() function and/or Str could become Str(val[,type]).

Yes! that sounds good.
Then normally you can use Str(val) easy to use,
and if you have any speed critical application you can specify the type with Str(val, type) keeping high speed.

There is no technical reason for not making an overloaded version of Str() which replaces itself with the correct type version at compile time, thus still giving the full speed at run-time.

But Fred would have to introduce explicit casting to explicitly choose a
procedure, what he never wanted (if I remember correctly).