Fred: "under the hood" handling of strings?

[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.

[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)

[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.

[Tenaja]

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.

[Mistrel]

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.

[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.

[Mistrel]

You may be pretty good at it but threads don't care.

[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.

[luis]

First of all, there is no "const" keyword in PureBasic to specify read-only parameters like in C.

Indeed const... where are thou ?