Page 1 of 1
Fred: "under the hood" handling of strings?
Posted: Mon Nov 24, 2014 6:39 pm
by Tenaja
Several times, other users have proclaimed that passing a string variable is just passing a pointer, so I have used it judiciously.
However, speed tests have shown extensively that passing pointers is typically about 50% faster in simple test loops.
So, my questions is this: What happens "under the hood" (aka "behind the scenes") when I pass a string?
Code: Select all
Procedure StringTest(s.s)
a.s = s.s
ProcedureReturn a
EndProcedure
GlobalString.s = "string"
t.s = StringTest(GlobalString)
I would guess there is a "copy" of GlobalString made, and that is the reason for the speed hit. Am I right, or is the actual pointer to the original GlobalString sent?
Also, if I send a sum of strings (i.e. "x="+str(x) ), is it safe to assume that a temporary string is created? If that is the case, is that temp var used, or is yet another created to be passed?
Thanks.
Re: Fred: "under the hood" handling of strings?
Posted: Mon Nov 24, 2014 8:00 pm
by Demivec
The string is always passed as a copy. That is why using a pointer is faster.
If a pointer was passed to the string it would be reflect changes made to it in the procedure.
Fred or freak has commented on this in the past, if I find the post I'll link it here.
http://www.purebasic.fr/english/viewtop ... =3&t=28104
http://www.purebasic.fr/english/viewtop ... 20&t=18029
@Edit: added one link, it is not the one I was thinking of; it is a little indirect.
@Edit2: added a link describing whether a string address would be passed as a parameter or the string itself (discussion)
Re: Fred: "under the hood" handling of strings?
Posted: Mon Nov 24, 2014 8:49 pm
by Mistrel
I think the default behavior is correct as it's more defensive with regards to threading. Otherwise the moment you turned on threads you could be exposing yourself to a crash or unexpected behavior.
Re: Fred: "under the hood" handling of strings?
Posted: Mon Nov 24, 2014 9:49 pm
by Tenaja
Mistrel wrote:I think the default behavior is correct as it's more defensive with regards to threading. Otherwise the moment you turned on threads you could be exposing yourself to a crash or unexpected behavior.
If your proc parameter is used as read-only, then there can be no safety issues.
Re: Fred: "under the hood" handling of strings?
Posted: Tue Nov 25, 2014 1:27 am
by Mistrel
Tenaja wrote:If your proc parameter is used as read-only, then there can be no safety issues.
First of all, there is no "const" keyword in PureBasic to specify read-only parameters like in C. Secondly, that kind of behavior is only evaluated at compile time unless you're using a language with RTI (runtime type information); and even then it's still just a promise than an enforcement.
And even if you were to somehow enforce this behavior, you're either going to lock up your threads or cause a memory access violation.
Re: Fred: "under the hood" handling of strings?
Posted: Tue Nov 25, 2014 4:25 am
by Tenaja
When I write a procedure I am pretty good about understanding which parameters are read-only, and which are written to, regardless of the reading or writing permissions.
Re: Fred: "under the hood" handling of strings?
Posted: Tue Nov 25, 2014 4:52 am
by Mistrel
You may be pretty good at it but threads don't care.
Re: Fred: "under the hood" handling of strings?
Posted: Tue Nov 25, 2014 5:59 am
by IdeasVacuum
You may be pretty good at it but threads don't care.
It is easy to believe you are thread safe and later find that you have overlooked something but it is as much to do with good coding habits as anything.
Re: Fred: "under the hood" handling of strings?
Posted: Tue Nov 25, 2014 12:05 pm
by luis
Mistrel wrote:
First of all, there is no "const" keyword in PureBasic to specify read-only parameters like in C.
Indeed
const... where are thou ?
