By Blog Staff | Jan 24, 2014 06:29 PM | Tags: None
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: N3883
Date: 2014-01-17
Code checkers & generators
by Németh Péter
Excerpt:
Native Json & HTML, built-in tutorial, easy meta programming, reflection proposal to C++.
By Blog Staff | Jan 24, 2014 01:01 PM | Tags: None
From new C++ user groups springing up across Europe and upcoming conferences, to the Boost refactoring and (of course) C++14, Jens Weller has a nice piece previewing some of the things to look forward to for C++ in 2014.
C++ in 2014
by Jens Weller
Note that Jens' list is not complete, but it gives a pretty good overview of what's coming up in the near term with a few more things to be added later.
A small teaser from the article:
I already know that there are new C++ User Groups in Aachen, Dortmund, Heidelberg and Munich in Germany, also a Russian C++ User Group is now meeting in St. Petersburg and Moscow. I think a few others will follow...
By Blog Staff | Jan 24, 2014 09:32 AM | Tags: intermediate
Quick A: Maybe, but it generally commits you to exposing the internal type (can't change representation).
Recently on SO:
Should I use noexcept for getters always?
Should I use
noexceptmethod modifier for getters always in C++11?I mean simple getters here that just return members. At least in all my getters I have here an exception can't possibly be thrown. One downside is that a getter gets too verbose:
const std::string& getName() const noexcept{ return name; }The good side as pointed out in Stroustrup's book is that the compiler might do some optimizations here and there.
By Blog Staff | Jan 24, 2014 09:09 AM | Tags: intermediate
Michael Caisse and Jon Kalb will be conducting a two-day training class on C++11 in San Francisco in March as part of the Code Stars Summit event.
Two Full Days of C++11 for C++ Programmers
Instructors: Michael Caisse and Jon Kalb
March 25-26
San Francisco, CA, USA
From the announcement:
C++11 introduces a lot of new tools for writing code that is expressive, but continues the C++ tradition of uncompromised performance. If you are comfortable with C++, but need to get up to speed with the language and library extensions offered by C++11 this is your opportunity to learn the latest in C++ from some of the best instructors available.
Topics covered include:
- Move semantics, rvalues, and perfect forwarding
- Lambda expessions
- New smart pointers
- Tuples
- Range-based
forloops- Variadic templates
- Standard
functionandbindautoanddecltype- Initializer lists
- Uniform initialiation
constexpr- Delegating constructors
- Defaulted and deleted member functions
explicitandfinalnullptrPrerequisites:
No knowledge of C++11 is assumed, but basic familiarity with C++ is assumed. It isn’t necessary that students be able to write templates or operator overloads unassisted, but they need to be able to follow examples of such code, or they are likely to fall behind.
By Blog Staff | Jan 23, 2014 01:08 PM | Tags: None
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: N3882
Date: 2014-01-17
An update to the preprocessor specification
by David Krauss
Excerpt:
The C preprocessor specification inherited by C++ uses undefined behavior to specify latitude for implementation differences. This technically allows one compiler to produce a defective executable from a particular program, while another fills the void with useful features. In theory this makes porting programs dangerous, but in practice consensus has been reached regarding the meaning of most programs invoking undefined behavior, and programmers have little reason to worry. By capturing the status quo in the standard, safety can be properly guaranteed, and the preprocessor may be more completely understood without referring to platform documentation.
Additionally, the preprocessor has not kept pace with C++11 lexical extensions (raw strings, user-defined literals, and new encoding prefixes), resulting in unspecified corner cases.
This proposal updates the preprocessor specification to remove undefined behavior, missing specifications, and possible contradictions, and to better document implementation differences.
Issues related to universal-character-names are not addressed here, but in N3881.
By Blog Staff | Jan 23, 2014 12:57 PM | Tags: None
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: N3881
Date: 2014-01-03
Fixing the specification of universal-character-names
by David Krauss
Excerpt:
There are two main problems with the current specification of UCNs, which remains essentially the same as initially standardized.
- Undefined behavior is an undesirable kind of specification, because it technically allows the implementation to quietly produce a defective executable file. There is consensus that errors in preprocessor usage should not have runtime consequences. There is even a CERT security advisory about UCNs causing undefined behavior. N3801 "Removing Undefined Behavior from the Preprocessor" directly addresses this by recommending to convert undefined behavior specifications to ill-formedness.
- There are corner cases which are not specified as undefined behavior. These may be welldefined and misinterpreted, or ill-formed yet undiagnosed, by popular implementations, or simply excessively restrictive. Underspecified cases undermine the effect of N3801 by remaining wrongly defined.
The present paper will review several corner cases, considering the natural response of models A,
B, and C, and the actual behavior of GCC and Clang. This leads to a specification permitting
implementation flexibility without ambiguity, and bringing existing compilers into conformance.
By Blog Staff | Jan 23, 2014 12:53 PM | Tags: None
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: N3879
Date: 2014-01-17
Explicit Flow Control: break label, goto case and explicit switch
by Andrew Tomazos
Excerpt:
We propose adding to C++ some new jump statements and making available an explicit-specifier for
switch statements.The new jump statements are
breaklabel,continuelabel (same as Java),goto caseconstant-expression
andgoto default(same as C#).An
explicit switchstatement (same as C#) causes each case block to have its own block scope, and to never flow off the end. That is, each case block must be explicitly exited. (The implicit fallthrough semantic between two consecutive case blocks can be expressed in anexplicit switchusing agoto casestatement instead.)
By Blog Staff | Jan 23, 2014 12:38 PM | Tags: None
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: N3878
Date: 2014-01-13
Extensions to the Concept Introduction Syntax in Concepts Lite
by Botond Ballo and Andrew Sutton
Excerpt:
In this paper, we propose a few small extensions to concept introductions. We believe these extensions will make the language more expressive and fill some holes in the Concept Lite proposal.
By Blog Staff | Jan 23, 2014 12:28 PM | Tags: None
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: N3877
Date: 2014-01-17
Centralized Defensive-Programming Support for Narrow Contracts (Revision 3)
by John Lakos and Alexei Zakharov
Excerpt:
In this proposal, we describe a centralized facility for supporting defensive runtime validation of function preconditions. What makes this overall approach ideally (and uniquely) suited for standardization is that it allows the application to (1) indicate coarsely (at compile time) the extent to which precondition checking should be enabled based on how much defensive overhead the application (as a whole) can afford, and (2) specify exactly (at runtime) what action is to be taken should a precondition violation be detected. Moreover, the flexibility of this supremely general solution to precondition validation lends itself to a thorough, yet surprisingly easy-to-use testing strategy, often called negative testing, for which a supportive framework is also provided. Finally, this general approach to implementing and validating defensive checks is not just a good idea: It has been successfully used in production software at Bloomberg for over a decade, was presented at the ACCU conference in 2011, and is currently available along with copious usage examples embedded in running library code as part of Bloomberg’s open-source distribution of the BSL library at https://github.com/bloomberg/bsl.
By Blog Staff | Jan 23, 2014 12:24 PM | Tags: None
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: N3876
Date: 2014-01-19
Convenience Functions to Combine Hash Values
by Nicolai Josuttis
Excerpt:
Currently, there is not support in C++ to define hash functions for user-defined keys. Instead, the user has to implement an appropriate function. Implementing a hash function is not trivial. This proposal has the goal to make the definition of hash functions for user-defined types easier by providing a convenience function to combine multiple hash values.
The goal is not to provide a perfect hash function here, but to provide an easy-to-use interface to help application programmers to provide an pretty useful hash function so that they can use hash containers with their types. Note that this does not disable the ability to still provide better user-defined hash tables. It just helps to avoid that a user-defined hash function is better than a naive approach.
Note also that this paper doesn’t provide an easier approach to define new hash functions (as discussed in N333).