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.