Letters to the editor may be sent via email to cujed@cmp.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.
Mr. Allison:
I’m sending this email in response to your request for feedback to the December 2001 CUJ Editor’s Forum entitled “What Every Programmer Should Know.” I’m currently a software engineer at a large aerospace company, but I spent a majority of the last fifteen years of my career in high-tech startups, medical systems development, “the phone company,” a software testing firm, and a defunct middleware company. My educational credentials include a BA in Mathematics (C.S. option), a Masters in Computer Information Systems, and a soon to be completed MS in Space Systems Operations Management.
I’d like to suggest that “Computer Science” knowledge isn’t the weak part of a new CS grad’s skills. New grads are great at producing the required mass of code. The real weakness is in what I will call “production skills.” I’ve observed that the things that you really need to be successful are software configuration management “Philosophy,” makefile “engineering,” unit/system test procedure creation/implementation, software development process (CMM & ISO), and documentation development skills. A healthy dose of requirements analysis, systems analysis, and design using UML or similar methodology would also be really beneficial. Project management knowledge is also very valuable. Even if a programmer has no intention of leading a software development project, it is very useful to be able to understand such terms as “critical path” and “predecessor task” in order to understand what must be done and when to do it. It can also be extremely helpful in prioritizing the many tasks each developer faces on a daily basis. I’m in total agreement with your requirement for communication skills. This list is based on my observation of the skills the “really good programmers” I’ve worked with possess.
I’ve observed that new grads can create extremely complex data structure handling routines, utilize very obscure STL features, and write an SQL query that reads like a novel. The problem is that coding is only one (small at that) aspect of the software system creation process. I liken coding and “computer science” skills to fine cooking skills. There are many fine chefs in the world, but it seems very few of them have all the necessary skills to open and run a successful world-class restaurant. It takes more than just cooking skills to do this, and it takes more than just bit-manipulation knowledge to produce “industrial-strength” software.
I look forward to reading the feedback to your December column and thanks for listening.
Martin Sagara
I pretty much closed the book on running responses to that forum, but this one was too good to let go. Thank you, Martin!
Dear CUJ,
I got my first issue from you, it was the January issue, and found this incredibly good Perl stream class from Robert Y. Seward. Unfortunately, the source does not work in a Borland environment, because the compiler does not support nested classes the same way VC++ does.
I wanted to contact the author somehow, but there is no contact address and I could not find any contact either for addressing such problems.
Thank you very much
Christian
Robert Seward responds:
I don’t know much about the Borland environment, but I may be able to help out. Are you saying that Borland does not handle nested classes at all? If that is the case, I may be able to help you out, as I wrote an earlier version without nested classes. Let me know exactly what your problem was, and we can go from there.
Robert
[Borland most certainly supports nested classes, but there always seem to be minor differences among compilers, so trying the non-nested version is good advice. — cda]
Hi,
I recently fell into this trap and thought that others might be interested.
In the case of large classes, it’s not uncommon to see developers list their class methods and data members in alphabetical order to ease finding them. Take the following code:
class A { public: A(); . . private: B aB; BManager aBM; }; A::A() : aBM(), aB(aBM) {}In my scenario, what I wanted was the BManager object to be created first because it was then passed to the B object so that the B object could register itself with the BManager object. I was most confused when this compiled and built, but kept producing segmentation faults caused by the object’s constructor.
Turns out that what I had done wrong was assume that the order of the member initialization was controlled by the order of the initialization list, in the above case, aBM followed by aB. As stated in The C++ Programming Language (Bjarne Stroustrup, Section 10.4.6, Special Edition, Addison Wesley, 2000):
The members’ constructors are called before the body of the containing class’ own constructor is executed. The constructors are called in the order in which the members are declared in the class rather that the order in which the members appear in the initializer list.
Easily fixed in a multitude of ways (one shown below), but I wonder how many others have been caught out? The compiler I was using (yes, I’ll admit it was written in house) didn’t spot it, but do any of the more common ones spot it?
Regards,
Ashley Williams
Yep, it’s just one of those things you have to keep in mind. Most books on C++ style mention as a rule of thumb that you should always list items in an initializer list in the same order as they appear in the class definition. If you have dependencies in the order of initialization (a dubious practice in general), then you must reorder the original declarations. No compiler I know compares the order of initializers to the declared order. — cda
Dear CUJ:
There are so many errors, including unbalanced parentheses, unbalanced brackets, and inaccessible data members, that the code in Mr. Hicks reply to Mr. Marooney’s letter to CUJ in the September 2001 issue is incomprehensible, much less capable of being compiled. The king of the mountain is the line:
set<unsigned int, > indexedthings(f);It goes without saying that Thing::operator()( int x, int y ) having been defined at great and error-crammed length is never called.
Would someone, perhaps Mr. Hicks himself, try to make some sense of the example code given?
Charles Elliott
Dear Mr. Elliott,
I’ve included the syntactically correct and compiled code (Listing 1) along with output (Figure 1). I apologize for allowing the mistakes to appear in the pages of the C/C++ Users Journal.
I will try to explain myself more clearly. Mr. Marooney’s code copied the value, paired it with an index, and stored them in a multimap. Since the original problem specified that we did not want to copy values, I provided a solution similar in spirit to Mr. Marooney’s, but which only stores the index in a set and uses a functor to provide indirect access to the data.
The indirect access and the non-standard compare are combined in the functor’s operator since there is thought to be little chance of reusability. That’s why it is called disposable_ftr.
As for the rest of the letter, I stand corrected about the nature of a priority queue.
Mr. Marooney also asked whether a heap would have any advantages over set and noted that set has logarithmic insertion and deletion times. I mentioned that heap insertion from the bottom looks like it has O(1) time on average. The editor pointed out that it is still O(log N) worst case. While this is true, the average case can very important. It makes little difference if all elements are going to be deleted since then the O(long N) deletion time will become dominant anyway, but if only some of the values (e.g., less than N/log(N) elements) are ever going to be extracted, then an average O(1) insertion time would make the total average operation time O(N) (i.e., linear).
Respectfully Yours,
Craig Hicks
KGK Tokyo
CUJ,
I am an email subscriber to CUJ (vishu_iyer@hotmail.com). I wanted to know whatever happened to R++ — the rules implementation for C++. Is any implementation available at all according to the specification at <www.research.att.com/sw/tools/r++>?
Bjarne Stroustrup replies:
Unfortunately R++ is — as far as I know — inactive and unused. I don’t think that there are any funds for developing or maintaining it at AT&T or Lucent.
Bjarne