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.
:mrgreen:
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 ? :)