Archive for April 7th, 2008

Andy Koenig is the expert’s expert, and I rarely disagree with him. And, well, when I do disagree I’m invariably wrong… but there’s a first time for everything, so I’ll take my chances one more time.

I completely agree with the overall sentiment of Andy’s blog entry today:

I spend a fair amount of time reading (and sometimes responding to) questions in the C++ newsgroups. Every once in a while, someone asks a question that makes me cringe.

What makes a question cringe-worthy?

Usually it is a question that implies that the person asking it is trying to do something inappropriate.

Asking how to violate programming-language abstractions is similar: If you have to ask, you probably shouldn’t be doing it.

Amen! Bravo! Absolutely correct. Great stuff. Except that the example in question isn’t violating an abstraction:

For example, I just saw one such question: Are the elements of a std::vector contiguous? Here is why that question made me cringe.

Every C++ container is part of an abstraction that includes several companion iterators. The normal way of accessing a container’s elements is through such an iterator.

I can think of only one reason why one should care whether the elements of a vector are in continuous memory, and that is if you intend to use pointers, rather than iterators, to access those elements. Doing so, of course, violates the abstraction.

There is nothing wrong per se with violating abstractions: As Robert Dewar told me more years ago than I care to remember, some programs are poorly designed on purpose. However, there is something wrong with violating abstractions when you know so little of the data structures used to implement those abstractions that you have to ask strangers on Usenet about your proposed violation. To put it more bluntly: If you have to ask whether vector elements are contiguous, you probably should not be trying to make use of that knowledge.

The reason this analysis isn’t quite fair is that contiguity is in fact part of the vector abstraction. It’s so important, in fact, that when it was discovered that the C++98 standard didn’t completely guarantee contiguity, the C++03 standard was amended to explicitly add the guarantee.

Why is it so important that vectors be contiguous? Because that’s what you need to guarantee that a vector is layout-compatible with a C array, and therefore we have no reason not to use vector as a superior and type-safe alternative to arrays even when we need to exchange data with C code. So vector is our gateway to other languages and most operating systems features, whose lingua franca is the venerable C array.

And it’s not just vector: The TR1 and C++0x std::array, which implements fixed-size arrays, is also guaranteed to be contiguous for the same reasons. (std::array is available in Boost and, ahem, the VC++ TR1 implementation we shipped today.)

So why do people continually ask whether the elements of a std::vector (or std::array) are stored contiguously? The most likely reason is that they want to know if they can cough up pointers to the internals to share the data, either to read or to write, with other code that deals in C arrays. That’s a valid use, and one important enough to guarantee in the standard.

Read Full Post »

Back in November, I reported that we’d be shipping Visual C++ 2008 that month (we did!) and that we’d soon thereafter be doing the “agile thing” and shipping a major update mere months later, instead of waiting two years between releases per our prior tradition. I wrote:

The update is expected to be available in beta form in January 2008, and to ship in the first half of 2008. Enjoy!

Well, it’s official: It’s available. Enjoy! Besides major updates to MFC for the latest Office/VS/Vista look-and-feel to support first-class native code development, it also includes most of TR1 (everything except C99 compatibility, and the special math functions that didn’t make it into C++0x):

TR1 (“Technical Report 1”) is a set of proposed additions to the C++0x standard.  Our implementation of TR1 contains a number of important features such as smart pointers, regular expression parsing, containers (tuple, array, unordered set, etc) and sophisticated random number generators.

More information on TR1 can be found at the sites below:

TR1 documentation

Channel 9: Digging into TR1

TR1 slide decks (recommended)

Enjoy, everyone – and thanks, team!


1. This feature pack requires Visual C++ 2008 Standard or above. The only VC08 edition it doesn’t work with is Express; we’ll support Express in a future release.

2. When I wrote that it would be available “in the first half of 2008,” a number of people seemed to automatically interpret that as code for “maybe around June 31.” We’re not always that bad at shipping, fortunately. :-)

3. Yes, I know that June has 30 days.

Read Full Post »