Printed C++ Journals
Scott Meyers dropped in on the accu-general mailing list recently to discuss the state of C++ article publishing. I think it’s fair to say that he’s dismayed by the steady decline of printed journals specialising in C++ such as CUJ.
(During the course of the email thread, Scott stated that CUJ used to have a circulation of 40,000. 40,000! Surely that’s enough for a magazine to be viable?)
Despite this decline, ACCU publishes two such journals. These journals don’t just cover C++ — their range extends to pretty much anything relating to programming — but C++ is always strongly represented.
I read the December editions last week and was reminded just why I both subscribe to and write for ACCU. Some things deserve to be read and to be re-read, and I think the printed form serves such thoughtful material well. It’s easier to concentrate on a programming article offline. Sadly, too many online journals drown in the presence of animated adverts.
For me, a couple of articles stood out:
-
“Library Vendors and the Non-Existent C++ ABI”, by Andrew Marlow, which pointed out the madness of trying to deliver compiled C++ libraries.
-
“Pooled Lists”, by Christopher Baus, which provides a succinct masterclass in how to design an STL compliant list offering precision control over bulk memory allocations (and guess what, custom allocators didn’t get a look in).
The Baus article is available online. Why not print yourself a copy?
Feedback
-
Thanks for the kind words. I didn't even know that article got published.
Thanks for the link.
Christopher
-
Many thanks for your kind comments. I am glad people like it. :-)
-Andrew
-
Cheers! It's invidious to select articles in this way, I know, but for me these two did stand out.
In the case of "Pooled Lists": where I work we've found that the standard linked list doesn't cut it for a resource which is 1) very heavily used and 2) recycled. We ended up writing a homemade container, together with custom implementations of the algorithms needed. The pooled list solution is more elegant.
In the case of the C++ ABI article, I agree completely with the conclusions reached -- but I'd never thought the issues through for myself before. I'm increasingly frustrated by the problems (of our own making) caused when executables are separated from the source code from which they derive.
Articles