in reply to Re^3: XS/Inline::C concat *any* two SVs.
in thread XS/Inline::C concat *any* two SVs.

Right now, all is behaving, even w/o refcnt mess

The code in the OP does exactly what I need it to do. The equivalent of Perl's $scalar1 .= $scalar2;. Your version does not.

I want, and need to accumulate the appended data in the original SV.

The question is why do I need to increment the ref count, not how to avoid doing so. The problem with your approach is that you are completely discarding the benefits of Perl's dynamic string management.

Your code is roughly equivalent to

my $scalar3 = $scalar1; $scalar3 .= $scalar2;

Which is not what I need. I would have to do

my $scalar3 = $scalar1; $scalar3 .= $scalar2; $scalar1 = $scalar3;

to get what I need and that is very wasteful as this will be called many (100s) of times to append 4 bytes each time.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^5: XS/Inline::C concat *any* two SVs.
by vkon (Curate) on May 28, 2006 at 22:08 UTC
    I want, and need to accumulate the appended data in the original SV.

    That's easy, but in this case you must work not with SV but refernce to SV, and dereference it properly.

    Let us start with perl stub of what you're trying to achieve

    sub test { my $ref = shift; $$ref .= shift; # concatenate, but do efficiently at C level, workin +g with preallocated space }

    If this is not what you need, then try expressing in terms of Perl sub your ideas, and we'll translate those to XS... or C.

    When you enter a sub, parameters to it are mostly copied (well, sometimes they are aliased but relying on this knowledge will not help you understanding, so let us assume they are copied), so you will not gain speed unless you work with reference.

    Regarding your OP code, when you make an illusion of correctly working code, but with mystery "Why do I need to increment the ref count?" this only means you got a SV leak. I can explain it, if needed.

    PS sorry my frustrated reply, but once you'll explain your subroutine better I will reply better :)

      well, sometimes they are aliased but relying on this knowledge will not help you understanding,

      Actually, that is exactly the type of understanding I hope to aquire. The very purpose of dropping into XS to code is to achieve better performance. If you throw away half that potential by unnecessarially replicating data, there is no point in going there in the first place.

      The purpose of the exercise is to learn how to correctly use and benefit from using Perl's scalar classes from within XS code.

      Dealing with scalars that might be NVs, IVs, UVs and readonly is only the first part of the exercise. There are also RVs, tied scalars, blessed scalars etc. When I posted, I was hoping for insights into dealing with these also. I never expected to get hung up on dealing with readonly inputs.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        IMO dealing with NVs, IVs, UVs should be left to perl, its algorithms were tuned by years of everyday use and tons of bugreports. So instead of inserting your own "if numerix then stringify" better just do nothing and perl will DWIM. (let days of its DWIMery and TIMTOWTDI will be countless :)

        I applause to your intentions on deal efficiently with SV. This is very doable. I will gladly share my knowledge, in addition to what I already shared (try pure-XS w/o Inline::C and you need reference to SV to be able to modify SV passed to sub).