|No such thing as a small change|
Either I reply to your post or to Re: Use perl type without perl.
The latter would have made more sense I think.
But, reading the OP, nowhere is it indicated that he want to use the perl interpreter at all. Indeed, this " I mean don't invoke perl interpreter or struct." could be construed as saying he doesn't want to.
I took the OP to mean that he would like to use some of the perl data types in a completely non-Perl piece of code. Just (say) as a convenient source of an efficient hash implementation. And to that end, it ought to possible to use them without perl contexts coming into it at all.
The fact that it isn't possible is symptomatic of one (of many) of the anachronisms in the way the perl sources are laid out.
(Guessing) 80% or more of perl internal functions that receive and pass-through a perl context handle, make no use of it.
And (again guessing) other than to pass it on to perl internal functions they call, 90%+ of user XS functions make no use of the context handle they get passed.
Only those function that need the perl context should ever need be aware of it. They can retrieve it from TLS on-demand.
But apparently, TLS is so inefficiently implemented under pthreads, it is cheaper to tie up a register in every function, than to have the the 10% than need access to fetch it on demand.
I was completely baffled by your reference to GObject at first, but now I'm guessing that you are suggesting that if the OP wants a ready source of a hash implementation, GLib comes with one he might find more convenient than perl's? That could be more clearly stated.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.