CppCon 2014 Registration Open: September 7-12, Bellevue, WA, USA

cppcon-173.PNGThe Standard C++ Foundation is very pleased to announce the first annual CppCon.

cppcon-logo.PNG

Registration is now open for CppCon 2014 to be held September 7–12, 2014 at the Meydenbauer Center in Bellevue, Washington, USA. The conference will start with the keynote by Bjarne Stroustrup titled "Make Simple Tasks Simple!"

CppCon is the annual, week-long face-to-face gathering for all C++ users. The conference is organized by the C++ community for the community. You will enjoy inspirational talks and a friendly atmosphere designed to help attendees learn from each other, meet interesting people, and generally have a stimulating experience. Taking place this year in the beautiful Seattle neighborhood and including multiple diverse tracks, the conference will appeal to anyone from C++ novices to experts.

What you can expect at CppCon:

  • Invited talks and panels: The CppCon keynote by Bjarne Stroustrup will start off a week full of insight from some of the world’s leading experts in C++. Still have questions? Ask them at one of CppCon’s panels featuring those at the cutting edge of the language.
  • Presentations by the C++ community: What do embedded systems, game development, high frequency trading, and particle accelerators have in common? C++, of course! Expect talks from a broad range of domains focused on practical C++ techniques, libraries, and tools.
  • Lightning talks: Get informed at a fast pace during special sessions of short, less formal talks. Never presented at a conference before? This is your chance to share your thoughts on a C++-related topic in an informal setting.
  • Evening events and “unconference” time: Relax, socialize, or start an impromptu coding session.

CppCon’s goal is to encourage the best use of C++. The conference is a project of the Standard C++ Foundation, a not-for-profit organization whose purpose is to support the C++ software developer community and promote the understanding and use of modern, standard C++ on all compilers and platforms.

Looking at C++14

A few weeks ago the C++ committee did meet in Issaquah, its most important result: the final draft for C++14. See Herb Sutters trip report for details, I have written an overview based on his trip report, clangs C++14 status page and of course the papers it self.

Looking at C++14

by Jens Weller

From the Article:

As I have read through most papers of last and this year, a short overview which papers now have made it into the standard. So, what are the new features of C++14? Already before the last meeting, clang had implemented all known C++14 features of the draft published after the Chicago meeting.

Quick Q: When should you prefer std::function vs. a virtual function to implement a callback? -- SO

Quick A: Using a named abstract base class makes code more tightly coupled to that specific name. Where possible, prefer using std::function which is more general and flexible.

Recently on SO:

Pros & cons of a callback (std::function/std::bind) vs an interface (abstract class)

I'm creating a server application in C++11 using Boost.Asio. I've created a class, Server, which takes care of accepting new connections. It's basically just:

void Server::Accept() {
  socket_.reset(new boost::asio::ip::tcp::socket(*io_service_));
  acceptor_.async_accept(*socket_,
                         boost::bind(&Server::HandleAccept, this, boost::asio::placeholders::error));
}
void Server::HandleAccept(const boost::system::error_code& error) {
  if (!error) {
    // TODO
  } else {
    TRACE_ERROR("Server::HandleAccept: Error!");
  }
  Accept();
}

I've found two ways (I'm sure there are more) to "fix" the TODO comment, i.e. to move the socket to wherever it should go. In my case I just want it back to the class instance that owns the Server instance (which then wraps it in a Connection class and inserts it to a list).

  1. Server has a parameter in its constructor: std::function<void(socket)> OnAccept which is called in HandleAccept.
  2. I create an abstract class, IServerHandler or whatever, which has one virtual method OnAccept. Server takes IServerHandler as parameter in its constructor and the class instance owning the server instance extends IServerHandler and constructs Server with *this as parameter.

What are the pros and cons of option 1 vs option 2? Are there any better options? I'm having the same problem in my Connection class (OnConnectionClosed). Also, depending on how I decide to design the system, it might need a OnPacketReceived and OnPacketSent callback.

Stroustrup & Sutter on C++ Update

eelive.PNGUpdate: The EE Live! organizers have announced that they are able to expand the room for Stroustrup & Sutter on C++, and so seats are still available for Bjarne Stroustrup's and Herb Sutter's two-day seminar:

Super C++ Tutorial: Stroustrup & Sutter on C++

EE Live!
March 31 - April 1, 2014
McEnery Convention Center
San Jose, CA, USA

We invite you to spend two insightful and informative days with C++ luminaries Bjarne Stroustrup, the creator of C++, and Herb Sutter, the chair of the ISO C++ committee, as they address the most important issues for C++ developers in 2014.

If you are interested in attending and have not registered yet, seats are still available -- register today.

See also the session details announcement for more information about topics and content. This event is especially well timed with the technical completion of C++14 just one month ago, and will include solid and practical coverage from two of the key people who shape the C++ standard about how to effectively apply many C++14 features that are already available in your current compilers.

Fun with Lambdas: C++14 Style (Part 1) -- Sumant Tambe

sumant-tambe.PNGA rapid-fire "now write this using lambdas" problem-solution drill with Sumant Tambe:

Fun with Lambdas: C++14 Style (Part 1)

by Sumant Tambe

From the article:

It's common knowledge that Functional Programming is spreading like a wildfire in mainstream languages. Latest promoted languages: Java 8 and C++, both of which now support lambdas. So, let the lambdas begin! and may the fun be ever on your side. The same text is available in slides form on Slideshare. This blog post and the talk/slides are inspired by JSON inventor Douglas Crockford.

C++: The Good Parts -- Jordan DeLong

delong.PNGA fun(ctional) talk from QCon:

C++: The Good Parts (slides)

by Jordan DeLong

The talk abstract:

Although C++ originated with the primary aim of adding Object Oriented features to C, it has evolved from the OO paradigm into a multi-paradigm language with strong support for various functional programming idioms.   C++11 adds several language features, most notably lambda expressions, that are overtly functional. But even prior to C++11, key parts of the standard library sported a design that has fundamentally more in common with functional programming than with OO.   This talk gives an overview of the past, current and near future "good parts" of C++'s functional side, through the colored lens of the speaker's biases.

 

Classic C++ Files: Sixteen Ways to Stack a Cat -- Bjarne Stroustrup

For your Friday reading pleasure, here's a classic paper showing off C++'s flexibility with a wink and a smile.

Although it doesn't exercise the new features of modern C++, we believe all of the code still works. How's that for backward compatibility...

Sixteen Ways to Stack a Cat

by Bjarne Stroustrup

From the article:

This paper presents a series of examples of how to represent stacks in a program. In doing so it demonstrates some of the fundamental techniques and tradeoffs of data hiding as seen in languages such as C, Modula2, and Ada. Since all the examples are written in C++ it also demonstrates the flexibility of C++’s mechanisms for expressing data hiding and access.

... The nine-plus cat lives in this paper are dedicated to Dave McQueen who once in desperation proposed the death penalty for presenting "yet another stack example." Also thanks to Andy for giving me a practical demonstration of the difficulty of stacking cats.

Compiler support for C++11 and C++14

C++11 support is still an interesting topic, even that GCC and Clang now fully support it. Also the upcoming C++14 standard is already getting implemented by a lot of compilers. There are two very interesting publications about this topic in recent weeks, first, on italiancpp.org there is a PDF on C++11 and C++14 feature support for Visual C++, Intel, Clang and GCC. Also Just a few days ago, a interesting blogpost about this topic was published on C++Rocks, focussing on compiler and library support:

C++11/14 compiler and library shootout

by C++ Rocks

From the Article:

It’s been almost a year since my last comparison of C++11 support across different compilers, so I decided to take a break from working on my book about C++11/14 features in VS2013, and see how things have changed.

N3966: Fixes for optional objects -- Fernando Cacciola, Andrzej KrzemieĊ„ski

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3966

Date: 2014-03-01

Fixes for optional objects

by Fernando Cacciola, Andrzej Krzemieński

Excerpt:

This document proposes a number of wording fixes, as suggested in Issaquah meeting, to optional objects proposed in N3793. We do not propose any changes in the functionality. We only reworded the standardese, and applied bug fixes: ...

N3965: Proposal for Unbounded-Precision Integer Types -- Pete Becker

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3965

Date: 2014-02-28

Proposal for Unbounded-Precision Integer Types

by Pete Becker

Excerpt:

Programmers sometimes need to manipulate integer values that are too large to repesent with C++’s standard integer types. Doing a Google search for terms that describe large integers produces many hits for libraries that handle large integers. These libraries vary in quality, from hacks by beginners to sophisticated, professional implementations. Also, Java has unbounded precision integers as part of its standard class library.

One important use for unbounded-precision integers is cryptography. Cryptographic applications typically manipulate integer values of several hundred digits. If the C++ standard library provides facilities for such values it will make cryptographic applications easier to write and to port.

There have been two Committee papers proposing unbounded-precision integer libraries for C++: N1718 (2004) and N2143 (2007), both by M.J. Kronenburg. Nothing was done with these papers, in part because there was too much else going on in the Library Working Group at the time. Now that the Committee is looking to greatly expand the scope of the standard library, it’s time to reconsider unbounded-precision integers.