On Jan 18, 2008, at 11:56 AM, Dave Rolsky wrote: > * How memory management should be done
Mastering the stack and the heap isn't too tough. Refcounting and
garbage collection are difficult topics -- but for XS at least, you
don't have to worry about designing the algo, just managing your SV
refcounts correctly. > * How and when to do funky things with pointers
Pointers are so closely analogous to Perl references, I think you'll
find this to be easier than it seems. > * What is in the std library, how to use it portably, when not to
> use it because it's insecure
Security is a huge, important issue. IMO, if you are writing public
C code, particularly for an environment as hostile as the web, you
need to understand the material this book covers:
Secure Coding in C and C++
Robert C. Secord http://www.cert.org/books/secure-coding/
It's not a beginner book, but it's very, very good. > * C differences across platforms
The thing that spurred me to learn this was having my XS distros fail
on Windows. To solve the problem, I donned the hair shirt: I
installed the free version of MSVC on a Windows box, compiled Perl,
and kept plugging away until everything worked.
The experience was painful and time-consuming. It would be less so
now, since 5.10 compiles with minimal fuss under MSVC 8 (Thank you
Steve Hay!) but ExtUtils::CBuilder still has some frustrating
I don't think there's a good answer for this besides actually going
out and doing the hard work of compiling within unfamiliar
environments yourself. C90 is highly portable, but limiting yourself
to C90 isn't realistic. > * Data structures, particularly how to make a "proper" struct
Not sure what you mean by that. > * How to use the preprocessor sanely
Heh. > And that's not even getting into things like support tools (make)
> or configuration probing, which seems to be an integral part of any
> FS/OSS work in C.
As for configuration programming, take a look a ./Configure.
The main thing that configuration probers do is compile lots of tiny
test programs and see what happens. Do they build successfully?
What do they print? Etc. That's how ./Configure works. It's also
how Autoconf works.
When writing stuff purely for extending Perl, you can pretty much
take advantage of the symbols that ./Configure generates and which
are part of the perlapi.
For other FS/OSS work, most people use Autoconf. However, I didn't
really cotton to Autoconf, so I decided to reinvent that wheel and
wrote a tool called Charmonizer that basically uses C to probe and
configure C. In the process, I learned the wisdom of the Larry Wall
quote "It is easier to port a shell than a shell script" but I also
learned a lot about C. :)
I'm not sure writing my own probing tool was the right way to go, but
it seems to work and maybe someday it will escape into an independent
release. Here's the repository URL if you'd like to browse: http://www.rectangular.com/svn/kinosearch/trunk/charmonizer/
Rectangular Research http://www.rectangular.com/