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.

Correction: the acronyms TCP and UDP were incorrectly defined in a couple of places in the September 2000 issue of CUJ. The correct definitions are Transmission Control Protocol and User Datagram Protocol respectively. We regret the errors. — mb

Alan Nash writes the following with respect to his article, "Introduction to Function Try Blocks," which was published in the October 2000 issue of C/C++ Users Journal:

"As soon as my ‘Introduction to Function Try Blocks' article was out, Herb Sutter pointed out to me that return statements within a function try block handler are not disallowed by the Standard. It turns out I had misread the Standard on this; return statements are only disallowed for constructors.

Thus, several portions of the article are in error, including the code replacing a general function try block and the first paragraph under ‘Recommended Use.' In particular, it does makes sense to use a function try block for a non-void function, although many would recommend against it.

I am sorry for any confusion I might have caused."

Alan Nash

Dear CUJ,

I feel better after hearing that CUJ has no plans to add a C# column.

However, I have a question about that language: why didn't [Microsoft] name it "C@?" Does this imply that they are not really committed to Internet Programming?

I'd love it if Stan Kelly-Bootle would comment on that in one of his coming articles. I'm sure that C# does mean something to the C/C++/Java Programming Community and I fear that recent advances in the Genoma project might bring nearer the days when the pigs fly.

Yours,

Alessandro Vesely

Assuming your question is not facetious, I believe there already is (or was) a programming language named C@, or C@+, or something similar. As far as Stan is concerned, there's never any telling what he may write about, but I'll forward your comments to him. (Some of you may have noticed that his bimonthly column is missing from this month's issue. We have bumped his column schedule by a month; it will now run in the January 2001, March 2001, May 2001, etc. issues of CUJ.) Finally, for the benefit of readers struggling to understand your concern about pigs taking flight, or what that could possibly have to do with C#: at some point in the past I believe I said we'd start a column on Visual Basic "when pigs fly." It was my cute little way of expressing the absurdity of a VB column in CUJ. A C# column would be equally inappropriate for the time being, though not so absurd. Considering the wild things genetic engineers are doing these days, I had better start using a new criterion for absurdity.

Dear CUJ,

I like the new [C/C++ tips] feature. I have a comment on Craig Hicks' tip in the August 2000 CUJ. Mr. Hicks' sort_idxtbl function uses iterators for the range to sort, but it takes an int* as the destination of the data. I find that ironic. Why aren't the sorted indexes written through an output iterator?

Changing the template function to the following will make it more flexible (not to mention more in keeping with the STL design):

template <typename RAIt, typename OutIt>
OutIt sort_idxtbl(
    RAIt first,
    RAIt last,
    OutIt destination);

The type of the output iterator will need to be compatible with the type the loop uses to create the set of indexes to sort. As implemented, the loop uses int for this type, so OutIt::value_type will need to be int or a type convertible from int. However, the loop type should really be V::size_type; or, since V is defined to be a std::vector, it could be simply std::size_t, so OutIt::value_type should be std::size_t or a type convertible from it.

This change allows the function to be used in new ways, such as supplying an ostream_iterator for cout as the third parameter, thus dumping the sorted indexes to the console. What could be easier?

Rob Stewart

Thanks for the meta-tip. We got tons of feedback on the August 2000 tip; see the November 2000 issue for another implementation. I think it's about time to let this one drop and move on to something else. Thanks for writing. —mb

Dear CUJ,

I am sending this letter to both the editor of C/C++ User's Journal (because it is about something I would like to see addressed in the magazine) and Thomas Becker (as author of the new STL column and therefore a potential [writer on this topic]).

I really like the STL container classes and string classes, but I have noticed a problem that never seems to be discussed in books or magazine articles. At most there will be a little note about "binary incompatibility."

The problem has to do with Windows DLLs (Dynamic Link Libraries). Unix has a similar mechanism, so I guess it has a similar problem.

Suppose you have a producer/consumer sort of system: a DLL named PRODUCE.DLL that produces things (by getting stuff from somewhere, for instance news headlines coming in from a distant server) and a consumer named CONSUME.EXE that handles them.

The producer contains something like this:

class Producer {
   std::string getNextString();
   };

and the consumer has this:

while (true) {
   std::string nextString =
      producer->GetNextString();
   mainScreen.display(nextString);
}

There would be no problem if getNextString returned a built-in type such as an int. Also there would be no problem if it returned [an object of] a class that did not allocate resources in its constructor or free any in its destructor. But in this example, the DLL allocates resources which the consumer frees, and that doesn't work.

Early on you learn that as a general rule you can't allocate something in the DLL and free it outside of the DLL. But naively a string seems to be some sort of atomic thing that you can just pass across a DLL boundary, like an int or a pointer to a static zero-terminated character string. (So what's the point of using std::strings (the novice asks)? You might just as well use pointers to static buffers.)

Here is another example:

Producer:

__declspec(dllexport)
std::queue<int> iq;

__declspec(dllexport)
void pushInt(void)
{
   iq.push(nCount—);
}

Consumer:

extern __declspec(dllimport)
std::queue<int> iq;

__declspec(dllimport)
void pushInt(void);

int n = 9999;
while (n > 0)
{
   pushInt();
   while (!(iq.empty()))
   {
      n = iq.back();
      cout << n << endl;
      iq.pop();
   }
}

There are two reasons why this won't work.

1. Functions pop and push use housekeeping information that is contained in the DLL. The consumer doesn't know where this information is; instead it queries and changes some random information in its own space.

2. If the .exe and the .dll were built with different compilers, or even different versions of the STL, there would be even worse incompatibilities.

This implies that even if publish.obj and consume.obj were linked into the same executable, they may not work if they were built with different implementations of the STL.

Okay, you already know all that, and so do I. Why am I complaining about this? Because the problem is not at all obvious to new users of the STL. After all, the STL is part of the Standard library, and you don't have these problems with the rest of the Standard library, do you? In fact the Standard library is in a DLL. (But one compiler manufacturer's run-time library is not compatible with another's.)

COM and CORBA are two solutions to the general problem of binary incompatibility of DLLs. But let's not get into that.

I would like to see an article that tells how to safely use STL containers in projects where several object files (not necessarily compiled by the same compiler) are linked into a single executable; also how to do it when DLLs (or whatever they are called in other operating systems) are involved.

Maybe the answer is "Don't do it; redesign things to use the Interface/Implementation pattern instead." That appears to be a complex solution to a seemingly simple problem, but maybe you can show why the problem is not so simple and the solution is not so complex.

Mark Lutton

Thomas Becker replies:

Mark,

Thank you for your email concerning STL containers and DLLs.

First of all, I should tell you that for the past three years, I have been working on a Windows (NT, 95, 98) application that uses STL containers heavily and is also partioned into a large number of DLLs. This software has now been shipped and is being used by hundreds of people every day.

The main issue you address in your email is the use of heap memory ([allocated/deallocated via] new and delete) across DLLs. When using STL containers across DLLs, this is of course happening all the time. The good news is that in 32-bit Windows programming, this is not a problem anymore at all. Heap memory and DLLs were a big issue in 16-bit Windows, but not anymore. Allocating memory in one DLL and freeing it in another is fine. That's because new and delete get their heap memory through the runtime library, which eventually gets it from the Win32 process heap. Once a DLL has been loaded — and it does not matter whether it has been loaded explicitly or implicitly — all calls to new and delete will go to that one process heap. If there were a problem with that, our application would not even start up. (Note: you must link with the "Multithreaded DLL" version of the runtime library.)

In 32-bit Windows programming, there are in fact very few problems with "programming across DLLs." One obvious thing is that you have to be careful about is retrieving what Windows calls "resources," such as menus, dialogs, etc. However, this is not a very deep issue, and it has nothing to do with STL containers.

So why do some of the STL containers that come with Microsoft Visual C++ not work across DLLs? The reason is really quite simple: there is at least one class in there that uses a static class member in a class template that's in a header file. It is clear that such a thing is not going to work across DLLs. Last time I checked, Microsoft was still shipping that version. However, P.J. Plauger has made a fix available on his website at http://www.dinkumware.com/vc_fixes.html. If you replace the Xtree and Set headers that came with Visual C++ with these new versions, your problems should go away.

If problems with STL containers and Win32 DLLs remain after this fix, I would be very interested to know about them. The best thing is always to send compilable code that exhibits the problem.

Sincerely,

Thomas Becker

A letter to Early Ehlinger, author of the article, "Creating Truly Maintainable Class Factories," which appeared in the November 2000 issue of CUJ:

Hi Early,

Thanks for an interesting article. Like you and many others, I have come up against this problem. I wonder if my solution is a little easier to use and maintain than yours?

Each class that must be "makeable" by the factory has an instance of itself as a static attribute. When this instance is created during startup, it registers with the factory [1], passing an identifier and a pointer to itself. It also has a Make function, which accepts the same parameters as the normal constructor.

The factory is passed a text message (in my example), from which it extracts an identifier. Using the identifier, it retrieves the pointer to the static instance of the appropriate class, and calls its Make function, passing the text message.

Adding new classes is just a matter of copying the .cpp and .h files for an existing class, and changing it to fit. Deleting classes is achieved simply by deleting their source code files and rebuilding.

The whole scheme is just a little tidier than I have described it, but I'm trying to keep my text simple. It works fine, and is portable across operating systems. If you're interested, I can send you some sample code, or answer your questions, if you have any.

Regards,

Steve Merrick

[1] This is the weakest point of this scheme — it must be possible to distinguish between the creation of the one and only static instance, and the creation of an "normal" instance of the class. In my case, it was easy, but this might not always be the case! I used a single constructor, but two would be just as good, if it was easier to do.

Early Ehlinger replies:

Steve,

Thank you for your comments. The only problem with your approach is that C++ does not guarantee that the single static instance will be created during startup. Implementations are free to leave the singleton uninitialized until its first use, which will never occur in the scenario you describe.

I actually used to use the exact solution you propose until I switched compilers and discovered, much to my dismay, that the new compiler optimized away the existence of my singleton because it was never referenced.

Best Regards,

Early Ehlinger

Dear CUJ,

MS Visual C++ v6.0 refuses to recognize the user-defined templated casting operator

template<typename T>
operator T () const

in Fernando Cacciola's variant class (see "An Improved Variant Type Based on Member Templates," CUJ, October 2000, Listing 3). I assume this is semantically valid and I am experiencing a compiler limitation. Has anyone else experienced this, and is there any way around it?

Andrew Becker

I don't know if the following will fix the problems you're experiencing, but Fernando has updated his code to work with VC++ 6.0. He writes:

Dear Marc,

I've been receiving some email from Visual C++ users regarding incompatibilities of the variant code and Microsoft compiler. In particular, reader Jaroslav Bradik worked out all the details of the incompatibilities and as a result I've modified the code for variant.h, variant_cc.h and variant_test.cpp.

I applied the following changes:

1. I changed the functions taking (T v) with (T const& v). I realized that the extra copy (implicit in T v) is unnecessary since the second signature works fine with any type except for references, but variant_t cannot be instantiated with a reference (variant_t<int&>) since it is not designed for that.
2. I added std:: to the throw expression.
3. I removed the header condefs.h and the #pragma hdrstop which slipped into that code but are Borland specific.
4. I applied all the changes as suggested by Jaroslav to make it work under VC++ 6.0. (It doesn't work with VC++ 5.0 as reader Michael Maron found.)

Basically, some functions changed the signature to include an extra dummy parameter to help the compiler with the match lookup and two non-member functions were added. Unfortunately, I had to change the name of the second is_type method, now named is_type_as, because VC++ couldn't resolve the ambiguity.

I haven't adapted the arglist code since that was mostly an example.

Best Regards,

Fernando Cacciola Sierra
s.r.l.
[email protected]

We have updated Fernando's code on our website. (See www.cuj.com/code/updates.html.) —mb

Hi,

I just wanted to drop you a note thanking you for publishing the former columnists from C++ Report. [See "C++ Experts Forum" at www.cuj.com/experts/.] As a former subscriber I am grateful that someone is doing this.

In case you were wondering I am already a (fairly long term) subscriber to C/C++ UJ.

If I could make just one suggestion, would it be possible to send email, as a reminder, that a new set of columns has been posted?

Thanks very much.

Louis A. Russ.

Your wish is our command! We have just started an email newsletter that contains just this sort of information. To subscribe, point your browser to www.cuj.com and follow the simple instructions. — mb