[32719] in Perl-Users-Digest
Perl-Users Digest, Issue: 3983 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 6 21:09:42 2013
Date: Sat, 6 Jul 2013 18:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 6 Jul 2013 Volume: 11 Number: 3983
Today's topics:
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <oneingray@gmail.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <rweikusat@mssgmbh.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <rweikusat@mssgmbh.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <ben@morrow.me.uk>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <rweikusat@mssgmbh.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <derykus@gmail.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <derykus@gmail.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <oneingray@gmail.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <ben@morrow.me.uk>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <derykus@gmail.com>
Re: [XS] .h constants -> Perl subs (like POSIX' "errno_ <hjp-usenet3@hjp.at>
Re: [XS] DESTROY: free or flush? "related" objects? <rweikusat@mssgmbh.com>
Re: [XS] DESTROY: free or flush? "related" objects? <oneingray@gmail.com>
Re: [XS] DESTROY: free or flush? "related" objects? <ben@morrow.me.uk>
[XS] invalidating the pointers in DESTROY? <oneingray@gmail.com>
Re: [XS] invalidating the pointers in DESTROY? <ben@morrow.me.uk>
Re: clobbering of $@ in DESTROY? <rweikusat@mssgmbh.com>
Re: having trouble with hash of arrays... <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: having trouble with hash of arrays... <jurgenex@hotmail.com>
Re: speed of subroutine calls in perl <cwilbur@chromatico.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 06 Jul 2013 07:23:28 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <87ehbc179r.fsf@violet.siamics.net>
>>>>> Charles DeRykus <derykus@gmail.com> writes:
>>>>> On 7/2/2013 11:05 PM, Ivan Shmakov wrote:
>> Is there an easy way to make a bunch of C constants (as in: #define)
>> available as Perl subroutines (just like, e. g., POSIX does for the
>> errno.h constants)?
[...]
> Could you just transform 'em to perl constants, eg,
> BEGIN {
> my %const = map {chomp; (split)[1,2]; }
> qx{ grep '^#define' /path/to/*.h };
Surely I could. The question is: how do I keep my code in sync
with the library's it duplicates?
[...]
--
FSF associate member #7257
------------------------------
Date: Sat, 06 Jul 2013 11:06:02 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <87k3l40zqt.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 7/2/2013 11:05 PM, Ivan Shmakov wrote:
>> Is there an easy way to make a bunch of C constants (as in:
>> #define) available as Perl subroutines (just like, e. g., POSIX
>> does for the errno.h constants)?
[...]
> Could you just transform 'em to perl constants, eg,
>
> BEGIN {
> my %const = map {chomp; (split)[1,2]; }
> qx{ grep '^#define' /path/to/*.h };
> my $code;
> while ( my($k,$v) = each %const ) {
> $code .= "$k => $v,";
> }
> eval "use constant {$code}";
> die $@ if $@;
> }
That's broken. Some people indent nested preprocessor directives, eg
#ifdef BLAH
# define OOPS "yodel"
#else
# define OOPS "---"
#endif
Macro expansions may be multiline, eg
#define OTHERTINGER \
"dock"\
"wok"\
"clock"\
"cat"\
"bat"\
"flat"\
"spherical"\
"dot"
There might not by any expansions and macros can have arguments (this
is likely not an exhausive list). Also, numerical constants can be
defined via enum which makes them visible to 'other tools' (like
debuggers) and prevents 'unexpected substitutions' as in
#include <stdio.h>
#define oo ar
int main(void)
{
int oo = 5;
printf("%d\n", ar);
return 0;
}
You also don't need the eval, constant.pm also works with anonymous
hashes
perl -e 'use constant { A => 2, B => 3 }; print A + B, "\n";'
------------------------------
Date: Sat, 06 Jul 2013 13:14:37 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <87hag728cy.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Charles DeRykus <derykus@gmail.com> writes:
[...]
>> BEGIN {
>> my %const = map {chomp; (split)[1,2]; }
>> qx{ grep '^#define' /path/to/*.h };
>> my $code;
>> while ( my($k,$v) = each %const ) {
>> $code .= "$k => $v,";
>> }
>> eval "use constant {$code}";
>> die $@ if $@;
>> }
[...]
> You also don't need the eval, constant.pm also works with anonymous
> hashes
This statement doesn't exactly make any sense :-). But the eval isn't
needed, one way to accomplish the same would be
----------------
BEGIN {
my %c = ( A => 1, B => 2 );
use constant;
constant->import(\%c);
}
print A,B,"\n";
------------------------------
Date: Sat, 6 Jul 2013 14:03:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <66hlaa-sgl1.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 7/2/2013 11:05 PM, Ivan Shmakov wrote:
> > Is there an easy way to make a bunch of C constants (as in:
> > #define) available as Perl subroutines (just like, e. g., POSIX
> > does for the errno.h constants)?
>
> Could you just transform 'em to perl constants, eg,
>
> BEGIN {
> my %const = map {chomp; (split)[1,2]; }
> qx{ grep '^#define' /path/to/*.h };
> my $code;
> while ( my($k,$v) = each %const ) {
> $code .= "$k => $v,";
> }
> eval "use constant {$code}";
> die $@ if $@;
> }
That's what h2ph does. There's a reason it was replaced with h2xs, and
that is that it's usually better to get the C compiler to interpret C,
since include files can contain all sorts of rubbish.
For instance, your code above will fail on both these common cases:
/* sys/ioctl.h */
#include <sys/ioccom.h>
#include <sys/filio.h>
#include <sys/sockio.h>
#include <sys/ttycom.h>
/* perl.h */
#ifndef S_IRUSR
# ifdef S_IREAD
# define S_IRUSR S_IREAD
# define S_IWUSR S_IWRITE
# define S_IXUSR S_IEXEC
# else
# define S_IRUSR 0400
# define S_IWUSR 0200
# define S_IXUSR 0100
# endif
#endif
not to mention more complicated constructions like the BSD ioctl
definitions, where one macro is defined as an expression involving other
macros (which does eventually resolve to a constant).
Ben
------------------------------
Date: Sat, 06 Jul 2013 15:17:28 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <87r4fbbwnb.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 7/2/2013 11:05 PM, Ivan Shmakov wrote:
>> > Is there an easy way to make a bunch of C constants (as in:
>> > #define) available as Perl subroutines (just like, e. g., POSIX
>> > does for the errno.h constants)?
>>
>> Could you just transform 'em to perl constants, eg,
>>
>> BEGIN {
>> my %const = map {chomp; (split)[1,2]; }
>> qx{ grep '^#define' /path/to/*.h };
>> my $code;
>> while ( my($k,$v) = each %const ) {
>> $code .= "$k => $v,";
>> }
>> eval "use constant {$code}";
>> die $@ if $@;
>> }
>
> That's what h2ph does. There's a reason it was replaced with h2xs, and
> that is that it's usually better to get the C compiler to interpret C,
> since include files can contain all sorts of rubbish.
h2xs doesn't use external programs for analysing C headers, it
just contains a more complete 'C header analyzer' than the one in the
example above (as does h2ph, FWIW).
------------------------------
Date: Sat, 06 Jul 2013 07:25:41 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <kr99d8$os$1@speranza.aioe.org>
On 7/6/2013 6:03 AM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 7/2/2013 11:05 PM, Ivan Shmakov wrote:
>>> Is there an easy way to make a bunch of C constants (as in:
>>> #define) available as Perl subroutines (just like, e. g., POSIX
>>> does for the errno.h constants)?
>>
>> Could you just transform 'em to perl constants, eg,
>>
>> BEGIN {
>> my %const = map {chomp; (split)[1,2]; }
>> qx{ grep '^#define' /path/to/*.h };
>> my $code;
>> while ( my($k,$v) = each %const ) {
>> $code .= "$k => $v,";
>> }
>> eval "use constant {$code}";
>> die $@ if $@;
>> }
>
> That's what h2ph does. There's a reason it was replaced with h2xs, and
> that is that it's usually better to get the C compiler to interpret C,
> since include files can contain all sorts of rubbish.
>
> For instance, your code above will fail on both these common cases:
>
I knew (and have experienced) h2ph's flaws. Somehow, I was thinking
they were well-behaved, home-grown header files so "I came, I saw,
I re-invented" h2ph.
--
Charles DeRykus
------------------------------
Date: Sat, 06 Jul 2013 07:27:26 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <kr99gh$os$2@speranza.aioe.org>
On 7/6/2013 5:14 AM, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> Charles DeRykus <derykus@gmail.com> writes:
>
> [...]
>
>>> BEGIN {
>>> my %const = map {chomp; (split)[1,2]; }
>>> qx{ grep '^#define' /path/to/*.h };
>>> my $code;
>>> while ( my($k,$v) = each %const ) {
>>> $code .= "$k => $v,";
>>> }
>>> eval "use constant {$code}";
>>> die $@ if $@;
>>> }
>
> [...]
>
>> You also don't need the eval, constant.pm also works with anonymous
>> hashes
>
> This statement doesn't exactly make any sense :-). But the eval isn't
> needed, one way to accomplish the same would be
>
> ----------------
> BEGIN {
> my %c = ( A => 1, B => 2 );
>
> use constant;
> constant->import(\%c);
> }
>
> print A,B,"\n";
>
Thanks, I had forgotten that too...
--
Charles DeRykus
------------------------------
Date: Sat, 06 Jul 2013 14:42:06 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <8761wn21j5.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> There's a reason [h2ph] was replaced with h2xs, and that is that
>> it's usually better to get the C compiler to interpret C, since
>> include files can contain all sorts of rubbish.
> h2xs doesn't use external programs for analysing C headers, it just
> contains a more complete 'C header analyzer' than the one in the
> example above (as does h2ph, FWIW).
I guess the point was that h2xs (or, rather, WriteConstants ())
uses the C compiler to get the /values/ of such constants.
And as for the names, -- indeed.
--
FSF associate member #7257
------------------------------
Date: Sat, 6 Jul 2013 20:04:59 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <rb6maa-d9o1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> BEGIN {
> my %c = ( A => 1, B => 2 );
>
> use constant;
> constant->import(\%c);
> }
Or simply
use constant {
A => 1,
B => 2,
};
You can even calculate the contents of the hashref dynamically, if you
like:
use constant {
map (chr(ord("@") + $_), $_), 1..4,
};
This expression is evaluated at compile time, so any subs called need to
be available at the point where the 'use' statement is compiled.
Ben
------------------------------
Date: Sat, 06 Jul 2013 15:33:54 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <kra60p$dgu$1@speranza.aioe.org>
On 7/6/2013 12:04 PM, Ben Morrow wrote:
>
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> BEGIN {
>> my %c = ( A => 1, B => 2 );
>>
>> use constant;
>> constant->import(\%c);
>> }
>
> ...
>
> You can even calculate the contents of the hashref dynamically, if you
> like:
>
> use constant {
> map (chr(ord("@") + $_), $_), 1..4,
> };
>
> This expression is evaluated at compile time, so any subs called need to
> be available at the point where the 'use' statement is compiled.
>
Hm, appears not:
$ perl -le 'use constant {map( (chr(ord("@") + $_), $_), 1..4 ) }'
syntax error at -e line 1, near "use constant {
Interestingly though:
$ perl -le 'use constant map( (chr(ord("@") + $_), $_), 1..4 );
print A()'
1B2C3D4
This works:
$ perl -le 'BEGIN{%h = map ( (chr(ord("@") + $_), $_), 1..4 ) };use
constant \%h;print A()'
1
This of course too:
$ perl -le 'use constant; constant->import( {map ( (chr(ord("@") +
$_), $_), 1..4)}); print A()'
1
--
Charles DeRykus
------------------------------
Date: Sun, 7 Jul 2013 01:19:02 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: [XS] .h constants -> Perl subs (like POSIX' "errno_h")?
Message-Id: <slrnkth9f8.c5e.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-06 22:33, Charles DeRykus <derykus@gmail.com> wrote:
> On 7/6/2013 12:04 PM, Ben Morrow wrote:
>> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>>
>>> BEGIN {
>>> my %c = ( A => 1, B => 2 );
>>>
>>> use constant;
>>> constant->import(\%c);
>>> }
>>
>> ...
>>
>> You can even calculate the contents of the hashref dynamically, if you
>> like:
>>
>> use constant {
>> map (chr(ord("@") + $_), $_), 1..4,
>> };
>>
>> This expression is evaluated at compile time, so any subs called need to
>> be available at the point where the 'use' statement is compiled.
>>
>
> Hm, appears not:
>
> $ perl -le 'use constant {map( (chr(ord("@") + $_), $_), 1..4 ) }'
> syntax error at -e line 1, near "use constant {
Perl thinks that the { starts a block here, not an anonymous hash. You
can force it by prepending a +:
% perl -le 'use constant +{map( (chr(ord("@") + $_), $_), 1..4 ) }; print A, B, C, D'
1234
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 06 Jul 2013 11:18:44 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <87d2qw0z5n.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> >>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> > My suggestion would be to call close and print a diagnostic if it
>> > fails.
[...]
>> > That's consistent with the way 'other objects' work (specifically,
>> > file handles) and better than calling the other: there's a (usually
>> > good) chance that this will work as intended while just freeing the
>> > object is equivalent to a close which always fails.
>>
>> Sounds sensible; thanks.
>
> I would say it's always worth doing any cleanup you can which will not
> do any harm if it fails. If flushing might leave whatever its flushing
> to in an inconsistent state if it fails, it would be better not to call
> it from DESTROY and instead provide an explicit ->sync method of some
> sort.
Actually, combining both is possible: Provide the explicit method for
people whose cultural background makes it difficult for them to
understand that 'automatic management' isn't necessarily restricted to
memory and for situations were 'checking the return value of close'
actually makes any sense (which it generally doesn't) and provide a
working destructor, ie, one which doesn't gratuitiously leave the
object in an inconsistent state because trying to make it consistent
could fail.
------------------------------
Date: Sat, 06 Jul 2013 14:37:22 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <87a9lz21r1.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>> My suggestion would be to call close and print a diagnostic if it
>>> fails.
>> How do I print the diagnostic, then? (I'm considering implementing
>> ->DESTROY () in the .xs code.)
> Perl_warn, unless you want to offer some more sophisticated form of
> diagnostic catching.
As die () in ->DESTROY () already seem to turn into a warn (),
if "use warnings" is in effect, I guess I'd stick to the former.
(But then, I wonder if Perl_croak () will so behave?)
There's another question, however: what's an easy way to
invalidate the object in an XS DESTROY ()? In Perl, I've seen
it being done as follows:
sub DESTROY {
## .
return
unless ($$self);
## ... clean the things up...
## .
$$self
= undef;
}
Now, I try to invalidate the object from within an XS function:
void
obj_free (obj)
XXX::Object obj;
CODE:
/* ... clean the things up... */
/* FIXME: accessing ST () directly */
sv_setref_pv (ST (0), 0, 0);
However, this appears to be subtly different in that (AIUI) it's
the reference that gets invalidated, and not just the referent
SV. (Thus, I cannot, say, XSRETURN_EMPTY early upon seeing such
a condition.)
Any suggestions on that?
TIA.
[...]
>>> That's consistent with the way 'other objects' work (specifically,
>>> file handles) and better than calling the other: there's a (usually
>>> good) chance that this will work as intended while just freeing the
>>> object is equivalent to a close which always fails.
>> Sounds sensible; thanks.
> I would say it's always worth doing any cleanup you can which will
> not do any harm if it fails. If flushing might leave whatever its
> flushing to in an inconsistent state if it fails, it would be better
> not to call it from DESTROY and instead provide an explicit ->sync
> method of some sort.
To note is that it isn't all that obvious from the library's
documentation whether the state of the on-disk object being
manipulated will be consistent or not, should close () fail.
Somehow, I guess it won't.
So, I'm going to flush in DESTROY, yet advise in favor of
explicit flushing in the Perl interface's documentation.
OTOH, there isn't going to be a bunch of easy ways to recover
after a failure, whether it was detected or not.
[...]
>>> Instead of a pointer to the parent object, I'd use a reference to
>>> the corresponding Perl object. This would imply that the parent
>>> won't be destroyed while an iterator referring to it still exists.
>> Indeed, that's what I've meant.
> If you're manipulating these objects from C, you don't need to use a
> Perl array, nor a full Perl reference to the parent object. Just
> create a little structure with an iterator* and a SV* in it, then
> store that structure in the PV slot of the object (that is, not the
> reference, the SV that reference points to).
Indeed, this makes it easier to access the objects from the
C side; and as for the Perl side, I'd only need ->parent (),
which could easily be implemented in XS. Thanks.
> Put the iterator pointer in the iterator member, SvREFCNT_inc the
> parent object (again, the object itself, not the reference pointing
> to it), and put a pointer to it in the SV*. Then, in the iterator's
> DESTROY method, free the iterator and SvREFCNT_dec the parent object
> (and let perl handle cleaning up the structure, since it was the
> 'string value' of the object).
So, I ended up with roughly the following code.
SV *
new (class, parent)
SV *class
SV *parent
CODE:
/* ... should the arguments be sane... */ {
struct wrapped_iter *wr;
/* NB: class != 0, thus defclass = 0 won't do any harm */
RETVAL
= allocate_rv_pvn (sizeof (*wr), class, 0, &wr);
wr->parent
= SvREFCNT_inc (parent);
wr->iter
= iter;
}
OUTPUT:
RETVAL
void
iter_free (iter)
XXX::Iterator iter;
CODE:
SvREFCNT_dec (iter->parent);
iter_free (iter->iter);
/* NB: this one is similar to allocate_struct () in POSIX.xs */
static SV *
allocate_rv_pvn (const STRLEN size, SV *class, const char *defclass,
void **ptr)
{
SV *sv
= newSV (size);
/* turn this into a "valid" PV of the size given */
SvCUR_set (sv, size);
SvPOK_on (sv);
if (ptr) {
*ptr
= SvPV_nolen (sv);
}
/* . */
return
sv_bless (newRV_noinc (sv),
(class
? gv_stashsv (class, GV_ADD)
: gv_stashpv (defclass, GV_ADD)));
}
--
FSF associate member #7257
------------------------------
Date: Sat, 6 Jul 2013 20:38:16 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [XS] DESTROY: free or flush? "related" objects?
Message-Id: <8a8maa-fko1.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> How do I print the diagnostic, then? (I'm considering implementing
> >> ->DESTROY () in the .xs code.)
>
> > Perl_warn, unless you want to offer some more sophisticated form of
> > diagnostic catching.
>
> As die () in ->DESTROY () already seem to turn into a warn (),
> if "use warnings" is in effect, I guess I'd stick to the former.
> (But then, I wonder if Perl_croak () will so behave?)
It does.
> There's another question, however: what's an easy way to
> invalidate the object in an XS DESTROY ()? In Perl, I've seen
> it being done as follows:
>
> sub DESTROY {
> ## .
> return
> unless ($$self);
>
> ## ... clean the things up...
>
> ## .
> $$self
> = undef;
> }
I'm not sure exactly what this is intended to accomplish, since
->DESTROY would not be called at all unless $$self was about to be
destroyed. Possibly it's something to do with the out-of-order
destruction that happens during global destruction, but you should
probably be able to clearly articulate the reason this code is necessary
before including it.
> Now, I try to invalidate the object from within an XS function:
>
> void
> obj_free (obj)
> XXX::Object obj;
> CODE:
> /* ... clean the things up... */
>
> /* FIXME: accessing ST () directly */
You don't need to. 'obj' is a SV* pointing to the right SV, unless
you've got a typemap that maps it to something else, in which case you
want to change the 'XXX::Object' to 'SV *'. You only need to access ST()
directly if you're trying to change which SVs are on the stack.
> sv_setref_pv (ST (0), 0, 0);
>
> However, this appears to be subtly different in that (AIUI) it's
> the reference that gets invalidated, and not just the referent
> SV.
Yes. The equivalent of the Perl above is
SvSetMagicSv(ST(0), &PL_sv_undef);
> (Thus, I cannot, say, XSRETURN_EMPTY early upon seeing such
> a condition.)
I don't understand what you mean here.
Ben
------------------------------
Date: Sat, 06 Jul 2013 16:49:04 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [XS] invalidating the pointers in DESTROY?
Message-Id: <871u7b1vnj.fsf_-_@violet.siamics.net>
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
[...]
> There's another question, however: what's an easy way to invalidate
> the object in an XS DESTROY ()? In Perl, I've seen it being done as
> follows:
> sub DESTROY {
> ## .
> return
> unless ($$self);
> ## ... clean the things up...
> ## .
> $$self
> = undef;
> }
... Specifically, do I understand it correctly that the Perl
code above is nearly equivalent to the following XS code?
void
DESTROY (obj)
XXX::Object obj
CODE:
/* NB: accessing ST () directly here and below */
if (! SvOK (SvRV (ST (0)))) {
/* . */
XSRETURN_EMPTY;
}
/* ... clean the things up... */
/* invalidate the pointer */
sv_setsv_mg (SvRV (ST (0)), &PL_sv_undef);
[...]
--
FSF associate member #7257
------------------------------
Date: Sat, 6 Jul 2013 20:39:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [XS] invalidating the pointers in DESTROY?
Message-Id: <ad8maa-fko1.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>
> > There's another question, however: what's an easy way to invalidate
> > the object in an XS DESTROY ()? In Perl, I've seen it being done as
> > follows:
>
> > sub DESTROY {
> > ## .
> > return
> > unless ($$self);
>
> > ## ... clean the things up...
>
> > ## .
> > $$self
> > = undef;
> > }
>
> ... Specifically, do I understand it correctly that the Perl
> code above is nearly equivalent to the following XS code?
>
> void
> DESTROY (obj)
> XXX::Object obj
> CODE:
> /* NB: accessing ST () directly here and below */
> if (! SvOK (SvRV (ST (0)))) {
SvOK is defined(). Boolean true is SvTRUE, though it makes very little
difference here.
> /* . */
> XSRETURN_EMPTY;
> }
>
> /* ... clean the things up... */
>
> /* invalidate the pointer */
> sv_setsv_mg (SvRV (ST (0)), &PL_sv_undef);
This is the same.
Ben
------------------------------
Date: Sat, 06 Jul 2013 11:24:45 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: clobbering of $@ in DESTROY?
Message-Id: <878v1k0yvm.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>
> [...]
>
> >> It certainly feels more sensible to call "close" in Perl's DESTROY
> >> method, but what do I do if it fails? AIUI, calling die () in
> >> DESTROY is of little use.
>
> ... Unless "use warnings" is in effect, as it seems to turn such
> die () invocations into warn ().
>
> > AFAIK, the only effect is that it possibly clobbers another
> > exception, cf
>
> I wonder if it still is the case in the newer Perl versions?
AFAIK, the behaviour changed with Perl 5.14 and generally 'for the better'.
[...]
> > package A;
>
> > sub new
> > {
> > return bless([], 'A');
> > }
>
> BTW, do I understand it correctly that in order to allow for
> proper subclassing, it should generally be $_[0] // 'A' instead?
In actual code, $_[0] should be used because this means the
constructor can be inherited.
------------------------------
Date: Sat, 6 Jul 2013 23:55:46 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: having trouble with hash of arrays...
Message-Id: <kra08i$j48$1@news.ntua.gr>
(.*)$/
will match the new line like it or not
------------------------------
Date: Sat, 06 Jul 2013 14:05:31 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: having trouble with hash of arrays...
Message-Id: <ja1ht8lj0g2h45cchjti8gnbaosnofsahe@4ax.com>
"George Mpouras"
<nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
>(.*)$/
>
>will match the new line like it or not
No, it doesn't. From "perldoc perlre":
$ Match the end of the line (or before newline at the end)
In so far it is the same as the zero width(!!!) assertion
\Z Match only at end of string, or before newline at the end
which does not match the new line, either.
jue
------------------------------
Date: Sat, 06 Jul 2013 10:54:38 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: speed of subroutine calls in perl
Message-Id: <87bo6fhh75.fsf@new.chromatico.net>
>>>>> "RW" == Rainer Weikusat <rweikusat@mssgmbh.com> writes:
RW> I recently read the 'Lambda: The ultimate GOTO' paper published
RW> by Steele/ Sussman in 1977[*]. While I mostly consider this 'an
RW> entertaining rant', the idea that The Absolutely Dreadful
RW> Function Call Overhead[tm] is rather an urban legend people keep
RW> telling each other seemed plausible to me.
You are aware that processors have gotten considerably faster in the
intervening 36 years, no? You do understand that an overhead of 20
cycles when your cycles per second is measured in the hundreds is
considerably more of a problem than an overhead of 20 cycles when your
cycles per second is measured in the millions?
Or are you going to ask, next, how Bill Gates could *possibly* have
thought 640K would be enough for everyone when your last computer
shipped with 4M?
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3983
***************************************
