Submissions for CppCon 2024
CppCon is organized by the C++ community for the community and so we invite the community to present.
CppCon 2024 will be an onsite conference at the Gaylord Rockies in Aurora, Colorado, so we are calling for submissions from presenters that can join us onsite.
Dates
Submissions open: 2 April 2024
Submission deadline: 19 May 2024
Decision notifications by: 23 June 2024
Program available online: 30 June 2024
For a chronological view of all the key conference dates, refer to the CppCon Timeline.
Who Should Submit?
You. If you have something interesting to share with the C++ community about C++ then please consider presenting. Our goal is to create the best program that we can and we feel that there must be room for both seasoned presenters and new voices.
We want to present the best C++ sessions of the year every year, so are happy to accept sessions that have been presented at other conferences. (We have enough compelling tracks that this isn’t an issue, even for attendees that attended the other conference.) Because our Main Program sessions are recorded, we generally do not accept the same session if it was presented at a previous year’s CppCon, unless that session has been significantly updated.
Topics
All submitted topics should be about making attendees better C++ programmers. Submissions such as Java for C++ Programmers are off-topic. (A submission such as What C++ Programmers Can Learn from Swift could be considered.) Submissions unrelated to C++, such as time or stress management are also off-topic. Note that submissions about software design are candidates for inclusion in our Software Design Track if they are presented by recognized C++ “experts” and focus on techniques and examples using C++.
We are open to any topic that will make attendees better C++ programmers. Below are some ideas.
- C++14/17/20/23/26
- C++ libraries and frameworks of general interest
- ISO standardization proposals
- Safety and Security in C++
- Parallelism/multi-processing
- Concepts and generic programming
- Functional programming
- High performance computing
- Software development tools, techniques, and processes for C++
- Updates on active projects (tools or libraries) that are important to C++
- Practical experiences using C++ in real-world applications
- Sessions for one of our dedicated tracks. In 2024, we plan to have the following tracks:
- Industry-specific perspectives: mobile systems, game development, high performance trading, scientific computing, robotics, cryptography, etc.
- Insights that might help software engineers from the point of view of specific roles, such as testing, IT, or documentation
Audience
CppCon attendees tend to be software engineers with many years of experience from a wide diversity of industries. Talks targeted to beginning C++ programmers are on topic, but are unlikely to be well attended. (But see our Back to Basics Track.)
Talks aimed at experienced C++ programers that are beginners in a particular area (for example, functional, game, or embedded programming, or introducing a new library or language feature), can be compelling.
Platform specific talks may be accepted, especially if they present general concepts and techniques that are not limited to one platform or tool. The number of people who could use the subject of your talk is part of our review decision. Broad appeal is better than narrow appeal, but deep appeal is our real goal. The abstract should make it clear why this is a C++ talk.
Format
Standard presentation sessions are sixty minutes long (including Q&A). We can accommodate half hour sessions and multi-session submissions. Note that multi-session submissions may be harder to accommodate. Please indicate your flexibility.
We will also have Lightning Talks, but they need not be submitted in advance of the conference. We will share more information about Lightning Talks and other opportunities for Open Content in time for you to plan your participation.
Speaker Registration
Accepted half and full session speakers will have their conference registration fee waived (one speaker per half session). If you are planning to submit a proposal, please do not register for the conference at this time. You’ll be contacted with special registration instructions later.
Financial Assistance
Further financial assistance is available to accepted speakers presenting in person. Please indicate if you require financial assistance when signing up for our Submission Page on Speaker.Fish. Details are provided on request of the Speaker Liaison.
Submission Title and Abstract
The success of your submission and even the success of CppCon as a conference depends on the quality of your title and abstract. A compelling title and abstract will result in your submission being accepted by the Program Committee, increased attendance at the conference, and increased attendance at your session.
Writing good titles and abstracts is an art, but here are some guidelines likely to make your submission more compelling.
-
- Focus on the subject and the lede–the first two sentences of your abstract.
- A reader should be able to read just the title and the first two sentences of the abstract, no more, and know “what” the topic is and “who/why” should be interested in attending the talk.
- Everything else in the abstract should (just) elaborate with details on those things, not add new main points.
- Help us highlight the broad uses of C++. We want people looking at our program to think, “Wow, C++ sure is used in a lot of different applications in a lot of different industries.” If your session is based on experience from or application in embedded, robotics, games, finance, science, etc. or a large, successful, “hot,” or otherwise well-known company then consider that as part or your title.
- If worded properly your session can be compelling to those in the same field and also to those that want to apply the lessons learned in your field to their problems.
- Examples:
Less Great: “constexpr performance tips” Much Better: “Using constexpr for performance in low-latency Google search engine code” Less Great: “Cross-platform C++ development using Visual Studio” Much Better: “Cross-platform C++ development targeting Android, iOS, Windows, Xamarin, Linux and IoT” (possibly adding “using VS”) - Consider a flavor of “How you can X by learning / embracing / using / understanding Y” rather than “Some thoughts on Y.” Emphasizing the practical value of attending your talk is what turns a website visitor into a conference/session attendee.
- Attendees come to CppCon to learn new ways to use C++ effectively. Therefore, all CppCon talks should focus on showing attendees how to use C++ well. As a litmus test, the take-away of every talk should be a list of “here’s what you can/should do in C++.”
- Example: A talk that shows a technique from another language and then focuses on how to accomplish that in C++ is fine. A talk about “<other language> for C++ programmers” that is primarily teaching about another language is not, because it doesn’t focus on using C++ effectively.
- Example: A talk that complains, even bitterly, about how hard something is in C++ (and there are hard things! and some issues may even take some time to explain) and then focuses on “here’s what you do instead” guidance is fine. A talk that is mostly a rant about how difficult something is but that has little focus on practical solutions that do work is not, because it doesn’t focus on using C++ effectively.
- Avoid jargon and insider terms.
- A single unknown acronym or term may cause attendees to think “this talk is not for me.”
- It is fine to use such terms if you define them or make their meaning clear in context. You may even have such a term in your title, as long as you explain it in your abstract. “Applications of Hobb’s Algorithm in Low-Latency Libraries” is fine as long as the abstract lets us know something about Hobb’s algorithm and why it has special value (or challenges) in low-latency applications.
- You may also refer to something in a way that makes it clear that you will explain it so attendees don’t need to worry if they aren’t already familiar with the concept: “We will also explain Lippincott functions and other techniques for exception handling.”
- Humor/cleverness is okay.
- It is certainly not required and it is better to not attempt it than to fail at it.
- People are attending because they want information, not entertainment, but no one wants to be bored. Having a title/abstract that is catchy/funny/clever is a signal that your presentation won’t be dry.
- The litmus test is that what you write should work on both levels. It should make sense even if the reader doesn’t get the joke. Otherwise it is maybe off-putting or alienating.
- A professional technical conference, like CppCon, is not the place for humor that is “adult” in nature or targets any group. Better to risk boredom than to risk offense.
- Focus on the subject and the lede–the first two sentences of your abstract.
Submission Advice
If you are a first-time submitter or just want some comments on your title and/or abstract, we invite you to send an email to our submission advice address. Please include your name in the subject line and include your session title, abstract, and any specific questions in the body. We’ve recruited a set of volunteers that will share ideas and comments on your submission before you submit it. Asking for this advice is optional, and the volunteers do not speak for the conference or the Program Committee, but may give you comments from a valuable perspective. (If you wish to use this option, do not wait. As the deadline approaches, response times on this service will lengthen.) If you’d like to volunteer to join the mailing list to share your ideas and comments, please contact the organizers to volunteer. Your own titles and abstracts will benefit from the experience.
Comments from Attendees
We’ve surveyed attendees on every presentation ever given at CppCon and the single most common issue raised is that presenters speak too fast and try to cover too much material.
Slow Down
The primary cause of the issues that attendee surveys have identified is that presenters under-estimate how long it will take to cover material. When you practice your talk in front of your cat, you’ll cover a lot of material quickly because your cat understands everything right away. Practice in front of a real audience–at work and/or your local user group. You’ll understand from the looks on their faces and the questions they ask how fast (or slow) you can go. You’ll begin to get a feel for how much material you can cover in sixty minutes.
A common mistake made by technical presenters is to give audiences insufficient time to read code-heavy slides. (This is a programming conference. There can and should be lots of code.) You understand the code very well: you wrote the slide and have practiced it many times, so you know that the important part of the code is right there, on lines six and seven. Your eyes naturally go to this part of the code and understand its meaning quickly because you already know the context. But eyes that haven’t seen this slide before need more time to absorb the code. We are programmers and we know that the devil is in the details. We want to read it all. (If it doesn’t need to be read, why is it on the slide?)
There are a few approaches you can take for code-heavy slides. One is just to pause when one comes up. The programmers in your audience won’t need to be told to start reading the code. Another approach is to talk the audience through all the code before focusing on the important part. (This might help you trim out code that doesn’t need to be on the slide.)
One handy technique is to highlight the important part of the code so it stands out and, when showing how code is being changed from slide to slide, dim or gray out the code that is unchanged from the previous slide. (This is one of several reasons why syntax coloring, while great for IDEs, is not great for slideware. Syntax coloring tends to clash with attempts to dim or highlight code.)
You’ve researched your topic and you have a lot to say, but stay focused. Your goal should be to have no more material than you can comfortably cover in one hour with questions. If you find that you are speaking quickly to accomplish this, think about where you can trim.
Resist the (admittedly very strong) urge to cover more. The difference between a session that covers less material very well and a session that hurries through material that the audience does not have time to fully appreciate, is the difference between a memorable session and a forgettable one.
Submitting
Submissions should be made on our Submission Page on Speaker.Fish. After making a submission, you’ll receive an acknowledgement from the Speaker.fish system. All submissions will go through a double-blind peer review process by the Program Committee. This means that the Program Committee does not see your name or bio when evaluating your submission, only your Title, Abstract, and Outline. To preserve anonymity, we ask you to please avoid statements in the Title, Abstract, or Outline that remove all uncertainty about who you are.
Presenters are encouraged, but not required, to submit slides and source code for distribution to attendees and to agree to have their sessions recorded. Presenters must agree to grant a non-exclusive perpetual license to publish submitted and/or recorded materials, either electronically or in print, in any media related to CppCon. Note that CppCon videos are sponsored and may be published with the sponsor’s logo.
If you have any questions about the submission process, please contact the Program Committee.