Visual C++ Team Blog : Dev

Channel 9 Video: Stephan T. Lavavej - Everything you ever wanted to know about nullptr

vcblog — Tue, 27 Oct 2009 16:11:00 GMT

Stephan T. Lavavej is back in front of the Channel 9 cameras once again for a discussion on our recently implemented C++0x feature “nullptr”. In a previous channel 9 appearance, Stephan spoke about the C++0x language and library features we were implementing for VS2010 and the various interdependencies between various features (for example, how rvalue references – a language feature – enable move semantics and perfect forwarding in our Standard Template Library implementation – a library feature.) In this video Stephan describes how rvalue references exposed a few loopholes in the C++ type system around the NULL macro (or more specifically around the value of the NULL macro, the integer constant 0, and how this value is treated “differently” by the compiler to other integer constants.) The issue had already been identified by the C++ Language Committee and a solution had been added to the C++0x language specification (the aforementioned “nullptr”). And to add even more good news, customers can see and use this feature (and all our other C++0x Features) in the Visual Studio 2010 Beta 2 which was released this week. We hope you enjoy Stephan’s latest theatrical release.

Thanks

Damien

The Mallocator

vcblog — Fri, 29 Aug 2008 00:51:00 GMT

A common question from programmers who have an intermediate amount of experience with using the STL is, "How do I write an STL allocator?". Writing an STL allocator is not especially difficult - only two member functions are interesting, allocate() and deallocate(). However, STL allocators must satisfy a number of other requirements (given by section 20.1.5 of the International Standard for C++, ISO/IEC 14882:2003), and the code to do so takes roughly 80 editor lines. Figuring out the code from the requirements can be overwhelming, but once you see the code, it's easy.

One thing some programmers try is to derive from std::allocator. I recommend against this; it's more trouble than it's worth. Looking at std::allocator's implementation is also painful.

Therefore, I've written an example STL allocator, whose purpose in life is to wrap malloc() and free(), which I've imaginatively called Mallocator. I've carefully implemented all of the integer overflow checks and so forth that would be required in real production code. And I've exhaustively commented which parts of Mallocator are boilerplate (common to all, virtually all, or all stateless allocators), and which parts you would have to customize. Hopefully, this should demystify the implementation of STL allocators:

C:\Temp>type mallocator.cpp

// The following headers are required for all allocators.

#include <stddef.h> // Required for size_t and ptrdiff_t and NULL

#include <new> // Required for placement new and std::bad_alloc

#include <stdexcept> // Required for std::length_error

// The following headers contain stuff that Mallocator uses.

#include <stdlib.h> // For malloc() and free()

#include <iostream> // For std::cout

#include <ostream> // For std::endl

// The following headers contain stuff that main() uses.

#include <list> // For std::list

template <typename T> class Mallocator {

public:

// The following will be the same for virtually all allocators.

typedef T * pointer;

typedef const T * const_pointer;

typedef T& reference;

typedef const T& const_reference;

typedef T value_type;

typedef size_t size_type;

typedef ptrdiff_t difference_type;

T * address(T& r) const {

return &r;

}

const T * address(const T& s) const {

return &s;

}

size_t max_size() const {

// The following has been carefully written to be independent of

// the definition of size_t and to avoid signed/unsigned warnings.

return (static_cast<size_t>(0) - static_cast<size_t>(1)) / sizeof(T);

}

// The following must be the same for all allocators.

template <typename U> struct rebind {

typedef Mallocator<U> other;

};

bool operator!=(const Mallocator& other) const {

return !(*this == other);

}

void construct(T * const p, const T& t) const {

void * const pv = static_cast<void *>(p);

new (pv) T(t);

}

void destroy(T * const p) const; // Defined below.

// Returns true if and only if storage allocated from *this

// can be deallocated from other, and vice versa.

// Always returns true for stateless allocators.

bool operator==(const Mallocator& other) const {

return true;

}

// Default constructor, copy constructor, rebinding constructor, and destructor.

// Empty for stateless allocators.

Mallocator() { }

Mallocator(const Mallocator&) { }

template <typename U> Mallocator(const Mallocator<U>&) { }

~Mallocator() { }

// The following will be different for each allocator.

T * allocate(const size_t n) const {

// Mallocator prints a diagnostic message to demonstrate

// what it's doing. Real allocators won't do this.

std::cout << "Allocating " << n << (n == 1 ? " object" : "objects")

<< " of size " << sizeof(T) << "." << std::endl;

// The return value of allocate(0) is unspecified.

// Mallocator returns NULL in order to avoid depending

// on malloc(0)'s implementation-defined behavior

// (the implementation can define malloc(0) to return NULL,

// in which case the bad_alloc check below would fire).

// All allocators can return NULL in this case.

if (n == 0) {

return NULL;

}

// All allocators should contain an integer overflow check.

// The Standardization Committee recommends that std::length_error

// be thrown in the case of integer overflow.

if (n > max_size()) {

throw std::length_error("Mallocator<T>::allocate() - Integer overflow.");

}

// Mallocator wraps malloc().

void * const pv = malloc(n * sizeof(T));

// Allocators should throw std::bad_alloc in the case of memory allocation failure.

if (pv == NULL) {

throw std::bad_alloc();

}

return static_cast<T *>(pv);

}

void deallocate(T * const p, const size_t n) const {

// Mallocator prints a diagnostic message to demonstrate

// what it's doing. Real allocators won't do this.

std::cout << "Deallocating " << n << (n == 1 ? " object" : "objects")

<< " of size " << sizeof(T) << "." << std::endl;

// Mallocator wraps free().

free(p);

}

// The following will be the same for all allocators that ignore hints.

template <typename U> T * allocate(const size_t n, const U * /* const hint */) const {

return allocate(n);

}

// Allocators are not required to be assignable, so

// all allocators should have a private unimplemented

// assignment operator. Note that this will trigger the

// off-by-default (enabled under /Wall) warning C4626

// "assignment operator could not be generated because a

// base class assignment operator is inaccessible" within

// the STL headers, but that warning is useless.

private:

Mallocator& operator=(const Mallocator&);

};

// A compiler bug causes it to believe that p->~T() doesn't reference p.

#ifdef _MSC_VER

#pragma warning(push)

#pragma warning(disable: 4100) // unreferenced formal parameter

#endif

// The definition of destroy() must be the same for all allocators.

template <typename T> void Mallocator<T>::destroy(T * const p) const {

p->~T();

}

#ifdef _MSC_VER

#pragma warning(pop)

#endif

int main() {

using namespace std;

cout << "Constructing l:" << endl;

list<int, Mallocator<int> > l;

cout << endl << "l.push_back(1729):" << endl;

l.push_back(1729);

cout << endl << "l.push_back(2161):" << endl;

l.push_back(2161);

cout << endl;

for (list<int, Mallocator<int> >::const_iterator i = l.begin(); i != l.end(); ++i) {

cout << "Element: " << *i << endl;

}

cout << endl << "Destroying l:" << endl;

}

C:\Temp>cl /EHsc /nologo /W4 mallocator.cpp

mallocator.cpp

C:\Temp>mallocator

Constructing l:

Allocating 1 object of size 4.

Allocating 1 object of size 12.

l.push_back(1729):

Allocating 1 object of size 12.

l.push_back(2161):

Allocating 1 object of size 12.

Element: 1729

Element: 2161

Destroying l:

Deallocating 1 object of size 12.

Deallocating 1 object of size 4.

To explain this output:

The object of size 4 is the aux object.

The objects of size 12 are doubly-linked list nodes.

In VC's implementation, default-constructed lists allocate a sentinel node, which is where end iterators point. (End iterators have to be decrementable, so they can't point at NULL.)

Stephan T. Lavavej

Visual C++ Libraries Developer

Channel 9 video: STL Iterator Debugging and Secure SCL - Stephan T. Lavavej

vcblog — Mon, 16 Jun 2008 21:08:00 GMT

Hello

Stephan has just completed his latest channel 9 video, this one on debugging in our implementation of the STL: http://channel9.msdn.com/shows/Going+Deep/STL-Iterator-Debugging-and-Secure-SCL/. This topic gets a little confusing as we have two technologies available here, namely Iterator Debugging and Iterator Checking – if you are occasionally confused by exactly what is the difference (and when should you use one or the other) then this video is for you.

You can also see Stephan’s Channel 9 video on TR1 here: http://channel9.msdn.com/shows/Going+Deep/Stephan-T-Lavavej-Digging-into-C-Technical-Report-1-TR1/

Thanks Damien

Visual C++

Channel 9: Ale Contenti and Louis Lafreniere - Understanding Exceptions and When/How to Handle Them

vcblog — Fri, 21 Sep 2007 23:32:00 GMT

During Ale Contenti's first Channel 9 video (VC++ Safe Libraries and More) he was asked how the Safe CRT worked with exceptions. This was a great question, but too much to handle at the time. Ale suggested the topic was worth a whole other video...and so here it is! Ale is joined in this video by Louis Lafreniere (developer on the backend) to give you the whole picture - including how exception handling is implemented (even describing the variations caused by different hardware) and optimized. You can find the new video here.

This video is deep, and at 55 minutes fairly long, so get a fresh coffee, allocate some time and sit down to enjoy this one.

Thanks Damien

What Compiler Does the Compiler Team Use...and Decoding Version Numbers

vcblog — Wed, 05 Sep 2007 01:09:00 GMT

Hi: Jonathan Caves here. Recently I received some queries from users wanting to know what version of the Visual C++ compiler I use in my daily work. Well...that’s not really a simple question as I tend to use several different versions of the compiler.

<aside>

Before I proceed a little aside on decoding the Visual C++ compiler version numbers. The compiler version number is usually something like:

xx.xx.xxxxx.x

The first two digits is the major version number of the compiler . This number stretches way back to the first C compiler that was shipped by Microsoft: some highlights along the way are:

6 - the last standalone C compiler

7 - Microsoft C/C++ - which included the first C++ compiler

8 - the first release of Visual C++

12 - Visual C++ 6.0

13 – Visual C++ .NET 2002

15 – Which will Visual C++ 2008

The next two digits are the minor version number. These are usually ‘00’ except for products like Visual C++ 4.2 and Visual C++ .NET 2003 (which was 13.10).

The next 5 digits are the build number. This is a number that uniquely identifies one build of the compiler from another it is incremented on a daily basis. For example: today’s build number is 20904: which you can decode as follows:

2 => year: but it is not a direct mapping: currently in DevDiv the base year is 2005 so ‘2’ maps to 2007

09 => month: September

04 => day

The latest set of one or more digits are used to identify Service Packs, etc.

</aside>

For building I use the version of the compiler that the DevDiv build lab uses for the full product nightly build – this is currently build 15.00.20816.0 (which if you followed the explanation above you can see is a build from the middle of August). Using this build is important because I need to ensure that I can build the compiler using the tools that the build lab uses.

For testing I use a set of tools that I build on my machine – so I using a compiler that is only one or two days old (doing a full C++ compiler build takes at least 2+ hour even on a very fast machine so I tend not to do it every single day). Using a really fresh compiler is important as I want to ensure that I have all the recent changes that have been made to the compiler – just in case there is some weird interaction between my fix and some other recent change.

But this is only for Visual C++ 2008 targeted tasks. I am also currently responsible for handling all the QFE (Quick Fix Engineering) requests for the compiler so I also have on my machine Visual C++ 2008 Beta-2 (15.00.20706.01) Visual C++ 2005, both the original release (14.00.50727.42) and SP1 (14.00.50727.762) and Visual C++ 2003.

We also get bug reports from users against older versions of the compiler – so I also have Visual C++ .NET 2002 and Visual C++ 6.0 on my machine so I can compare whether or not code used to compiler with older versions of the product. Sometimes this ‘software archeology’ can take me back even further: recently a customer wanted confirmation that a bug only existed in Visual C++ 5.0 release so I had to find and install Visual C++ 4.2 and Visual C++ 5.0 and then I was able to confirm that the customer was correct – this specific bug only existed in Visual C++ 5.0.

On top of all this I also have to deal with builds of the compiler for x86, x64 and Itanium (the latter two come in both native and cross-compiler variants). So you can see that I don’t actually use a single version of the compiler tools and, with the exception of tools that we have released, I tend not to stick to a single version for very long. This may seem complicated (and it can be at times) but it does really help to ensure that the compiler we finally ship has been tested as thoroughly as possible.

I also use the Visual Studio IDE – though I don’t update this as often as I do the compiler tools (mostly because it take awhile to uninstall the old version and install a new version). Currently I am still using the Beta-2 release of the IDE but I do hope that if I find 1 hour of calm in the next week or so I can upgrade to a new release. I like to use a relatively recent version of the IDE so I can provide quick feedback to the IDE team on what I like and what I don’t like.

Thanks,

Jonathan

Visual C++ Code Model

vcblog — Fri, 17 Aug 2007 20:13:00 GMT

Hi, my name is Vytautas Leonavičius, and I'm recent addition to VC++ IDE dev team. My focus areas are VC Wizards and VC++ Code Model (CM). Today, I’d like to talk about future of the CM.

In a sentence (actually, two sentencesJ), the VC++ CM is a collection of classes that allows a client to get source code reflected in objects. Objects have read and write properties, so, for example, VCCodeClass.Name allows you to get the name of the class. It also allows you to rename a class by assigning a different value to Name property. More on the VC++ CM can be found in MSDN: http://msdn2.microsoft.com/en-us/library/t41260xs(VS.80).aspx

The VC++ CM is used by various Visual Studio components. In particular, VC++ Wizards and Class Designer use it. Such an architecture greatly simplifies those components by deferring source code manipulations to the CM.

Currently C++ Intellisense, Class View, CM and other components use the NCB as an underlying database. As Jason mentions in his post http://blogs.msdn.com/vcblog/archive/2006/08/16/thoughts-on-the-visual-c-abstract-syntax-tree-ast.aspx , in VC10, we’re moving to a new architecture. We’re expecting to improve the following aspects of CM:

· As CM is based on NCB today, it has to do additional C++ code parsing. This is primarily caused by a limitation of NCB architecture, where no column information is provided for source code elements (a C++ program can be written in one line). The new architecture will provide column information. Methods doing a lot of text processing, like VCCodeElement.StartPointOf, will become faster.

· The NCB had not been originally designed to support templates and namespaces. Although NCB supports both today, the support is far from perfect. That causes processing overhead in the VC++ CM and various correctness issues. The new architecture is designed from scratch and takes into account modern C++ coding realities.

· The NCB contains a snapshot of source code in one macro state. That means, if we have code like:

#define X

#ifdef X

class A {};

#else

class B {};

#endif

only class A will make it to NCB. The new architecture is based on different principles. The database will contain both definitions and the CM will be able to provide a true reflection of source code in this scenario.

· VCCodeElement.CodeElementFromFullName/ VCCodeElement.CodeTypeFromFullName will support wildcards.

· We expect VCCodeModel.Synchronize to become faster, because population of the underlying database is going to be based on different principles than it is today.

The VC++ team is looking forward to hear your feedback. Any suggestions, comments and feedback about what we can do to make VC++ Code Model better are welcome.

Vytas/Visual C++

The Future of the C++ Language

vcblog — Fri, 10 Aug 2007 22:48:00 GMT

Hello, world! Today, I (Stephan T. Lavavej, library dev) would like to present one question and one Orcas bugfix.

First, the question: What is the future of C++? Or, phrased crudely, does C++ have a future? Will it grow and evolve, with programmers using it in new application domains and finding ways to use it more effectively? Or will it stagnate, with programmers using it in fewer and fewer application domains until nothing new is being invented with it and it enters "maintenance mode" forever? After C++'s explosive growth over nearly the last three decades, what is going to come next?

This question has a finite horizon. No language can possibly be eternal, right? (Although C is certainly making a good run for it.) I don't expect C++ to be vibrant in 2107, or even 2057. 50 years is an almost incomprehensible span of time in the computer industry; the transistor itself is turning 60 years old this year. So when I ask, "what is the future of C++?", I'm really asking about the next 10, 20, and 30 years.

Here's how I see it. First, consider C++'s past. As it happens, Bjarne Stroustrup recently released an excellent paper covering C++'s recent history, "Evolving a language in and for the real world: C++ 1991-2006", at http://research.att.com/~bs/hopl-almost-final.pdf . There's also a wonderful 1995 interview with Alexander Stepanov at http://stepanovpapers.com/drdobbs-interview.html which explains C++'s machine model.

C++'s machine model has a relentless focus on performance, for several reasons. Being derived from C, which was "fat free", is one reason - in the realm of performance, C++ has never had to lose weight. It's just had to avoid gaining weight. Additions to C++ have always been structured in such a way as to be implementable in a maximally efficient manner, and to avoid imposing costs on programmers who don't ask for them. (As the Technical Report on C++ Performance, now publicly available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c043351_ISO_IEC_TR_18015_2006(E).zip , explains, exception handling can be implemented with the "table" approach, which imposes minimal run-time overhead on code that doesn't actually throw. VC uses the "code" approach on x86 because of historical reasons, although it uses the "table" approach on x64 and IA-64.) Historically, C++ ran on very small and slow machines that couldn't bear any unnecessary costs. And now, C++ is used to tackle huge problems where performance is critical, so unnecessary costs are still unthinkable!

Aside from the elevator controllers and supercomputers, does performance still matter for ordinary desktops and servers? Oh yes. Processors have finally hit a brick wall, as our Herb Sutter explained in 2005 at http://gotw.ca/publications/concurrency-ddj.htm . The hardware people, who do magical things with silicon, have encountered engineering limitations that have prevented consumer processors from steadily rising in frequency as they have since the beginning of time. Although our processors aren't getting any slower, they're also not getting massively faster anymore (at least, barring some incredible breakthrough). And anyways, there isn't plenty of room at the bottom anymore. Our circuits are incredibly close to the atomic level, and atoms aren't getting any smaller. The engineering limit to frequency has simply arrived before the physical limit to circuitry. Caches will continue to get larger for the foreseeable future, which is nice, but having a cache that's twice as large isn't as nice as running everything at twice the frequency.

As programmers, we are faced with a future that looks radically different from what we're used to: the processors we have today are about as fast as we will ever have. The computer industry undergoes constant change, of course, but we rather liked the kind of change that made our programs run twice as fast every couple of years with no extra work on our part.

Undaunted, the hardware engineers have begun putting multiple cores in each processor, which is actually increasing overall performance quite nicely. (I'd sure like to have a quad-core machine at work!) But not everything is as embarrassingly parallel as compiling. Single-core performance still matters. And the problems that we, as programmers, are asked to solve are getting bigger every year, as they always have.

Therefore, I say that C++ is uniquely positioned to weather this performance storm. Other languages will continue to find uses in application domains that aren't performance-critical, or that are embarrassingly parallel. But whenever the speed at which an individual core crunches stuff matters, C++ will be there. (For example, 3D games. When Halo Infinity is released in 2027 - and yes, I totally just made that up - I fully expect it to be written in C++.)

Among C++0x's biggest core language changes will be variadic templates, concepts, and rvalue references. The first two will make writing templates a lot more fun. That's great, because templates are a powerful way to produce highly efficient code. And the third will address one of the flabbiest areas in C++03 - its tendency to make copies of values. (Things that have value semantics are great - unnecessary copies aren't.) By eliminating unnecessary copies through "move semantics", rvalue references will make value-heavy code, like any code that uses the STL, significantly faster. The future is bright!

Why am I thinking about performance? Well, because one of my fixes has reduced the performance of the Standard Library. Before you scream in agony, let me explain...

In my first VCBlog post, I mentioned that I was working on something which has since been checked into Orcas (VC9). I call it The Swap Fix. To recap, Visual Studio 2005 (VC8) introduced new iterator debugging and iterator checking features. Iterator debugging, enabled by _HAS_ITERATOR_DEBUGGING, performs powerful correctness verification. Iterator checking, enabled by _SECURE_SCL, performs minimal checks that serve as a last line of security defense. For example, _SECURE_SCL will terminate a program that triggers a heap overrun with a vector iterator.

All that is explained by MSDN documentation. The story behind this is interesting. The _HAS_ITERATOR_DEBUGGING functionality was provided by Dinkumware, the company that licenses their most triumphant implementation of the Standard Library for inclusion in Visual Studio. The _SECURE_SCL functionality was added by Microsoft, in order to improve the security of programs running on Windows. In order to perform their checks, both _HAS_ITERATOR_DEBUGGING and _SECURE_SCL make iterators contain additional data members, such as pointers to their parent containers. _HAS_ITERATOR_DEBUGGING, because it is enabled by default in debug mode (and not obtainable in release mode), also builds singly linked lists that allow containers to refer to all of their iterators. This is expensive performance-wise, but performance is not critical in debug mode, and this enables excellent checks.

_SECURE_SCL, because it is enabled by default in release mode, strives to impose minimal performance penalties. Therefore, when it is enabled, although iterators have pointers back to their containers, containers don't have pointers to their iterators. (Updating "iterator lists" is too time-consuming for release mode.)

Now, VC8 RTM/SP1 had a bug when _HAS_ITERATOR_DEBUGGING was disabled and _SECURE_SCL was enabled (e.g. the default for release mode). When you have persistent iterators into two containers, and then swap the containers, the Standard requires that the iterators remain valid (23.1/10). Unfortunately, the parent pointers that _SECURE_SCL added to iterators were broken by such a swap. (The containers being swapped have no way to find the iterators which point into them.) Dinkumware's _HAS_ITERATOR_DEBUGGING is immune to this problem since it can walk the iterator lists and update all of the parent pointers. This option is not available to _SECURE_SCL.

In order to fix this conformance bug, The Swap Fix in Orcas makes every Standard container own an additional dynamically allocated object, imaginatively called "the aux object". Each container holds a pointer to its aux object, which holds a pointer back to the container. Each iterator, instead of holding a pointer directly to its parent container, now holds a pointer to its parent container's aux object. It's true: everything can be solved by an extra level of indirection. When containers are swapped, they also swap their aux objects. This allows the containers to "tell" their iterators their current location, without having to know where they all are. The result is that VC9 will be conformant even under _SECURE_SCL.

The performance issue is that the aux object, while unavoidable (without "pimpling" the containers, which would probably be even more expensive for performance), is not free. Each Standard container is now larger because it has to hold a pointer to its aux object. The aux object has to be dynamically allocated, occupying more space and taking more time. And _SECURE_SCL has perform a double indirection when going from an iterator to its parent container. I've measured the cost of the double indirection, and it is nontrivial: programs that use iterators in deeply nested loops may run at half the speed as before. (In general, only hand-written loops will be significantly affected. The Standard algorithms perform checking once and then "uncheck" their arguments for increased speed. It's yet another reason to avoid hand-written loops!) Most programs should not experience noticeable performance changes because of this fix, and some programmers' lives will be made easier because of the increased conformance, but other programmers will have to deal with the fallout of The Swap Fix. That's why I write it with capital letters.

This is something to keep in mind: although performance is important, it is not all-important. Correctness and security trump performance. _SECURE_SCL increases security, and this fix is necessary to restore correctness. The performance in VC8 was an illusion, since it was obtained at the cost of correctness. Orcas's performance will reflect the true cost of _SECURE_SCL. As before, programs will be able to turn off _SECURE_SCL in order to extract maximum performance. How to disable _SECURE_SCL (and _HAS_ITERATOR_DEBUGGING) properly might be a topic for a future blog post - it's easy to do incorrectly, and we're thinking about ways to make this process more robust in Orcas + 1.

STL

MFC Updates for Vista Common Controls

vcblog — Thu, 22 Mar 2007 03:31:00 GMT

MFC has been updated for Visual Studio codename Orcas to handle the new common controls/messages/flags added in Windows Vista. We have made a number of updates to MFC to wrap the new controls and messages, so when you’re using these new capabilities, MFC will make it easier to code them.

Three new MFC classes have been added to wrap new controls (from Windows XP and Vista):

· The CPagerCtrl MFC class wraps a ‘SysPager’ control window. The pager control is a control container which has scrollers, so it can contain more controls than there is visible space for.

· The CNetAddressCtrl MFC class wraps a ‘msctls_netaddress’ control window. The network address control is essentially an edit control with network address validation built in, so IPv6, IPv4, and DNS names can be validated by the control rather than by user code.

· The CSplitButton MFC class wraps a button window when it has the BS_SPLITBUTTON style. This is a button with a drop-down attached, so variants of a command can be added to a drop-down menu attached to the button.

Several MFC classes have been updated with methods to wrap new messages (from Windows XP and Vista):

· The CMonthCalCtrl class has 19 new methods, including support for setting various calendar views(month/year/decade/century) and support for calendar borders.

· The CButton class has 15 new methods, including support for the “split-button” and “command-button” styles in Vista.

· The CTreeCtrl class has 15 new methods, including support for expanded images and extended item states.

· The CListCtrl class has 14 new methods, including complete support for group methods and item-index methods.

· The CToolBarCtrl class has 9 new methods, including support for padding and pressed image lists.

· The CProgressCtrl class has 8 new methods, including support for marquee mode, colors and states.

· The CEdit class has 7 new methods, including support for “highlighting” behavior added in Vista and “cue banner” behavior added in Window XP.

· The CComboBox class has 5 new methods, including support for “cue banner” behavior added in Windows XP.

· The CDateTimeCtrl class has 5 new methods, including support for changing the style of the child calendar control.

· The CHeaderCtrl class has 5 new methods, including support for a dropdown from the column header.

· The CReBarCtrl class has 4 new methods, including support for setting band width and extended styles.

· The CToolTipCtrl class has 4 new methods.

· The CSliderCtrl class has 2 new methods.

· The CStatusBarCtrl class has 1 new method.

· The CAnimateCtrl class has 1 new method.

· The CLinkCtrl class has 1 new method.

MFC has been updated to handle the new Vista Aero “look-and-feel”. This includes support for automatically or manually hiding the main menu bar in an application, which is suggested if other UI elements such as toolbars duplicate most of the UI in the main menu bar.

MFC has also been updated to use the new file opening and saving dialogs that are the standard in Vista. This is as simple as recompiling your application with MFC. If you are using CFileDialog to get an open or save dialog, your application will automatically use the new Vista dialogs and gracefully degrade to using the old dialogs on previous versions of Windows.

That pretty much covers the updates to MFC.

Also note that Spy++ has also been updated to handle the new Vista controls and messages, so you can use it effectively in tandem with MFC. An article about those updates will be posted soon.

Thanks, and we welcome any questions you might have about MFC, or feature requests for future versions.

Pat Brenner

Visual C++ Libraries Team

Visual C++ Compiler Plans

vcblog — Fri, 30 Jun 2006 03:56:00 GMT

Hi: my name is Jonathan Caves and I’m a developer on the Visual C++ Compiler Team. I thought I'd take a few moments to let you know about the plans our team has for the next release of Visual C++.

After the last release of Visual C++ we took a long, hard look at the compiler source base and decided we needed to take the time to seriously invest in reworking our existing code base - some parts of which are over 20 years old. We have plans to really improve the development process for both our existing native C++ customers as well as our newer C++/CLI customers. Unfortunately these changes are going to take time to implement and we definitely can't do anything in the next release (called Orcas) which has a short development cycle.

So instead of working on the next release of Visual C++ most of the compiler development team will be full steam ahead working on the future generation compiler - we are not yet sure exactly what form this compiler will take but we do know that it will really improve and re-energize the C++ development process.

This does bring up the question of what C++ compiler enhancements will be in Orcas? Notice I said "most of the compiler development team" as we are not putting the whole team on the future generation compiler - instead we have left one developer, yours truly, to work on the current source base. We know that C++ is still one of the most widely used programming languages and that we can't just let the current Visual C++ compiler stagnate so I'll be working on keeping it ticking. This is mostly going to involve bug fixing (and I hope that most of the bugs I fix will be ones reported by our customers) though I also think that I may find time for a few small features!

One thing we did after Whidbey, as part of analyzing our source base, was to categorize the remaining bugs in the database. This analysis showed some areas of the C++ language in which the compiler support was less than what we would have wished it to be. We made an effort to address these areas and in some cases we think we can get this work into the next release of the compiler. One example is the interaction between friend functions and templates. In many other cases, however, the work became so big (like rewriting the code that handles the parsing of qualified-names) that we decided to just move it to the 'future' compiler. Going forward I know of other 'problem' areas in the compiler that I am pretty certain can be addressed without needing major reconstructive surgery.

But these small features aside, most of the work on the compiler for the next release is going to bug-fixing and I know from interacting with many of you over the last few years that you’ll be quite happy about this. I’m sure you'll welcome a compiler that doesn't introduce a lot of new features and instead focuses on improving the quality of what we have. So if you have a serious bug you feel we need to address you should definitely open an issue on the Product Feedback site but please be aware that I am only one person and so, unfortunately, I won't be able to fix each and every bug. I can assure you though that as a team we will focus on the bugs we believe have the greatest impact - like compiler crashes (especially without any error message), bad code generation, blocking issues, etc.

I would welcome any feedback on this plan so feel free to add your comments below.

Jonathan Caves

Visual C++ Compiler Team

Hello from the trenches of Orcas

vcblog — Mon, 12 Jun 2006 19:36:00 GMT

Hi! My name is Martyn Lovell, and I’m the development lead on the Visual C++ Libraries team. You might have seen me blog before, (though I never seem to manage to get regular enough). You might also have caught me recently on video on Channel 9. I wanted to give everyone a quick update on the kinds of things my team is looking at right now [you should see blog entries from many of them in the coming weeks]. Remember, I’m discussing things here that haven’t yet met the quality we need for shipping, so things could change or disappear before we ship.

We’re in the middle of the first development milestone for Orcas. If you’re an avid blog-reader, you’ve probably already heard that we’re running our development process a little differently this time, in an attempt to be more agile. We’re putting each piece of functionality into its own ‘feature branch’, where it has to live until it is at a standard that is free of known bugs and much closer to ready to ship. A small set of developers/testers and others focus on the feature until it’s done (we call them a ‘feature crew’) We hope this will keep our shipping branches at a higher quality, and also ensure that things don’t make it into the product until we know they are in good enough shape to not delay our release. Of course, building a product this large is complex and diverse, so not every feature can fit into this model, but it’s the general plan we’re using. So far it’s working out well, but of course the proof of a plan like this will only really come later in the product cycle.

Feature Crews

Right now, my team is working on three feature crews, and a fourth is about to spin up. I’ll start by talking a bit about each of these.

MSBuild: One of the things I love about the libraries team is the fact that we ship almost all our sources. I’m generally proud of the quality of our source, and I think it’s good discipline for us to know that everything we do will be seen by our customers. [Plus, of course, it adds value to the essay-length comments I sometimes seem to write – like the one on ATLASSUME in atldef.h J]. As a more practical matter, shipping source makes it so much easier to debug and understand our libraries. I don’t know that I could ever have learnt as much about MFC by reading docs and books as I did my first couple of years of writing MFC applications and debugging through the library sources. Our libraries build with a very complex and involved set of NMAKE-based build scripts. Use of NMAKE was very practical, since almost everyone understands it, and also was good dogfooding, since the team that owns NMAKE is also part of the VC family. You’d be amazed how complex our build is. The CRT build is especially gnarly.

For some years we’ve been watching with excitement as the MSBuild team built a new build system from the ground up. Several people who have worked for me in the past were involved in the MSBuild effort, and I think they’ve done a great job re-imagining this part of our product from scratch and producing a next generation solution to the problem. We took the decision a few months ago to migrate all our VC builds to use MSBuild, and we’ve had a feature crew working on it for a couple of months now; they’re just getting close to complete. I’m really excited to see the new build coming out. One great result of this has been a total spring-clean of our old builds. Though they are still some of the most complex builds in the division, they’re more comprehensible and better understood than they’ve been in years.

Development process: One of the things we need to do at the start of almost every product cycle is rename our library DLLs. You might wonder why we do this. It’d clearly be simpler for you if we kept our DLL names, and their binary contract, the same across multiple versions. For some parts of our libraries, it’s actually possible to imagine doing that and we seriously consider it. The CRT doesn’t change substantially every version, and because it is a pure-C API, when the CRT does change it can often be done in a compatible way. In our last version we made some non-compatible changes [for example, we widened time_t to 64 bits]. Other parts of our libraries have a greater need to change. Given the way C++ classes version, it’s not really possible to make significant changes to our STL or MFC without re-versioning the DLLs that contain those classes.

There’s also a testing problem with keeping the same DLL name. We’d have to make sure that no bug fix we made, or extension we added, was going to cause a subtle problem for existing applications. And we’d have to make sure that our new versions were tested in all the same platforms and scenarios as the old versions. This is called the platform type compatibility bar (I found a good article on platform versus library types here – the context is .NET, but the concepts are similar). We attempted to hit this compatibility bar for a couple of VC versions in the mid-nineties, with very limited success. Each new major version that shipped under the same DLL names had significant issues as we accidentally caused problems for existing users of the DLL.

Our experience has taught us that if we are making significant fixes or changes to our library components, we should re-version them. We work hard to remain source compatible, but do not need to worry about code compiled with the previous version of the product running on the current version. Our development process is just finishing the process of renaming the DLLs; we already have private copies of our newly minted, shiny msvcr90.dll and mfc90.dll to play with.

This team is also working on a fascinating internal process change that’ll significantly increase our dogfooding and reduce the complexity of our work. But I don’t have space to go into that here.

STL/CLR: One of my biggest disappointments from Visual Studio 8 is that we didn’t have the resources to complete and ship STL/CLR, our managed, verifiable implementation of the C++ Standard Template Library. Those of you on the beta for that product will have seen an early version of the technology in Beta 2. We worked with Dinkumware on this project for most of that product cycle, and they did some great work. But in the end we simply didn’t have enough people and time to keep working on it with them while finishing the other features we were building. Retrospectively, it was very ambitious of us to attempt to build this library at the same time as the C++/CLI dialect was still evolving.

We and Dinkumware started work again soon after Whidbey shipped, and now have a version that meets a lot more of our original goals. In particular, since last October we’ve done some fascinating optimization work to understand what really drives the performance of a template-based, generic-based library like this in managed code. We’re not finished yet on performance, but in informal testing we’ve seen some exciting results, including a bunch of cases where the magic of templates combined with the C++ optimizer are able to outperform the .NET Base Class Library even in verifiable code. When we envisioned C++/CLI several years ago, these are the kinds of scenarios that we dreamed of, and it’s exciting to see them coming to fruition.

We’re about to spin up a feature crew to integrate the current version of STL/CLR into Orcas. This will just be a snapshot of our current state, but it should allow us to get feedback from some of you in a future Customer Technology Preview. Lots of things will still be incomplete in that release (because we still have future milestones working with Dinkumware to complete the remaining parts of the library), but it should be enough to enable you to get a flavour of the implementation, and try it out and send us feedback. We’d love to hear your experiences.

Other Activities

Servicing: Another group that’s always running is our servicing team. Its job is to deal with incoming bugs in existing features, create QFEs and service packs, and help internal and external customers who contact us via various routes. We rotate membership of this group through our whole team, which gives everyone a chance to work on the broad spectrum of libraries technologies. I do some part-time help for this group too, and I find these issues especially fascinating – it’s always really illuminating to see how people are using our product, and learn what we can do in future versions to increase productivity and reduce pain.

We’re getting closer to a beta of our first service pack for Visual Studio 8. We managed to put lots of good fixes into this release, including many of the issues with highest vote-count on the MSDN Product Feedback Center.(which recently moved to http://connect.microsoft.com). Your feedback helped make this one of my favourite service pack experiences. And at least this one is coming out soon after the product shipped.

Planning for Vista UI: Orcas is a Vista-focussed release, and once we’ve completed the development process work described above, we can start the serious work of updating our libraries to do a better job targeting Windows Vista. The VS IDE and MFC both need to know about a raft of new controls, messages, and other Windows elements. If you look back at Windows XP, you’ll see that almost as many controls were added in that version of the operating system, and we didn’t have time to add those when Windows XP shipped (in August 2001, just before we shipped VS7). So we’ve gone back and looked at all the missing controls and UI elements back through Windows XP, so we can try to get all of these into Visual Studio Orcas. This is a big planning job that’s only partly complete, but we’re still working on this as we expect to start implementing these new controls sometime in the next 6 weeks.

Not so work related

What do I do when I’m not writing email or working? Well, this weekend I’m off to the Pacific Northwest Ballet (I’m a subscriber), and I’m going to finish building a Lego model I bought last week. My fiancée and I have to look at reception venues, and we have a couple of parties at to go to with friends. If I get time between that, I need to work on finishing organisation of the latest iteration of the Puzzle Safari event that I organise with some friends here at Microsoft. And of course, I’ll play squash both days, as I do every day. This weekend is more hectic than most, but that’s still a good sampling of what I spend my time doing.

Wrapping up

It’s been fun writing this up. Please send me feedback (martynl@microsoft.com), good or bad, so we can adjust and talk more about what you’d like to hear from VC. Also, please feel free to follow up with me if you’re interested in more in-depth information on any of the things above. I’ll use the feedback to consider what I might write to my semi-dormant personal blog, or what to ask others to write about here.

I get lots of mail from customers about various subjects. It’s very welcome, and I encourage you to mail me too. I can’t always respond promptly, but it is always read, and I’m sometimes able to help people a little bit. The features of our next product are shaped in part by the feedback we get from you through channels like this, so do make sure your voice is heard. Get in touch – keep the dialog going!

Thanks for using the product, and for your feedback,

Martyn Lovell

Development Lead

Visual C++ Libraries

http://blogs.msdn.com/martynl