Four years and still going

It has been a while since I have written here. Looking at the last time I wrote
an article of significance, I mentioned that I had insomnia. Indeed, I wrote
everything between midnight and sunrise. Fortunately for me, I haven't had
insomnia for the last year and half. This blog has suffered as a result.

why am I writing now? Well, today marks my fourth year anniversary of working at
Microsoft as a full-time employee. It is a great moment for reflection,
evaluating accomplishments, and identifying missed opportunities. No doubt, going
from knowing almost nothing about C++ three-and-a-half years ago to writing the
entire specification for all the new language features in Visual C++ 2005 is
a huge accomplishment. It is such a monumental task that I wonder if it will ever

This past week has been a time of nostalgia. Reviewing my experiences at
Microsoft as an intern and now, I am filled with hope and excitement. When I
worked as an intern in the Outlook team, it seemed as if so many great things
were about to happen in the software industry. Sure enough, great things are
happening... they're just taking an incredibly long time. After four years, I've
gained much more appreciation for the amount of effort it takes to change the
world. I expect to take all the lessons I learned over the past four years and
apply them to making an even greater difference in the next four.

Beyond the reminiscing, I regret not having said anything here for so long.
It is not because I have a shortage of things to discuss. To all those who asked me to write again (there are too many
to list here), I am making a commitment towards spending more of my
non-insomnia induced waking hours to sharing what I know. In no particular order, I am going to write about the following:

  • Design considerations for arrays
  • How to write an inline array in a ref class
  • Design considerations for overriding
  • Design considerations for for each
  • Design considerations for tracking references (and non-const binding to
  • Design considerations for strings
  • Design considerations for mixed types
  • Design considerations for class definitions
  • Comparing accessibility with visibility
  • Comparing hidebyname with hidebysig rules in C++
  • Design considerations for keywords
  • Design considerations for initonly and literal
  • Design considerations for delegates
  • Design considerations for properties and events
  • How to write a non-trivial event
  • Design considerations for conversions
  • Design considerations for safe cast and verifiability
  • Design considerations for delegating constructors
  • Design considerations for destructors and finalizers
  • Design considerations for boxing
  • Design considerations for enums
  • Design considerations for attributes
  • Design considerations for generics
  • XML documentation comments
  • Why we removed compiler switches in Visual C++ 2005
  • Thoughts about IntelliSense
  • Unicode support in the compiler
  • Compiler support for traits
  • Thoughts about reaching 100% conformance with the ISO C++ Standard
  • Discussion of some of the C++ breaking changes done for conformance
  • Design considerations for equality
  • Design considerations for Boolean conversions
  • Variadic macros
  • Managed calling conventions
  • How /clr:pure evolved
  • __declspec(process) variables in pure
  • [STAThread] and the main function
  • What is <MarshalCopy> and <MarshalDestroy>?
  • Design considerations for const and volatile in ref and value classes
  • Thoughts about Pre-JIT compilation verses JIT compilation
  • Thoughts about concurrent programming

If there are topics missing from this list or a particular topic should take
priority, please comment to let me know. To a large degree, the list above
represents subjects that I have become expert on over the last three years. With
four years past, I am looking at the challenges coming in the upcoming years.
I'm certain unexpected excitement and hard work lies ahead.

Comments (6)
  1. Mike Dimmick says:

    Presumably one of the sets of compiler switches you’re going to talk about is the /G5, /G6, /G7, /GB family?

  2. Nish says:

    Interesting list of future topics. I’ll look forward to them with pleasure 🙂

  3. Ned says:

    Brandon — really neat list! I’m curious about the STL.NET… Will it really exist? Also, I just ran into the syntax for declaring a managed C++ class static data member and it is really funky to my eyes! Is there a story behind it?

    Thanks — look forward to hearing your talks at the PDC.


  4. Ned says:

    Of course, now that I think of it, there were a few other questions I was wondering about. Is there something simple and obvious that I should do to get the same kind of functionality as boost::shared_ptr (or more specifically, boost::weak_ptr) in the managed world? The handles look like they’re similar to shared_ptr (although they don’t run d-tors immediately) but I’m feeling at a loss without boost::weak_ptr functionality. I guess my question is: should I be writing what I need or does the weak_ptr functionality already exist and I just missed the help page?

    On a more compiler-specific front, I’m curious about the lengths that the compiler will go to in expanding recursive templates before giving up and generating function calls. Last time I spoke to someone on the compiler team (~4 years ago) they said that there was an internal limit and in the view of crazy people like Andrei Alexandrescu the limit might be reviewed, but no promises… Any thoughts or breakthroughs on that front?

    Thanks again for all of your insights!


Comments are closed.

Skip to main content