The Future of Attributed ATL

When ATL 7 was released, Attributed ATL was a big new feature. All the wizards defaulted to generating attributed code, all the new help was about attributes, and everyone swore that this was the wave of the future. There was even talk of someday opening up the compiler so that people could create their own attribute providers.

Things didn't work out that way. Attributed code suffers from several problems:

• Difficulty debugging. If there's a problem in the code generated by the attribute or its interaction with your code, it's very difficult to debug.

• Lack of control. Attributes do a lot of work for you behind the scenes, but if you don't like the code the attribute is generating, you're out of luck. Because C++ is all about powerful tools that give you fine control over your code, this doesn't work so well for most C++ developers.

• Bugs. Some areas in attributed code (particularly around connection points) are just plain buggy.

It's very telling that in Visual Studio 2005, the ATL wizards now default to nonattributed code. The only part of ATL that requires attributed code is the Web Services portions of ATL Server (see Chapter 13, "Hello, ATL Server," for a discussion). Microsoft seems to be moving away from the attributed ATL experiment. It looks like the ATL community is stuck with templates, macros, IDL files, and RGS scripts.