June 2013

C++ & Beyond 2013 is now fully booked, but we’ve started a waiting list for people who’d like to attend if spots open up when people who’ve registered have to cancel.   Experience tells us that this will likely happen and given that there is 5+ months before C&B begins, we expect there will be waitlist-registration opportunities.

To get on the waiting list, go to the C&B Registration Page and click on the “Add Me to the Waitlist” button beneath the Registration Information section.

To everyone who has registered, thank you, because we very much value your support.   Keep your eyes on this blog, because we’ll continue to use it to post prospective sessions topics and otherwise communicate about C&B.  If you have comments about things we could do to make C&B a success for you, please don’t be shy about posting them!

We’re down to the very last FOUR remaining spots for C++ & Beyond 2013.

So if you’ve been procrastinating about whether to attend or have been postponing the administrative paperwork needed to sign up, now would be a good time. Our venue can only hold 64 so when we sell out; we’re sold out:  the number of slots cannot and will not be increased.

Sign up on our Registration Page.

Once we sell out, I’ll set up a waiting list just in case there are cancellations. But wouldn’t you rather be on the attendee list than the waiting list? Trust me, it’s hard to firm up plans when you are on a waiting list…

The C&B Registration page shows the number of remaining tickets, so if you want to see how many spots remain as we count down to a sold-out event, you can find out there.


We generally ask our visitors for topic suggestions, and recently we received a comment from Kyle Kloepper with some really good ones! Here are Kyle’s topic suggestions with Andrei Alexandrescu’s responses:

1. Error handling in C++ – What are the various ways to handle unexpected conditions in a C++ program? Are there superior error handling paradigms in other languages which should be modeled? What needs to be taken into account to choose between exceptions, error codes, bool try_xxx() with output arguments, noexcept, assert, program by contract, or something else? How can an error handling design be evaluated? How can that design be made robust to changes by future, and perhaps non-expert, developers?

Andrei’s response:
There’s new work on transactional error handling (borrowing from a language that shall remain unnamed) that I think is very worth sharing. That work is as of now platform-dependent, but there’s effort on standardizing it.

2. Unit testing and defect prevention – What are the current best practices in C++ unit testing? How do C++ features support unit testing? What is a unit test, and more importantly, what is not a unit test? What is the purpose of unit testing (e.g. speed development, provide a more robust code base, reduce maintenance costs)? How many unit tests should a module have? What is the proper interaction between unit testing, asserts, and runtime checking? How can C++ language features be used to prevent the introduction of defects so that unit tests need not be written?

Andrei’s response:
We at Facebook use Google’s unit testing mini-framework with great results, and I’m unclear how many actually do know about such.

3. When not to use C++ – What problems are best solved by a language (or tool) other than C++? What languages are those and why are they better than C++ for the specific problem? How should designs in those languages inform how C++ programs are written? How can C++ integrate with those other languages to put together a more complete system?

4. Robust systems – How can modules be designed and built to isolate failures and continue operation in the face of invalid input, hardware errors, logic errors, and upgrade regressions? Does this need to be designed in at the class level or at the application scale? How is robustness measured? What are examples of high availability C++ applications and projects and how was that achieved? How correct does code need to be and still be robust?

Andrei’s response:
3 & 4: These are interesting questions or even defining topics for a panel.

5. How to teach C++ – What are successful ways that a C code base and C developers can adapt to using C++? Is that conversion worth the cost? What are the most useful C++ features (i.e. which features should be promoted first)? How can an individual developer impact an organization in a significant way? What are the liabilities of C++ over against C and how can they be minimized? What are examples of large projects and companies who have made the switch? How can the tendency to write C code in a C++ code base be prevented?

Andrei’s response:
I’ll defer that to Herb, who could teach C++ to a Stegosaurus (as I’m sure you know, Stegosauri have a learning disability even by dinosaur standard).

6. C++ tools – What programs, applications, and libraries should be used to get the most out of C++ (e.g. editors, source control, code generators, debuggers, static analyzers, runtime instrumentation, compilers, libraries)? Specifically what about those tools enables more productive, higher quality, or easier to understand code (in the case that a specific tool cannot be used in some other development environment)?

Andrei’s response:
That’s a great idea as well, we were actually discussing it a couple of weeks ago.

You can view the entire blog post and comment exchange here: http://cppandbeyond.com/cb2013-schedule/

Do you have any topic suggestions, comments, or opinions? Please be sure to comment below, we’d love to hear them.

The Early Bird registration discount expires in just one week (June 9).  Don’t miss out on an opportunity to save $300 off registration.

Also, we have begun posting some topics for the technical sessions, so be sure to check them out at http://cppandbeyond.com/cb2013-schedule/.

Do you have a topic you’d like to see covered? Don’t be a Bashful Boris! You can suggest a topic either through a blog comment or via email to me (C&B Coordinator).

Lisa Wells