I thought I should finally get around to writing a design rationale for
C++/CLI, to pull together in one place some accurate information about the
whats, whys, and hows of these extensions. You can find it at:
A Design Rationale for C++/CLI
http://www.gotw.ca/publications/C++CLIRationale.pdf
I've pasted the Preface below. The paper also includes a FAQ covering some
common points of interest about C++/CLI. I expect it to be a living
do***ent; this is version 1.0.
Enjoy,
Herb
Preface
A multiplicity of libraries, run-time environments, and
development environments are essential to sup****t the range
of C++ applications. This view guided the design of C++ as
early as 1987; in fact, it is older yet. Its roots are in
the view of C++ as a general-purpose language
- B. Stroustrup (D&E, p. 168)
C++/CLI was created to promote C++ use on a major platform, ISO CLI
(the standardized subset of .NET). This paper attempts to capture a
small but representative sample of the experience gained by a suc-
cession of C++ experts who have tried to define a binding between
C++ and CLI. A central goal is to explain why pure library exten-
sions are technically insufficient in the cases where they were not
used, by considering design alternatives for representative
examples that cover most CLI feature areas:
- CLI types (e.g., ref class, value class): Why new type
categories are needed, and considerations for choosing the
right defaults for CLI types.
- CLI type features (e.g., property): Why new abstractions
are needed for some CLI features.
- CLI heap (e.g., ^, gcnew): Why not to reuse the existing *
pointer declarator and new.
- CLI generics (generic): Why the new genericity feature is
distinct from templates, but compatible and highly
integrated with templates.
- CLI non-features (e.g., template, const): Why and how these
are made to work on CLI types.
For each case, the paper describes:
- The CLI feature and basic requirements, including representative
metadata that must be generated.
- The lower-impact Managed Extensions design, and where it was
insufficient.
- The C++/CLI design and rationale.
- Other major design choices that were considered, both in earlier
iterations of C++/CLI and in other separate design efforts that
didn't work out and were never publicly available.
Finally, note that most of the C++/CLI extensions are needed only when
using C++/CLI to author new CLI types and libraries. In practice, many
programmers using a C++/CLI-enabled compiler (currently Visual C++
2005) are simply taking advantage of the ability to seamlessly use
existing CLI types with their C++ code, which typically requires no
extended syntax at all beyond a sprinkling of gcnew and ^.
---
Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)
Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
