The schedule for C++ and Beyond 2013 is perpetually tentative, because we reserve the right to change things at the last minute if we believe it will be for the good of the event. At the same time, we recognize that people make plans based on the schedule, so we do our best to adhere to what we announce.
You can view the current schedule here.
Here is the general structure of C&B 2013:
Monday, 9 December:
- 7:30–9:30PM: Informal welcome reception with complimentary light refreshments and soft drinks. Alcoholic beverages available for purchase. Location: Falls Terrace.
Tuesday, 10 December – Thursday, 12 December:
- 8:00–9:00AM: Communal breakfast. Location: Falls Terrace.
- 9:00AM–~12:00PM: Technical sessions. (Ending time is tentative.) Location: Salish Ballroom.
- ~12:00–~1:00PM: Communal lunch. (Starting time depends on when morning technical sessions end.) Location: Falls Terrace.
- 2:30–5:00PM: Technical sessions. Location: Salish Ballroom.
- 7:30–9:30PM: Informal discussion session. Scott, Andrei, and Herb will do their best to participate, but other commitments may interfere. Tuesday and Wednesday nights only. Location: Falls Terrace.
The longish break between the morning and afternoon technical sessions is designed to allow ample time for lunch plus some “post-lunch activity.” Possible activities include discussions with fellow C&B attendees, hiking or jogging near the lodge, catching up with email, conferencing with remote colleagues, visiting with non-C&B participants who accompanied you to Snoqualmie, cranking out code, or taking a nap.
Topics for Technical Sessions
As noted at C&B 2013’s Home Page, topics for the technical sessions are determined by Herb, Andrei, and Scott in the months and weeks prior to the event; talks typically cover new material developed expressly for C&B; and session ideas are usually posted to the C&B blog for advance feedback. Topics that have been finalized (bearing in mind that the schedule is perpetually tentative) are listed here:
- Concurrent Data Structures and Standard C++ (Scott)
- C++11 and C++14 Style (Herb)
- A Crash Course in C++14 (Scott)
- Burying
bind(Scott)
If you have a topic you’d like to see covered, don’t be shy about suggesting it, either through a blog comment or via email to the C&B Coordinator.
May 31, 2013 at 9:48 am
Here are some topics I would be interested in learning more about (in approximate order from most to least interesting):
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?
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?
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?
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?
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)?
June 3, 2013 at 3:01 pm
Hello Kyle,
This is Andrei (on behalf of the three of us). Thanks for your so eloquently stated list. Nearly every point raises an interesting thought, let me summarize
1. 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. 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, 4. These are interesting questions or even defining topics for a panel.
5. 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. That’s a great idea as well, we were actually discussing it a couple of weeks ago.
So I can’t promise anything in particular, but these are excellent suggestions that we are likely to look into.
Thanks very much!
Andrei
December 11, 2013 at 4:10 pm
Is that language that shall remain unnamed C+++? E? No idea what you are talking about. :) Who needs another language when you can have [](){}; I hope you have been in a particularly “destroy” mode.
June 8, 2013 at 7:33 am
After studying “Modern C++ Design” just after is was published and been astonished about the possibilities of the language many years ago, I would like to know if an updated version of the book is planned in regard to the C++ 11/14 capabilities?
I would like to see in a talk 1) how policy based designs could be improved with the new language features, 2) guidelines, how to structure such a design that it is still understandable by others and 3) tips and hints, what are the best ways to “debug” during compile time.
Many thank in advance!
June 9, 2013 at 7:36 am
Hi Felix —
Currently I have no plans for Modern C++1x Design, but that is definitely a good idea - some chapters would be reduced in size, which would allow for expanding in other directions.
Regarding (1) I gave a talk on that topic at a previous edition (http://cppandbeyond.com/2011/06/21/session-announcement-ten-years-of-policy-based-design-and-counting/). Definitely more would be to be said though! (2) and (3) are quite interesting. Thanks!
June 11, 2013 at 5:46 am
I really enjoyed the talk about converting blocking code to non-blocking code. I hope to be able to use std::future::then in the future.
Asynchronous is not always multithreaded. Having a reactor for IO is also asynchronous.
To my shame I do not know how to open and manipulate a file in non-blocking, cross-platform, c++ style way. And given the abundance of network file systems this is not a purely theoretical question. One can do it as a task in separate thread and yet another thread to imitate future::then. Doing it by hand every time is no fun.
I’d like to hear about current and planned standard language support for asynchronous IO, both networking IO, file IO and GUI. Maybe as a sub-topic in concurrency talk. There are many libraries doing it, each with own limitations, components written for one are not always reusable.
December 3, 2013 at 9:00 am
Michael, if you’re still wondering, one suggestion to manipulate files in a cross-plataform c++ way is boost libraries, specifically boost::filesystem if you don’t know yet, most of boost features were standardized into STL itself, so basically i believe it is very useful, well developed and reliable library.
Best regards,