N3893-95: C++ Standard Library Issues List (Revision R86) -- Alisdair Meredith

By Blog Staff | Jan 24, 2014 06:48 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: N3893-95

Date: 2014-01-20

C++ Standard Library Active Issues List (Revision R86)

C++ Standard Library Defect Report List (Revision R86)

C++ Standard Library Closed Issues List (Revision R86)

by Alisdair Meredith

Excerpt:

The purpose of this document is to record the status of issues which have come before the Library Working Group (LWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee.

N3892: C++ Ostream Buffers -- Lawrence Crowl

By Blog Staff | Jan 24, 2014 06:47 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: N3892

Date: 2014-01-20

C++ Ostream Buffers

by Lawrence Crowl

Excerpt:

At present, stream output operations guarantee that they will not produce race conditions, but do not guarantee that the effect will be sensible. Some form of external synchronization is required. Unfortunately, without a standard mechanism for synchronizing, independently developed software will be unable to synchronize.

... The general consensus in the July 2013 meeting of the Concurrency Study Group was that buffering should be explicit. This paper proposes such an explicit buffering.

N3890: Container<Incomplete Type> -- Zhihao Yuan

By Blog Staff | Jan 24, 2014 06:44 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: N3890

Date: 2014-01-19

Container<Incomplete Type>

by Zhihao Yuan

Excerpt:

The goal of this paper is to allow recursive data structure definitions with STL containers, while to make the STL container instantiations well-formed even when some of the template arguments are incomplete types (in contrast to 17.6.4.8/2) is an approach to achieve the goal without breaking any language restrictions or existing practices.

N3889: Concepts Lite Specification -- Andrew Sutton

By Blog Staff | Jan 24, 2014 06:42 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: N3889

Date: 2014-01-20

Concepts Lite Specification

by Andrew Sutton

Excerpt:

C++ has long provided language support for generic programming in the form of templates. However, these templates are unconstrained, allowing any type or value to be substituted for a template argument, often resulting in compiler errors. What is lacking is a specification of an interface for a template, separate from its implementation, so that a use of a template can be selected among alternative templates and checked in isolation.

N3887: Consistent Metafunction Aliases -- Michael Park

By Blog Staff | Jan 24, 2014 06: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: N3887

Date: 2013-12-26

Consistent Metafunction Aliases

by Michael Park

Excerpt:

This paper recommends a systematic guideline to steer future WG21 decisions in deciding when a metafunction-name_t template alias should accompany a standard library metafunction. After applying this recommended guideline to the entire C++14 standard library, we conclude that tuple_element_t is the only missing alias. We then propose wording (a) to remedy this lack and (b) to take advantage of the proposed remedy. Finally, we also present an alternative guideline and its implications, and provide justications for favoring the recommended guideline.

N3886: A Proposal to add a Database  Access Layer to the Standard Library -- Johann Anhofe

By Blog Staff | Jan 24, 2014 06:35 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: N3886

Date: 2014-01-18

A Proposal to add a Database  Access Layer to the Standard Library

by Johann Anhofe

Excerpt:

This document describes an easy to use database abstraction layer for C++. It describes a set of classes which can be used to access an arbitrary SQL based relational database system."

There exist a lot of different database systems in the world, with a lot of different API’s for accessing data within a C++ program. The most API’s are in plain old C, which make the usage even harder for novice programmers. So we need a simple harmonized layer which can be easily extended for new database systems and also easily used by programmers.

N3884: Contiguous Iterators: A Refinement of Random Access Iterator -- Nevin Liber

By Blog Staff | Jan 24, 2014 06:33 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: N3884

Date: 2014-01-20

Contiguous Iterators: A Refinement of Random Access Iterator

by Nevin Liber

Excerpt:

This is a proposal to add contiguous iterators to the standard, which is a refinement of random access
iterators.

A contiguous iterator is a random access iterator that also meets the following requirements:

std::pointer_from(i) == std::addressof(*i) (when i is dereferenceable)

std::pointer_from(i + n) == std::pointer_from(i) + n (when i + n is a valid iterator)

N3883: Code checkers & generators -- Németh Péter

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++.

C++ in 2014 -- Jens Weller

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...

Quick Q: Should "property get" functions be noexcept? -- StackOverflow

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 noexcept method 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.