ROUGH DRAFT

Please beware that every page on attributes, i.e., every page deeper than this index page, is not only a very rough draft but does not yet have its final position settled. URLs are likely to change without notice or explanation.

C++ Attributes

Microsoft Visual C++ extends the C++ language to recognise blocks of text between square brackets. The enclosed text specifies attributes for whatever programming element follows the block.

The intention seems to be that the attributes configure an automated generation of possibly large amounts of boilerplate that the programmer might otherwise have to write (or, more likely, cut and paste) into the source code, typically with small adaptations. Even with the assistance of macros and libraries, the writing of such boilerplate is both tedious and prone to silly errors. Its reading is not trivial, either: nobody ought ever have to wade through lines of boilerplate just to check that it truly is just (the expected) boilerplate. Far better to have such code generated mechanically by a program rather than by a programmer. Then, no programmer or reviewer need ever grapple with more than a concise statement of how the boilerplate is configured. Attributes seem intended to act as that statement.

Indeed, the boilerplate needn’t ever be seen by the programmer. The compiler comes across an attribute, possibly with arguments, and passes it to a corresponding attribute provider, which may be internal to the compiler or be supplied externally as a DLL. The provider generates whatever code is indicated by the attribute and arguments, and passes it to the compiler as if it were extra text to be injected at some specified position in the text that the compiler has already loaded from the source file. The source file itself is unaltered but it is compiled as if it had contained the injected code.

The programmer who wants to see the injected code may compile with the /Fx option. For each source file that caused any injection of text, the compiler then generates a new file containing both the given contents and the injected text, intended as a more or less faithful representation of what the compiler actually did end up compiling.

Needless to say, the recognition of an attribute and the injection of code in response to an attribute depend on a substantial interface between the compiler and the attribute providers. Nothing of this interface seems to be documented.

Of the built-in attributes and the attributes that are supported through ATLPROV, almost all are documented. That said, for a “technology” that Microsoft promotes as new and useful, rather much is left undocumented. Moreover, in what is documented, errors of fact are numerous.