Page 2 of 4
Posted: Tue Feb 14, 2006 9:21 pm
by Psychophanta
Fred wrote: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.
Posted: Tue Feb 14, 2006 11:32 pm
by blueznl
remi_meier wrote: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...
Posted: Wed Feb 15, 2006 1:51 am
by 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 ..
.. decision point: Whups, got a Quad. Call the StrQ proc here. And ..
.. 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
Posted: Wed Feb 15, 2006 8:47 am
by blueznl
it hurts, but perhaps dare is right
Posted: Wed Feb 15, 2006 1:01 pm
by 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.
Posted: Wed Feb 15, 2006 1:03 pm
by 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
Posted: Wed Feb 15, 2006 7:55 pm
by akee
Fred wrote: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
Posted: Wed Feb 15, 2006 7:57 pm
by 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.
Posted: Wed Feb 15, 2006 10:41 pm
by 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:
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.
Posted: Thu Feb 16, 2006 12:03 am
by MLK
would just be consistent!
tell a beginner why there is no StrL() *huh*!?
Posted: Thu Feb 16, 2006 10:12 am
by Lebostein
That's consistency:
StrB()
StrW()
StrL()
StrQ()
StrF()
StrD()
Posted: Wed Feb 22, 2006 1:10 pm
by 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])
Posted: Tue Mar 21, 2006 10:13 am
by Michael Vogel
Fred wrote: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
Posted: Tue Mar 21, 2006 1:12 pm
by Dare2
Michael Vogel wrote: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.
Posted: Tue Mar 21, 2006 8:42 pm
by Michael Vogel
Dare2 wrote:
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?