We Have Mail

1. Instead of writing the constructor as

Shape (Shape_base *p) : ptr(p), use() {}

Shape (Shape_base *p) try : ptr(p), use() {...} catch (...) {...}

2. Even simpler: if instead of a pointer the constructor takes an auto_ptr:

Shape::Shape (std::auto_ptr<Shape_base> p)

With either of these changes, the old implementation is exception-safe again, and we don't have to resort to the difficult linked-list implementation.

But then, of course, without the argument given by the authors, we would not have learned about the other implementation.

Sincerely,
Wolfgang Bangerth

Regarding your first point (that p can be deleted in a catch block), yes indeed, it can. But would you even think of doing it if the article had not pointed out the possibility to you? And even if you did think of it, do you think it's simpler?

Regarding the second point, yes, the auto_ptr solution would be simpler. I suspect it would be even simpler to use some kind of counter-pointer class, though--which gets us back to the question of how to do so in an exception-safe way.

Regards,
Andrew Koenig

In the article "Efficient Integer to String Conversions," Dec 2002, the article assumes:

    -1 % 10 equals -1.

I can use some education too. What is that ss_typename_param_k?

Thanks.
Sarwan K. Aggarwal

Sarwan,

I cannot say you are wrong because I do not claim a complete knowledge of every aspect of either C or C++ languages. However, I am very skeptical. I have never heard of such a thing. The code works correctly with all tested compilers for negative numbers over all tested ranges, which include those approaching 0 and approaching XYZ_MIN (the minimum for the particular integer type). The C99 standard states, in section 6.5.5.5, "... the result of % operator is the remainder. ... if the value of the second operand is zero, the behaviour is undefined." The C++98 standard says, in section 5.6.4, roughly the same thing.

According to your stipulated behaviour, what would be the results of the following expressions:

-10 % 10
-1 % 1
-1 % 2

ss_typename_param_k is a pseudo keyword used by the STLSoft libraries. There are a number of these -- including ss_typename_param_k, ss_typename_type_k, ss_typename_type_def_k -- which enable compiler differences to be centralized in the core headers of the STLSoft libraries, rather than cluttering and confusing the rest of the libraries. A full explanation for this and other issues is available at <http://stlsoft.org/ white_papers.html>.

Thanks very much for your interest in the articles and the STLSoft libraries.

Best regards,
Matthew Wilson

Mr. Allison,

I just finished reading your editorial on code quality with interest. I've been in the software field for dangerously close to twenty years, and your comments should have resonated with me as they surely would have even five years ago. At a time in my career when I should be looking to move into management, write a book, or start a company of my own, I am instead looking to get out of software altogether, and inattention to quality is one big reason. I have a growing level of dissatisfaction and frustration with software "engineering." Whenever the subject of software quality comes up, I offer this as-of-yet-undisputed statement: most programmers write terrible code. The codicil is: and almost nobody cares.

The industry pumps out mountains of books, endless seminars, and many papers and articles -- and has for decades -- on this very topic, and it has changed pretty close to nothing. You have the occasional rogue programmer who, like me, is personally offended by bugs and poor design in their own code, but they seem to be more rare than an ethical politician. Lousy code was written when I started and it continues to be written today. Nothing has changed in all these years. None of the formal processes, from ISO to CMM to XP, acknowledges the fundamental truth that the process doesn't create the code.

I think the main reason for poor code is this: you get the behavior you reward, and nobody is rewarding good coding. Heck, nobody knows how to reward good coding. Long hours? Yeah, we know how to reward that. Shipping on schedule? That's easy. Writing code that's robust and easy for the next guy to follow? Uh....

So, I'm going to change careers and take my long years of experience with me.

Gregory K. Miskin

Well put! The fact that no one cares enough has been identified as a crucial problem for some time. I have no idea how to change it. I fault, in part, management's standard bottom-line mentality that overlooks the long-term effect of poor quality. Scott Meyers gives a number of talks on this topic. One is "The Keyhole Problem," describing how myopia leads to poor quality. Another is "Nothing Works and Nobody Cares," which seems to be the situation you and so many many of us lament.

For my part, I am trying to demand quality of my students in the Computer Science Department at Utah Valley State College. But as you say, not too many care.

Thanks for writing, and good luck!

-ca