On Fri, 01 Sep 2000, Dan Sugalski wrote:
> I'm not sure. They're there mainly for guaranteed unfiltered access to the 
> variable's guts, and I'm not sure what things will need that.

I use direct, raw access in prototyping when dipping back into C for
"heavy" data manipulations - bit stream analysis, signals processing,
etc.  Since I'm usually doing a lot of buffer manipulations, I don't
want all the scalar overhead that comes into play.  

Of course, one could argue that that's a completely different subject -
we're talking about calls within perl itself.  Extraction of the raw
data could just as well happen underneath without an interface of any
kind.  But I'd like to bring a lot of that work back up into perl
proper, which, unfortunately, often results in the code running two to
three hundred times slower than native C.  (It's only prototyping, keep
in mind, but I'd like run-times to at least be the same day. :-)

I've been trying (off and on) for a couple of months to hack an
interface to a lightweight buffer from within Perl, to at least allow
some of the cruder constructs without *too* much overlap.  In the end,
though, it still comes down to pointers, arrays of pointers, or pointer
offsets. All of which were still scalars, so it didn't buy too much.

Furthermore, what is "guaranteed unfiltered access", and how can it be
used?  For a Perl 5 string, for instance, would it be the entire
allocated buffer, or the space from the beginning pointer to the end
of the string?  Are you going to be able to manipulate this raw data in
the raw, or are you still going to have to go through perl to work on
it? 

 > 
> >My reason for asking is that the more of the perl core that relies on
> >specific representations of data, the more complexity there is in porting to
> >other architectures.
> 
> Fair enough.  It may turn out to be unnecessary, in which case we'll toss 
> it, or if not we'll just make sure to force some reasonable requirements on 
> it so porting's easier.

I think, through line disciplines or string tags or what-have-you, that
some data should be allowed to be tagged as raw - perhaps to prevent
any automatic promotion, for instance - but actually needing that raw
data underneath is rather incestuous.  If something relies on that data
so much, it knows where to find it.

-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Reply via email to