Writing A Technical Article, Part 2: Gathering Tools
Probably the biggest difference between academic and commercial writing is this: academic writing is almost always concerned with algorithms and process, commercial writing is almost always driven by a specific set of technologies. In this case, I'm being paid by AMD to explain integration of CodeAnalyst and Eclipse CDT. So that dictates that I'll be using C++, which leads to a couple questions:
- Linux or Windows?
- What C++?
The Linux or Windows question is fairly easy for me to answer: I boot into Windows and run Linux in Virtual Machines. For an article on a profiler, the VM is a complication -- CodeAnalyst works within a VM, of course, but since I expect this article to get down to the hardware, I don't want any confusion about how toasty-warm my code is making my Opterons. So I'll be experiencing the code in Windows. But when writing about Eclipse, surely I should imagine that my target audience is not strictly Windows-based. So it seems logical to set up a compiler-chain based on GNU C++: I know that will be portable. (Note: I'll probably cross-compile with at least Microsoft C++ and compare the experience. That might give me enough information for, if not an article, at least a column.)
Since the article is supposed to emphasize multicore/multichip development and in C++, it's a no-brainer that I'll be using OpenMP. My next thought is unit-testing. For one thing, I just don't develop anything without unit-testing anymore. For another, repeatability is critical to the article. For a third, I expect to hit some hard problems along the way and unit-testing is the best way to maintain momentum in the face of brain-twisters. I have not compared C++ unit-testing frameworks, but \<a href="http://www.boost.org/libs/test/doc/index.html"" target="_blank" rel="noopener noreferrer">Boost has a test component, and while there may well be better, I know that Boost won't be poor.
Version control is not the same issue in an article that it is in professional development, but you can never over-estimate the benefit of a backup: I'll be using \<a href="http://subversion.tigris.org/"" target="_blank" rel="noopener noreferrer">Subversion against a local server.
Since I know that I'll be doing image-processing, I'd just as well use a library or two to handle file-loading and basic pixel manipulation. If I were building an application, I'd definitely tend towards GTK+. However, I want to keep things as simple as possible around the algorithm(s) that I'll be developing, so I'm going to see how far I can get with this project, \<a href="http://cimg.sourceforge.net/"" target="_blank" rel="noopener noreferrer">CImg, which seems nice and minimal.
So my initial tool list is:
- CodeAnalyst : Profiler
- Eclipse CDT : IDE
- GCC : Compiler-chain
- OpenMP : Shared-memory parallel programming
- Boost.Test : Unit-testing
- Subversion : VCS
- CImg : Image-processing library
If I need or change libraries, I'll make mention of it in forthcoming posts.
Next: Part 3, Research Begins...