Udostępnij za pośrednictwem

Design guidelines for C++

  • Artykuł

I'm here at PDC, and it hass been great to meet so many C++
developers. Of course, the best part of this week is that Visual C++ has finally
announced the new language design for C++. As I mentioned last time, I will
spend a while covering rationale and design behind this language design. Before
going through the design process and some of the history in the language, I'll
cover highlights of what we learned from managed extensions.

  1. Keeping compatibility with existing C++ was really
    great. This is what we have colloquially called "It Just Works" or IJW.
    Giving C++ developers seamless interop between unmanaged and managed code
    was the killer feature. We needed to preserve this advantage and look at
    making it even better.
  2. People hate underscore-underscore keywords. Even
    though this was done to work well with the C++ Standard (and developers
    understood that), no one really liked it. Going forward we needed to look at
    different ways to have first-class keywords but maintain compatibility with
    existing C++ code.
  3. Overloading the meaning of the same syntax makes the
    language hard to use. Nowhere is this more obvious than with pointers. An
    asterisk in the managed extensions syntax meant one of several things: (1) a
    native pointer in which memory did not move, (2) an interior pointer in
    which memory could move and it often pointed inside an object, or (3) a
    whole object pointer in which memory could move. Looking at single line of
    code and determining which kind of pointer was in use was sometimes
    impossible. We learned that different concepts need to be expressed with
    different syntax.

I could go on forever on lessons learned. A frequent
message that we heard was developers like C++ and wanted to use it, but managed
extensions were just too hard to use. More concerning is that some of the design
decisions in managed extensions actually prevented us from innovating in the
language. For example, the usage of pointers made it impossible to make use of
operator overloading CLR types, as user defined operators do not apply to
pointers. Based on significant feedback, we decided to redesign the CLR features
in C++.

Several things have greatly benefited the new language
design. First, we actively sought feedback from C++ community leaders. Compiler
vendors, library developers, and others were involved very early on. They were
given the opportunity to provide feedback, and we listened and acted. Second, we
started by setting goals for the language design. As more people were involved,
it was easier to get randomized with different approaches to solving problems.
By having a list of goals available, we were able to measure each of these
solutions.

Many people from Microsoft were involved in creating a
solid language design. From the compiler side, Mark Hall and Jonathan Caves have
brought significant experience in writing the Visual C++ compiler and doing much
of the work that made the Managed Extensions language possible. Jeff Peil
brought a wealth of knowledge about the C++ standard, the internal working of
the CLR, and a keen understanding of how C++ is used in production. Chris Lucas
led the language design team for a while to set the goals and direction for the
language design. Herb Sutter facilitated the community involvement and
standardization process, and recently started leading the design team to guide
it through some difficult decisions. Anson Tsao and Martyn Lovell have been
involved from the libraries aspect – both building libraries with the new
language and ensuring common C++ practices were enabled by the language design.
Finally, I have been involved working on the language semantics, implementation
schedule, and language specification document. Of course there a dozens more
people who are implementing this language and actively involved in the design.
As I cover more specific areas, I will mention who was involved.

Knowing that, Chris Lucas is the one to thank for setting
the language design team in the right direction. Extending a language is much
more difficult than creating a new language from scratch. He started by reading
Bjarne Stroustrup's book, "The Design and Evolution of C++." Many of the design
goals of C++ still resonated today, and they were adapted to the goals we
finalized upon. Here is a summary of those goals:

General Rule

  • Using CLR features is an option, not a requirement for
    C++ development.

Design Rules

  • Solve problems developers have today.
  • The CLR features are a first class part of the
    language, we need to make the experience seamless.
  • Enable good designs to be written. Even though C++ has
    significant flexibility, we need to enable good developers to write robust,
    correct, and maintainable code.
  • C++ is, and should always be, a multi-paradigm
    language. We need to support existing paradigms (object oriented,
    procedural, and generic) in everything we do. We should also make sure new
    features are orthogonal so that the combination of features yields an even
    more powerful language.
  • Consider the interaction with other .NET languages.
    These aren't always just paradigm issues. We need to make sure that
    frameworks programming is easy with C++.
  • We should have aspirations for standardization and
    growth in the CLR support, but prioritize making C++ useful and productive
    today.

Technical Rules

  • Care needs to be taken to preserve C++ semantics versus exposing
    CLR semantics. Using both semantics at the same time is ideal.
  • Syntax should have a distinct and consistent meaning.
  • It's more important to enable C++ and CLR features, than it is to
    disable them for CLS compliance. It should be obvious when a developer is
    writing CLS compliant interfaces, and tools should assist the developer. If a
    feature could be CLS compliant, make it CLS compliant.
  • We should not avoid a feature due to verifiability, but we should
    ensure that it is possible to write productive, useful verifiable code in C++.
    It should be easy for a developer to recognize when code is verifiable or not.
    If a feature could be verifiable, make it verifiable.

Support Rules

  • Leave no room for a lower level language on the CLR
    than C++.
  • Don't sacrifice the scalability of the C++ build
    process.
  • Support the creation of CLS compliant interfaces and
    verifiable components.
  • Support assembly, module, and compiland organization
    of code.
  • The language enables the library which enables the
    application.

There is a lot behind each of these rules. I'll spare
everyone from an in depth discussion of each one (someday it will probably end
up in a book). In the end, we had a very simple mantra that the language design
team lived by: Bring C++ to .NET. Bring .NET to C++. In that short phrase
lies a lot of power. C++ has so much to offer, as does .NET. It was our goal to
bring the best of both worlds together. In many ways, we believe we've succeeded
at tackling this challenge. As we continue to gain experience and feedback, we
are confident that C++ will continue to provide the power and flexibility that
make C++ developers the best in the world.

Next time, I'll share some
of the things I've heard at PDC as well as provide some background on the type
of developer the Visual C++ group is building a product for.

Comments