PureBasic - really pure? For example: Str()-Function

[Psychophanta]

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.

Noo!
Besides, if you do that, then would be ugly and inconsistent to see ValF, ValQ... or PeekF, PeelD ...etc.

[blueznl]

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

so? allow us to check for a variable type upon compilation time using a compiler statement...

[Dare2]

Okay, I think a generic Str() should work without bloat or slowdown as the compiler must know current data type at compile time. Otherwise all expression evaluation would fail. So it does the expression evaluation, creating asm as it goes ..

• Mov
  Jo
  AAS

.. decision point: Whups, got a Quad. Call the StrQ proc here. And ..

• ROL
  LOL
  LAHF
  ROFL

.. Heya, got a double here, insert the code to call the StrD proc.

And so (although this isn't a democracy) I vote for a generic Str().

But not yet. Let 4.00 stabilise as it stands, and quietly apply this to a 4.xx

[blueznl]

it hurts, but perhaps dare is right

[Fred]

Without cast it won't be reliable. Try to multiply 2 big longs (the result will be above the long limit). The compiler can't decide if he needs to pickup the long version or the quad version. So it will always fallback to the quad version, with the overhead we know (both in size and performances), to have correct result (as this is the priority). There is a long of case like this, even with simple addition. The only case where it could work is when you only specificy a variable, then yes the compiler can make the decision. For now we will leave it like this, it's not that a bad deal as it has its good points as well.

[blueznl]

fred, do you think we could get a compilerif statement to check on variable types? that would be nice and woud solve any of these issues as people can build their own solutions if they want

[akee]

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.

Yup! PB Code is tight like a pure virgin! :p

[Polo]

I prefer to stay with the StrF, StrD, ...
Just because even if it's basic, it's also complete, then if StrF become Str, the users won't understand why there is PeekF and not Peek, it would really mess everything to change the commands into one.

[chris319]

We could do an 'all in one' function, but it will make a slow down and bloat the call to every 'normal' Str()

Instead of bloating the code you've bloated the language syntax. Why not have:

Code: Select all

AbsD()
AbsF()
AbsL()
AbsQ()

If you can live with bloated syntax, my idea is:

Code: Select all

Str() ;works with all numeric variable types
StrD() ;for doubles
StrF() ; for floats
StrL() ;for longs
StrQ() ;for quads

The last four are for faster execution.

[MLK]

would just be consistent!

tell a beginner why there is no StrL() *huh*!?

[Lebostein]

That's consistency:

StrB()
StrW()
StrL()
StrQ()
StrF()
StrD()

[hellhound66]

Try to multiply 2 big longs (the result will be above the long limit). The compiler can't decide if he needs to pickup the long version or the quad version.

It doesn't need to, you should tell the compiler.

Code: Select all

  bigvalue1.l = bigvalue1*bigvalue2.l  ;too big for long, but still a long
  exp.q = bigvalue1*bigvalue2.l ; now the compiler knows, it's a QWord

You declare _every_ var, you have in your code, and if you don't it's the deftype type (long as usual^_^). And I don't want the compiler to change the type I declared.


STR-Problem:
Dare2 is right. If Fred's compiler works different, we must live with it, but Dare2's explanation makes more sense, than any other. The compiler will know the correct data type, so why should the programmer tell the compiler twice?

If I want a long as a string:

str.s = str(longvar)

If I want it as a float:

str.s = str(float(longvar) [,x])

[Michael Vogel]

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.

Bigger? When using Str, StrD, StrF and StrQ, then all code would be linked into the exe, isn't it?

Slower? I've just done a test with my 20+ years old 16 bit GFA (yes, again) - the universal Str-Function is far more than 3 times faster - now I'm a little bit nervous...

Code: Select all

;11 seconds with GFA...
DEFDBL "d"
DEFLNG "i,l,z"
DEFWRD "w"
DEFSTR "s"

d = PI
l = PI
w = PI
looptime = 50

z = -GetTickCount()
FOR i = 0 TO 9999999
  s = STR$(d)
NEXT i
z += GetTickCount() - looptime

PRINT z
PRINT s

Code: Select all

;38 seconds with PureBasic...
#looptime=50

d.d=#PI
l.l=#PI
w.w=#PI
s.s=""

DisableDebugger
z=-GetTickCount_()
For i=0 To 9999999
s=StrD(d)
Next i
z+GetTickCount_()-#looptime
EnableDebugger

Debug z
Debug s
; also checked with MessageBox_(0,Str(z),s,#MB_OK) and no debugger commands 

[Dare2]

now I'm a little bit nervous...

I would also be nervous if I was using GFA - and more so if I was constantly holding it up as a shining example on a PureBasic board.

[Michael Vogel]

I would also be nervous if I was using GFA - and more so if I was constantly holding it up as a shining example on a PureBasic board.

You're so right - and that's why it should be impossible that such an 25 year old bastard of basic has a smaller, faster, better, etc. pp. implementation of the str function, don't you think so?