We Have Mail

Letters to the editor may be sent via email to [email protected], or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.

Chuck,

I just received the latest C/C++ Users Journal in the mail and opened up the Java Solutions supplement (June 2001), containing your article “Threads 101.”

The summary paragraph ends with the following line: “[Java] is the first language to offer portable threading support.”

Surely this must be a mistake! The first language to offer tasking support is Ada, which was standardized in the early 80s. The language was revised and a new standard approved in Febreuary 1995, which achieved another first for Ada: it was the first object-oriented language to have an international standard.

Matt

Ah, yes. That was supposed to read “the first language in widespread use....” Big difference.

Thanks,

Chuck Allison

Dear CUJ,

I read with interest Steve Dewhurst’s article about casts in the April 2001 issue, and I think it should also have addressed the source of the problem, especially with const casts. What we as programmers must ask ourselves when tempted to use a cast is: “Do I need the cast in the first place?”.

Like in Steve’s first example, the cast here may be unnecessary, if:

1. The dealWith function does not modify the object pointed to by its parameter. Here the solution is to change the parameter type to a const Person *.
2. The dealWith function does modify the object pointed to by its parameter, but we can modify the return type from getNextEmployee to be a pointer to non-const.

In the second case if we cannot modify the return type (because it is a library for which we do not have the source code), then we are doomed and we must use the cast.

The great thing about const is that it allows us to express and enforce design decisions in code instead of comments; if we cast it away, we are violating the contract between the function/method and its user. One of the valid uses of casting away const before mutable was introduced was that it allowed us to cast away const in const methods, but even that is deprecated now in favor of mutable members. From that perspective, const casts are rarely necessary.

I have seen a lot of examples of this type of misunderstanding of const, the most common being the overuse of const. All parameters to function/methods are declared const, even pass-by value parameters, regardless of their use for input or output; this of course causes an explosion in the use of casts.

Another common flaw is to misunderstand a pointer to const with a const pointer, for example:

void foo(const char *pc)
{
    char *pnc = const_cast<char *>(pc);

    while(*pnc)
    {
        if(*pnc == ’a’)
           break;
        pnc++;
    }
}

Here the programmer thinks he needs a char * to be able to modify the pointer, but the const char * is fine as long as he does not dereference it and use it as an l-value.

I think it would be interesting to have an article covering this type of topic, since const and const_cast are not usually covered in the same section of the books about C++.

Thank you,

Agustin Vega

Dear Agustin,

Thank you for reading my article with interest. It’s a nice change, since I generally get the feeling that people read my articles with trepidation.

I agree with you that much more can be said about const casts and the psychological profiles of people who employ them, but with limited space I felt it was best to issue a short warning and move on. Clearly, the subject deserves a column to itself. My general advice about const can be summed up with two observations:

1. Anything that can be const should be const.
2. If you have to cast away const, it can’t be const.

A full treatment of const and const safety would then have to examine the nature of const (logical constness vs. bitwise constness), the interaction of const implementations with exception safety and multithreading issues, the effect of const on interface design, and the arcane rules for safe conversions among pointer to pointer (to pointer, ad infinitum) types that contain const qualifiers.

You do bring up a pet peeve of mine: the colloquial use of the term “const pointer” when “pointer to const” is intended. These are, as you point out, very different concepts, and any such usage must be clarified. In the past, I’ve been able to dismiss this usage as a vulgarism employed only by C++ newcomers and managers. Unfortunately, the C++ Standard library uses the term const_iterator in precisely that sense: a const_iterator is an iterator that refers to constant elements, not an invariant iterator.

Thanks again for your comments.

Steve Dewhurst

I just received a complimentary copy of the May 2001 issue of C/C++ User’s Journal. For the first time in the years that I’ve looked at the magazine, for some reason I feel that just maybe this is the time to subscribe. (Never mind the fact that I already subscribe to more magazines than I can read in my waking hours!) The topics on the cover, for the most part, cover issues of specific interest to me, but I think your editorial may be the clincher.

For the first time in years, I hear someone speaking out against the OO approach and, to paraphrase, it does a mind good! I’ve just come off a project where I “inherited” a bunch of code. While perusing the source files, I could see that the project started in a non-Windows environment and migrated to several different operating systems. It evolved and eventually moved into Windows drivers realm. At this point, it was made OO. Not that I am totally against OO — it has its place, but this code could honestly be called an abomination. The whole project had been wrapped into one BIG class! There was no need for globals because everything was visible to the whole class. It violated the basic principles of encapsulation, data hiding, etc. The sloppy coding practice, poor organization, and non-existent comments made it unreadable and un-maintainable. It did very little to convince me that OO may be a “good thing.”

When someone looks at my code, I would hope that they view it as a well-organized implementation of an algorithm performing a specific task in an efficient manner — not as just another “object.”

Thanks for your thoughts,

Pfaltzgraff

Dear Rick,

With respect to your article “Two Classes for Simple Socket Programming” in the C/C++ User’s Journal, May 2001: there is a bug in the design of the receive code that you may wish to know about.

The problem is that TCP is a stream protocol: message boundaries are not preserved. The sender may issue a single send of, say, 123 bytes, which get delivered to the receiver as three receives of, say, 3 bytes, 119 bytes, and 1 byte. TCP and the network can do whatever they want in this regard. In practice, the delivery sizes won’t be as capricious as the example I gave, but you cannot write reliable code without taking the essential stream nature of the protocol into account.

It’s a little odd, since you seem to be aware of the problem. You say “it is possible that the data will not be sent or arrive as a single unit,” but then you write code that expects each unit of data sent to be received as a single unit.

That is to say, you (needlessly) break down the data on the sending side into chunks of size IPC_SR_BUFSIZE-1 bytes, issuing one send for each chunk. On the receiver side, you assume that if a sent chunk of IPC_SR_BUFSIZE-1 bytes is not received as a single unit of IPC_SR_BUFSIZE-1 bytes, you have reached the end of the data stream. This is precisely the error you yourself warned about. You simply cannot assume that when you send IPC_SR_BUFSIZE-1 bytes (or any other number) as one send, the receiver will get exactly that number of bytes in a single receive call.

Assuming a sufficiently small definition of IPC_SR_BUFSIZE, you may not be lucky enough to encounter a problem on the network you tested against. The usual time at which these problems show up is when you move from the original test network (say, a LAN) to a different network (say, involving dialup links with shorter message transfer unit (MTU) size).

A correct implementation has, essentially, two choices:

1) Use a terminator byte, perhaps zero if the data is ASCII text, and receive up to and including that byte.

2) Send a length indication at the head of each message unit.

With either of these, there’s no need to break the data into chunks at the sending side (and in fact it may be less efficient if you do chunk the data, depending on the underlying sockets implementation). All you need to do is to run the receive code until you have received the whole message.

I prefer the length-based approach, since it makes it rather simpler to stop receiving at the right place. (If your client might send more than one request before your server responds, then you not only have to worry about one request getting split, as we have mostly talked about here, but you have to worry about more than one request getting combined.)

I hope this helps clarify the matter!

Dave Porter

Dave,

As you realized, I am well aware that TCP message boundaries are not preserved. In theory, any number of bytes could be sent or received at one time. In reality, however, this is not the case. As you mentioned: In practice, the delivery sizes won’t be as capricious as the example.

The two C++ classes that I present in CUJ are basically a class variation of a C API that was constructed over five years ago and has been in production in various GPL forms in a variety of platforms since. In my stress testing, I have not yet encountered a network that will send or receive less than IPC_SR_BUFSIZE bytes except when there is no more data.

I intentionally designed the classes/API to work like this as (at the time), I felt that the use of a delimiter couples the code to something unnecessary and using the chunk assumption seemed to be the only reasonable solution. I had also considered prefixing the message with a length.

I do not consider this a bug, as in the real world, the situation does not occur. I can modify the C++ classes to use the length approach if you wish. I have no plans, however to incorporate this into Future Lab GPL software.

Rick Smereka

Greetings,

I’m a fairly new subscriber to C/C++ Users Journal, I’m not all that experienced with C++, but I’ve learned a lot from reading it, even though a lot is over my head. I was looking through the suggested books list and I was wondering why Exceptional C++ (by Herb Sutter, Addison-Wesley, 1999) isn’t on the list, I think that book is incredible in its coverage of using exceptions and how to write good, solid code. Every time I pick up that book, I learn something new. The breadth of knowledge of Herb Sutter is amazing, as I’m sure you know since I see his columns in CUJ. Thanks for your time and keep up the excellent work on the magazine.

Regards,

Daniel Longest

Thanks for reminding us that the list is in need of updating! —mm