C++11 - the new ISO C++ standard and GCC

其他 2018-05-30 15:27:37 阅读次数: 0


http://www.stroustrup.com/C++11FAQ.html, https://gcc.gnu.org/projects/cxx-status.html#cxx11 GCC 版本与 C++特性

Morgan Stanley | Columbia University | Texas A&M University | Churchill College, Cambridge

home | C++ | FAQ | technical FAQ | C++11 FAQ | publications | WG21 papers | TC++PL | Tour++ | Programming | D&E | bio | interviews | videos | applications | glossary | compilers

C++11 - the new ISO C++ standard

Modified August 19, 2016

This document is written by and maintained by Bjarne Stroustrup. Constructive comments, corrections, references, and suggestions are of course most welcome. Currently, I'm working to improve completeness and clean up the references.

Translations:

I have contributed to the new, unified, isocpp.org C++ FAQ maintained by The C++ Foundation of which I am a director. The maintenance of this FAQ is likely to become increasingly sporatic.

C++11 is the ISO C++ standard ratified in 2011. The previous standard is often referred to asC++98 or C++03; the differences between C++98 and C++03 are so few and so technical that they ought not concern users.

A late working paper is available. This is close to the final draft international standard formally accepted by a 21-0 national vote in August 2011.

Before its official ratification, we called the upcoming standard C++0x. I have not had the time to update the name consistently, sorry, and anyway I like the name C++0x :-). The name "C++0x" is a relict of the days where I and others, hoped for a C++08 or C++09. Think of 'x' as hexadecimal (i.e., C++0B == C++11).

All official documents relating to C++11/C++0x can be found at the ISO C++ committee's website. The official name of the committee is SC22 WG21.

Caveat: This FAQ will be under construction for quite a while. Comments, questions, references, corrections, and suggestions welcome.

Purpose

The purpose of this C++11 FAQ is

  • To give an overview of the new facilities (language features and standard libraries) offered by C++11 in addition to what is provided by the previous version of the ISO C++ standard.
  • To give an idea of the aims of the ISO C++ standards effort.
  • To present a user's view of the new facilities
  • To provide references to allow for a more in depth study of features.
  • To name many of the individuals who contributed (mostly as authors of the reports they wrote for the committee). The standard is not written by a faceless organization.

Please note that the purpose of this FAQ is not to provide comprehensive discussion of individual features or a detailed explanation of how to use them. The aim is to give simple examples to demonstrate what C++11 has to offer (plus references). My ideal is "max one page per feature" independently of how complex a feature is. Details can often be found in the references.

Lists of questions

Here are some high-level questions

Questions about individual language features can be found here:

I often borrow examples from the proposals. In those cases: Thanks to the proposal authors. Many of the examples are borrowed from my own talks and papers.

Questions about individual standard library facilities can be found here:

Below are answers to specific questions as indexed above.

What do you think of C++11?

That's a (to me) amazingly frequent question. It may be the most frequently asked question. Surprisingly, C++11 feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever. If you timidly approach C++ as just a better C or as an object-oriented language, you are going to miss the point. The abstractions are simply more flexible and affordable than before. Rely on the old mantra: If you think ofit as a separate idea or object, represent it directly in the program; model real-world objects, and abstractions directly in code. It's easier now: Your ideas will map toenumerations, objects, classes (e.g.control of defaults), class hierarchies (e.g.inherited constructors), templates,aliases, exceptions, loops, threads, etc., rather than to a single "one size fits all" abstraction mechanism.

My ideal is to use programming language facilities to help programmers think differently about system design and implementation. I think C++11 can do that - and do it not just for C++ programmers but for programmers used to a variety of modern programming languages in the general and very broad area of systems programming.

In other words, I'm still an optimist.

When will C++11 be a formal standard?

It is now! The first draft for formal comments was produced in September 2008. The Final International Draft standard (FCD) unanimously approved by the ISO C++ committee on March 25, 2011. It was formally approved by a 21-0 national vote in August 2011. The standard was published this year (2011).

Following convention, the new standard is called C++11 (because it was published in 2011). Personally, I prefer plain C++ and to use a year marker only when I need to distinguish it from previous versions of C++, such as ARM C++, C++98 and C++03. For a transition period, I still use C++0x in places. Think of 'x' as hexadecimal.

When will compilers implement C++11?

Currently shipping compilers (e.g. GCC C++, Clang C++,IBM C++, and Microsoft C++) already implement many C++11 features. For example, it seems obvious and popular to ship all or most of the new standard libraries.

I expect more and more features to become available with each new release. I expect to see the first complete C++11 compiler sometime in 2012, but I do not care to guess when such a compiler ships or when every compiler will provide all of C++11. I note that every C++11 feature has already been implemented by someone somewhere so there is implementation experience available for implementers to rely on.

Here are links to C++11 information from purveyors:

When will the new standard libraries be available?

Initial versions of the new standard libraries are currently shipping with the GCC,Clang and Microsoft implementations, and are available fromboost.

What new language features does C++11 provide?

You don't improve a language by simply adding every feature that someone considers a good idea. In fact, essentially every feature of most modern languages has been suggested to me for C++ by someone: Try to imagine what the superset of C99, C#, Java, Haskell, Lisp, Python, and Ada would look like. To make the problem more difficult, remember that it is not feasible to eliminate older features, even if the committee agrees that they are bad: experience shows that users force every implementer to keep providing deprecated and banned features under compatibility switches (or by default) for decades.

To try to select rationally from the flood of suggestions we devised a set of specific design aims. We couldn't completely follow them and they weren't sufficiently complete to guide the committee in every detail (and IMO couldn't possible be that complete).

The result has been a language with greatly improved abstraction mechanisms. The range of abstractions that C++ can express elegantly, flexibly, and at zero costs compared to hand-crafted specialized code has greatly increased. When we say "abstraction" people often just think "classes" or "objects." C++11 goes far beyond that: The range of user-defined types that can be cleanly and safely expressed has grown with the addition of features such asinitializer-lists,uniform initialization,template aliases, rvalue references, defaulted and deleted functions, and variadic templates. Their implementation eased with features, such as auto, inherited constructors, and decltype. These enhancements are sufficient to make C++11 feel like a new language.

For a list of accepted language features, see the feature list

What new standard libraries does C++11 provide?

I would have liked to see more standard libraries. However, note that the standard library definition is already about 70% of the normative text of the standard (and that doesn't count the C standard library, which is included by reference). Even though some of us would have liked to see many more standard libraries, nobody could claim that the Library working group has been lazy. It is also worth noting that the C++98 libraries have been significantly improved through the use of new language features, such as initializer-lists,rvalue references,variadic templates, noexcept, and constexpr. The C++11 standard library is easier to use and provides better performance that the C++98 one.

For a list of accepted libraries, see the library component list.

What were the aims of the C++11 effort?

C++ is a general-purpose programming language with a bias towards systems programming that

  • is a better C
  • supports data abstraction
  • supports object-oriented programming
  • supports generic programming

The overall aims of the C++11 effort was to strengthen that:

  • Make C++ a better language for systems programming and library building -- that is, to build directly on C++'s contributions to programming, rather than providing specialized facilities for a particular sub-community (e.g. numeric computation or Windows-style application development).
  • Make C++ easier to teach and learn -- through increased uniformity, stronger guarantees, and facilities supportive of novices (there will always be more novices than experts).

Naturally, this is done under very stringent compatibility constraints. Only very rarely is the committee willing to break standards conforming code, though that's done when a new keyword (e.g.static_assert,nullptr, andconstexpr) is introduced.

For more details see:

What specific design aims guided the committee?

Naturally, different people and different organizations involved with the standardization have somewhat different aims, especially when it comes to details and to priorities. Also, detailed aims change over time. Please remember that the committee can't even do all that everyone agrees would be good things -- it consists of volunteers with very limited resources. However, here are a set of criteria that has seen real use in the discussion of which features and libraries were appropriate for C++11:

  • Maintain stability and compatibility -- don't break old code, and if you absolutely must, don't break it quietly.
  • Prefer libraries to language extensions -- an ideal at which the committee wasn't all that successful; too many people in the committee and elsewhere prefer "real language features."
  • Prefer generality to specialization -- focus on improving the abstraction mechanisms (classes, templates, etc.).
  • Support both experts and novices -- novices can be helped by better libraries and through more general rules; experts need general and efficient features.
  • Increase type safety -- primarily though facilities that allow programmers to avoid type-unsafe features.
  • Improve performance and ability to work directly with hardware -- make C++ even better for embedded systems programming and high-performance computation.
  • Fit into the real world -- consider tool chains, implementation cost, transition problems, ABI issues, teaching and learning, etc.

Note that integrating features (new and old) to work in combination is the key -- and most of the work. The whole is much more than the simple sum of its parts.

Another way of looking at detailed aims is to look at areas of use and styles of usage:

Where can I find the committee papers?

Go to the papers section of the committee's website. There you will most likely drown in details. Look for "issues lists" and "State of " (e.g.State of Evolution (July 2008)) lists. The key groups are

  • Core (CWG) -- dealing with language-technical issues and formulation
  • Evolution (EWG) -- dealing with language feature proposals and issues crossing the language/library boundary
  • Library (LWG) -- dealing with library facility proposals

Here is the latest draft C++11 standard.

Where can I find academic and technical papers about C++11?

This list is likely to be incomplete -- and likely to frequently go out of date as people write new papers. If you find a paper that ought to be here and is not, please send it. Also, not all papers will be completely up-to-date with the latest improvements of the standard. I'll try to keep comments current.

Where else can I read about C++11?

The amount of information about C++11 is increasing as the standard nears completion and C++ implementations start providing new language features and libraries. Here is a short list of sources:

Are there any videos about C++11?

(To people who know me, this is a proof that this really is an FAQ, rather than a series of my own favorite questions; I'm not a fan of videos on technical topics -- I find the video distracting and the verbal format too likely to contain minor technical errors).

Yes:

Is C++11 hard to learn?

Well, since we can't remove any significant features from C++ without breaking large amounts of code, C++11 is larger than C++98, so if you want to know every rule, learning C++11 will be harder. This leaves us with just two tools for simplification (from the point of view of learners):

Obviously, a "bottom up" teaching/learning style will nullify any such advantage, and there are currently (obviously) very little material that takes a different approach. That ought to change with time.

How does the committee operate?

The ISO Standards committee, SC22 WG21, operates under the ISO rules for such committees. Curiously enough, these rules are not standardized and change over time.

Many countries have national standards bodies with active C++ groups. These groups hold meetings, coordinate over the web, and some send representatives to the ISO meetings. Canada, France, Germany, Switzerland, UK, and USA are present at most meetings. Denmark, the Netherlands, Japan, Norway, Spain, and others are represented in person less frequently.

Much of the work goes on in-between meetings over the web and the results are recorded as numbered committee papers on theWG21 website.

The committee meets two to three times a year for a week each time. Most work at those meetings are in sub-working groups, such as "Core", "Library", "Evolution", and "Concurrency." As needed, there are also in-between meetings of ad-hoc working groups on specific urgent topics, such as "concepts" and "memory model." Voting takes place at the main meetings. First, working groups hold "straw votes" to see if an issue is ready for presentation to the committee as a whole. Then, the committee as a whole votes (one member one vote) and if something is accepted the nations vote. We take great care that we do not get into a situation where the majority present and the nations disagrees -- proceeding if that is the case would guarantee long-term controversy. Final votes on official drafts are done by mail by the national standards bodies.

The committee has formal liaison with the C standards group (SC22 WG14) and POSIX, and more or less formal contacts with several other groups.

Who is on the committee?

The committee consists of a large number of people (about 250) out of whom 90+ turn up at the week-long meetings two or three times a year. In addition there are national standards groups and meetings in several countries. Most members contribute either by attending meetings, by taking part in email discussions, or by submitting papers for committee consideration. Most members have friends and colleagues who help them. From day #1, the committee has had members from many countries and at every meeting people from half a dozen to a dozen countries attend. The final votes are done by about 20 national standards bodies. Thus, the ISO C++ standardization is a fairly massive effort,not a small coherent group of people working to create a perfect language for "people just like themselves." The standard is what this group of volunteers can agree on as being the best they can produce thatall can live with.

Naturally, many (but not all) of these volunteers have day jobs focused on C++: We have compiler writers, tool builders, library writers, application builders (too few of those), researchers (only a few), consultants, test-suite builders, and more.

Here is a very abbreviated list of organizations involved: Adobe, Apple, Boost, Bloomberg, EDG, Google, HP, IBM, Intel, Microsoft, Red Hat, Sun.

Here is a short list of names of members who you may have encountered in the literature or on the web:Dave Abrahams, Matt Austern,Pete Becker, Hans Boehm, Steve Clamage, Lawrence Crowl,Beman Dawes,Francis Glassborow,Doug Gregor, Pablo Halpern, Howard Hinnant, Jaakko Jarvi,John Lakos, Alisdair Meredith, Jens Maurer, Jason Merrill,Sean Parent, P.J. Plauger, Tom Plum, Gabriel Dos Reis,Bjarne Stroustrup,Herb Sutter,David Vandevoorde, Michael Wong. Apologies to the 200+ current and past members that I couldn't list. Also, please note the author lists on the various papers: a standard is written by (many) individuals, not by an anonymous committee.

You can get a better impression of the breath and depth of expertise involved by examining the author lists on theWG21 papers, but please remember there are major contributors to the standards effort who do not write a lot.

Will there be a C++1y?

Almost certainly -- and not just because the committee has slipped the deadline for C++0x. The plans for minor revisions, C++14, are well advanced (the features have been voted into the working draft and implemented), and the plan is for a major revision in 2017, C++17.

What happened to "concepts"?

"Concepts" was a feature designed to allow precise specification of requirements on template arguments. Unfortunately, the committee decided that further work on concepts could seriously delay the standard and voted to remove the feature from the working paper, see my note The C++0x "Remove Concepts" Decision andA DevX interview on concepts and the implications for C++0x for an explanation.

A radically simplified version ``concepts lite'' will be part of C++14 (as a technical report).

I have not deleted the concept sections from this document, but left them at the end:

Are there any features you don't like?

Yes. There are also features in C++98 that I don't like, such as macros. The issue is not whether I like something or if I find it useful for something I want to do. The issue is whether someone has felt enough of a need to convince others to support the idea or possibly if some usage is so ingrained in a user community that it needs support.

__cplusplus

In C++11 the macro __cplusplus will be set to a value that differs from (is greater than) the current199711L.

auto -- deduction of a type from an initializer

Consider 


	auto x = 7;

Here x will have the type int because that's the type of its initializer. In general, we can write


	auto x = expression;

and the type of x will be the type of the value computed from "expression".

The use of auto to deduce the type of a variable from its initializer is obviously most useful when that type is either hard to know exactly or hard to write. Consider:


	template<class T> void printall(const vector<T>& v)
	{
		for (auto p = v.begin(); p!=v.end(); ++p)
			cout << *p << "\n";
	}

In C++98, we'd have to write 


	template<class T> void printall(const vector<T>& v)
	{
		for (typename vector<T>::const_iterator p = v.begin(); p!=v.end(); ++p)
			cout << *p << "\n";
	}

When the type of a variable depends critically on template argument it can be really hard to write code withoutauto. For example: 


	template<class T, class U> void multiply(const vector<T>& vt, const vector<U>& vu)
	{
		// ...
		auto tmp = vt[i]*vu[i];
		// ...
	}

The type of tmp should be what you get from multiplying a T by a U, but exactly what that is can be hard for the human reader to figure out, but of course the compiler knows once it has figured out what particularT and U it is dealing with.

The auto feature has the distinction to be the earliest to be suggested and implemented: I had it working in my Cfront implementation in early 1984, but was forced to take it out because of C compatibility problems. Those compatibility problems disappeared when C++98 and C99 accepted the removal of "implicit int"; that is, both languages require every variable and function to be defined with an explicit type. The old meaning ofauto ("this is a local variable") is now illegal. Several committee members trawled through millions of lines of code finding only a handful of uses -- and most of those were in test suites or appeared to be bugs.

Being primarily a facility to simplify notation in code, auto does not affect the standard library specification.

See also

Range-for statement

A range for statement allows you to iterate through a "range", which is anything you can iterate through like an STL-sequence defined by a begin() and end(). All standard containers can be used as a range, as can a std::string, an initializer list, an array, and anything for which you define begin() and end(), e.g. an istream. For example:


void f(vector<double>& v)
{
	for (auto x : v) cout << x << '\n';
	for (auto& x : v) ++x;	// using a reference to allow us to change the value
}

You can read that as "for all x in v" going through starting with v.begin() and iterating to v.end(). Another example:


	for (const auto x : { 1,2,3,5,8,13,21,34 }) cout << x << '\n';

The begin() (and end()) can be a member to be calledx.begin() or a free-standing function to be called begin(x). The member version takes precedence.

See also

right-angle brackets

Consider 


	list<vector<string>> lvs;

In C++98 this is a syntax error because there is no space between the two >s. C++11 recognizes such two>s as a correct termination of two template argument lists.

Why was this ever a problem? A compiler front-end is organized parses/stages. This is about the simplest model:

  • lexical analysis (make up tokens from characters)
  • syntax analysis (check the grammar)
  • type checking (find the type of names and expressions)

These stages are in theory and sometimes in practice strictly separate, so the lexical analyzer that determines that>> is a token (usually meaning right-shift or input) has no idea of its meaning; in particular, it has no idea of templates or nested template argument lists. However, to get that example "correct" the three stages has somehow to cooperate. The key observation that led to the problem being resolved was that every C++ compiler already did understand the problem so that it could give decent error messages.

See also

control of defaults: default and delete

The common idiom of "prohibiting copying" can now be expressed directly: 


	class X {
		// ...
		X& operator=(const X&) = delete;	// Disallow copying
		X(const X&) = delete;
	};

Conversely, we can also say explicitly that we want to default copy behavior: 


	class Y {
		// ...
		Y& operator=(const Y&) = default;	// default copy semantics
		Y(const Y&) = default;
	};

Being explicit about the default is redundant. However, comments about copy operations and (worse) a user explicitly defining copy operations meant to give the default behavior are not uncommon. Leaving it to the compiler to implement the default behavior is simpler, less error-prone, and often leads to better object code.

The "default" mechanism can be used for any function that has a default. The "delete" mechanism can be used for any function. For example, we can eliminate an undesired conversion like this:


	struct Z {
		// ...

		Z(long long);     // can initialize with an long long
		Z(long) = delete; // but not anything less
	};

See also

control of defaults: move and copy

By default, a class has 5 operations:

  • copy assignment
  • copy constructor
  • move assignment
  • move constructor
  • destructor

If you declare any of those you must consider all and explicitly define or default the ones you want. Think of copying, moving, and destruction as closely related operations, rather than individual operations that you can freely mix and match - you can specify arbitrary combinations, but only a few combinations make sense semantically.

If any move, copy, or destructor is explicitly specified (declared, defined, =default, or =delete) by the user, no move is generated by default. If any move, copy, or destructor is explicitly specified (declared, defined, =default, or =delete) by the user, any undeclared copy operations are generated by default, but this is deprecated, so don't rely on that. For example: 


	class X1 {
		X1& operator=(const X1&) = delete;	// Disallow copying
	};


This implicitly also disallows moving of X1s. Copy initialization is allowed, but deprecated.


	class X2 {
		X2& operator=(const X2&) = delete;
	};

This implicitly also disallows moving of X2s. Copy initialization is allowed, but deprecated.


	class X3 {
		X3& operator=(X3&&) = delete;	// Disallow moving
	};

This implicitly also disallows copying of X3s. 


	class X4 {
		~X4() = delete;	// Disallow destruction
	};

This implicitly also disallows moving of X4s. Copying is allowed, but deprecated.

I strongly recommend that if you declare one of these five function, you explicitly declare all. For example:


	template<class T>
	class Handle {
		T* p;
	public:
		Handle(T* pp) : p{pp} {}
		~Handle() { delete p; }		// user-defined destructor: no implicit copy or move 

		Handle(Handle&& h) :p{h.p} { h.p=nullptr; }			// transfer ownership
		Handle& operator=(Handle&& h) { delete p; p=h.p; h.p=nullptr; return *this; }	// transfer ownership

		Handle(const Handle&) = delete;		// no copy
		Handle& operator=(const Handle&) = delete;

		// ...
	};

See also

the C++ draft section ??? [N2326==07-0186] Lawrence Crowl: Defaulted and Deleted Functions.[N3174=100164] B. Stroustrup: To move or not to move. An analysis of problems related to generated copy and move operations. Approved.

enum class -- scoped and strongly typed enums

The enum classes ("new enums", "strong enums") address three problems with traditional C++ enumerations:

  • conventional enums implicitly convert to int, causing errors when someone does not want an enumeration to act as an integer.
  • conventional enums export their enumerators to the surrounding scope, causing name clashes.
  • the underlying type of an enum cannot be specified, causing confusion, compatibility problems, and makes forward declaration impossible.

enum classs ("strong enums") are strongly typed and scoped: 


	enum Alert { green, yellow, orange, red }; // traditional enum

	enum class Color { red, blue };   // scoped and strongly typed enum
	                                  // no export of enumerator names into enclosing scope
	                                  // no implicit conversion to int
	enum class TrafficLight { red, yellow, green };

	Alert a = 7;              // error (as ever in C++)
	Color c = 7;              // error: no int->Color conversion

	int a2 = red;             // ok: Alert->int conversion
	int a3 = Alert::red;      // error in C++98; ok in C++11
	int a4 = blue;            // error: blue not in scope
	int a5 = Color::blue;     // error: not Color->int conversion

	Color a6 = Color::blue;   // ok

As shown, traditional enums work as usual, but you can now optionally qualify with theenum's name.

The new enums are "enum class" because they combine aspects of traditional enumerations (names values) with aspects of classes (scoped members and absence of conversions).

Being able to specify the underlying type allow simpler interoperability and guaranteed sizes of enumerations:


	enum class Color : char { red, blue };	// compact representation

	enum class TrafficLight { red, yellow, green };  // by default, the underlying type is int

	enum E { E1 = 1, E2 = 2, Ebig = 0xFFFFFFF0U };   // how big is an E?
	                                                 // (whatever the old rules say;
	                                                 // i.e. "implementation defined")

	enum EE : unsigned long { EE1 = 1, EE2 = 2, EEbig = 0xFFFFFFF0U };   // now we can be specific

It also enables forward declaration of enums: 


	enum class Color_code : char;     // (forward) declaration
	void foobar(Color_code* p);       // use of forward declaration
	// ...
	enum class Color_code : char { red, yellow, green, blue }; // definition

The underlying type must be one of the signed or unsigned integer types; the default isint.

In the standard library, enum classes are used

  • For mapping systems specific error codes: In <system_error>: enum class errc;
  • For pointer safety indicators: In <memory>: enum class pointer_safety { relaxed, preferred, strict };
  • For I/O stream errors: In <iosfwd>: enum class io_errc { stream = 1 };
  • For asynchronous communications error handling: In <future>: enum class future_errc { broken_promise, future_already_retrieved, promise_already_satisfied };

Several of these have operators, such as == defined.

See also

constexpr -- generalized and guaranteed constant expressions

The constexpr mechanism

  • provides more general constant expressions
  • allows constant expressions involving user-defined types
  • provides a way to guarantee that an initialization is done at compile time

Consider 


	enum Flags { good=0, fail=1, bad=2, eof=4 };

	constexpr int operator|(Flags f1, Flags f2) { return Flags(int(f1)|int(f2)); }

	void f(Flags x)
	{
		switch (x) {
		case bad:         /* ... */ break;
		case eof:         /* ... */ break;
		case bad|eof:     /* ... */ break;
		default:          /* ... */ break;
		}
	}

Here constexpr says that the function must be of a simple form so that it can be evaluated at compile time if given constant expressions arguments.

In addition to be able to evaluate expressions at compile time, we want to be able torequire expressions to be evaluated at compile time; constexpr in front of a variable definition does that (and impliesconst): 


	constexpr int x1 = bad|eof;	// ok

	void f(Flags f3)
	{
		constexpr int x2 = bad|f3;	// error: can't evaluate at compile time
		int x3 = bad|f3;		// ok
	}

Typically we want the compile-time evaluation guarantee for global or namespace objects, often for objects we want to place in read-only storage.

This also works for objects for which the constructors are simple enough to beconstexpr and expressions involving such objects: 


	struct Point {
		int x,y;
		constexpr Point(int xx, int yy) : x(xx), y(yy) { }
	};

	constexpr Point origo(0,0);
	constexpr int z = origo.x;

	constexpr Point a[] = {Point(0,0), Point(1,1), Point(2,2) };
	constexpr int x = a[1].x;	// x becomes 1

Please note that constexpr is not a general purpose replacement forconst (or vise versa):

  • const's primary function is to express the idea that an object is not modified through an interface (even though the object may very well be modified through other interfaces). It just so happens that declaring an objectconst provides excellent optimization opportunities for the compiler. In particular, if an object is declaredconst and its address isn't taken, a compiler is often able to evaluate its initializer at compile time (though that's not guaranteed) and keep that object in its tables rather than emitting it into the generated code.
  • constexpr's primary function is to extend the range of what can be computed at compile time, making such computation type safe. Objects declaredconstexpr have their initializer evaluated at compile time; they are basically values kept in the compiler's tables and only emitted into the generated code if needed.

See also

decltype -- the type of an expression

decltype(E) is the type ("declared type") of the name or expressionE and can be used in declarations. For example: 


	void f(const vector<int>& a, vector<float>& b)
	{
		typedef decltype(a[0]*b[0]) Tmp;
		for (int i=0; i<b.size(); ++i) {
			Tmp* p = new Tmp(a[i]*b[i]);
			// ...
		}
		// ...
	}

This notion has been popular in generic programming under the label "typeof" for a long time, but thetypeof implementations in actual use were incomplete and incompatible, so the standard version is nameddecltype.

If you just need the type for a variable that you are about to initialize auto is often a simpler choice. You really need decltype if you need a type for something that is not a variable, such as areturn type.

See also

  • the C++ draft 7.1.6.2 Simple type specifiers
  • [Str02] Bjarne Stroustrup. Draft proposal for "typeof". C++ reflector message c++std-ext-5364, October 2002. (original suggestion).
  • [N1478=03-0061] Jaakko Jarvi, Bjarne Stroustrup, Douglas Gregor, and Jeremy Siek:Decltype and auto (original proposal).
  • [N2343=07-0203] Jaakko Jarvi, Bjarne Stroustrup, and Gabriel Dos Reis: Decltype (revision 7): proposed wording.

Initializer lists

Consider 

 
	vector<double> v = { 1, 2, 3.456, 99.99 };
	list<pair<string,string>> languages = {
		{"Nygaard","Simula"}, {"Richards","BCPL"}, {"Ritchie","C"}
	}; 
	map<vector<string>,vector<int>> years = {
		{ {"Maurice","Vincent", "Wilkes"},{1913, 1945, 1951, 1967, 2000} },
		{ {"Martin", "Ritchards"}, {1982, 2003, 2007} }, 
		{ {"David", "John", "Wheeler"}, {1927, 1947, 1951, 2004} }
	};

Initializer lists are not just for arrays any more. The mechanism for accepting a{}-list is a function (often a constructor) accepting an argument of typestd::initializer_list<T>. For example: 


	void f(initializer_list<int>);
	f({1,2});
	f({23,345,4567,56789});
	f({});	// the empty list
	f{1,2};	// error: function call ( ) missing

	years.insert({{"Bjarne","Stroustrup"},{1950, 1975, 1985}});

The initializer list can be of arbitrary length, but must be homogeneous (all elements must be of a the template argument type,T, or convertible to T).

A container might implement an initializer-list constructor like this: 


	template<class E> class vector {
	public:
   		vector (std::initializer_list<E> s) // initializer-list constructor
   		{
      			reserve(s.size());	// get the right amount of space
      			uninitialized_copy(s.begin(), s.end(), elem);	// initialize elements (in elem[0:s.size()))
			sz = s.size();	// set vector size
   		}
   	
		// ... as before ...
	};

The distinction between direct initialization and copy initialization is maintained for{}-initialization, but becomes relevant less frequently because of{}-initialization. For example, std::vector has anexplicit constructor from int and an initializer-list constructor:


	vector<double> v1(7);	// ok: v1 has 7 elements
	v1 = 9;			// error: no conversion from int to vector
	vector<double> v2 = 9;	// error: no conversion from int to vector

	void f(const vector<double>&);
	f(9);				// error: no conversion from int to vector

	vector<double> v1{7};		// ok: v1 has 1 element (with its value 7.0)
	v1 = {9};			// ok v1 now has 1 element (with its value 9.0)
	vector<double> v2 = {9};	// ok: v2 has 1 element (with its value 9.0)
	f({9});				// ok: f is called with the list { 9 }

	vector<vector<double>> vs = {
		vector<double>(10), 	// ok: explicit construction (10 elements)
		vector<double>{10},	// ok: explicit construction (1 element with the value 10.0)
		10 			// error: vector's constructor is explicit
	};

The function can access the initializer_list as an immutable sequence. For example:


	void f(initializer_list<int> args)
	{
		for (auto p=args.begin(); p!=args.end(); ++p) cout << *p << "\n";
	}

A constructor that takes a single argument of type std::initializer_list is called an initializer-list constructor.

The standard library containers, string, and regex have initializer-list constructors, assignment, etc. An initializer-list can be used as a range, e.g. in arange for statement

The initializer lists are part of the scheme for uniform and general initialization.

See also

Preventing narrowing

The problem: C and C++ implicitly truncates: 


	int x = 7.3;		// Ouch!
	void f(int);
	f(7.3);			// Ouch!

However, in C++11, {} initialization doesn't narrow: 


	int x0 {7.3};	// error: narrowing
	int x1 = {7.3};	// error: narrowing
	double d = 7;
	int x2{d};		// error: narrowing (double to int)
	char x3{7};		// ok: even though 7 is an int, this is not narrowing
	vector<int> vi = { 1, 2.3, 4, 5.6 };	// error: double to int narrowing

The way C++11 avoids a lot of incompatibilities is by relying on the actual values of initializers (such as 7 in the example above) when it can (and not just type) when deciding what is a narrowing conversion. If a value can be represented exactly as the target type, the conversion is not narrowing. 

	char c1{7};      // OK: 7 is an int, but it fits in a char
	char c2{77777};  // error: narrowing (assuming 8-bit chars)

Note that floating-point to integer conversions are always considered narrowing -- even 7.0 to 7.

See also

Delegating constructors

In C++98, if you want two constructors to do the same thing, repeat yourself or call "an init() function." For example:


	class X {
		int a;
		void validate(int x) { if (0<x && x<=max) a=x; else throw bad_X(x); }
	public:
		X(int x) { validate(x); }
		X() { validate(42); }
		X(string s) { int x = lexical_cast<int>(s); validate(x); }
		// ...
	};

Verbosity hinders readability and repetition is error-prone. Both get in the way of maintainability. So, in C++11, we can define one constructor in terms of another:


	class X {
		int a;
	public:
		X(int x) { if (0<x && x<=max) a=x; else throw bad_X(x); }
		X() :X{42} { }
		X(string s) :X{lexical_cast<int>(s)} { }
		// ...
	};

See also

In-class member initializers

In C++98, only static const members of integral types can be initialized in-class, and the initializer has to be a constant expression. These restrictions ensure that we can do the initialization at compile-time. For example:


	int var = 7;

	class X {
		static const int m1 = 7;        // ok
		const int m2 = 7;                	// error: not static
		static int m3 = 7;              // error: not const
		static const int m4 = var;       	// error: initializer not constant expression
		static const string m5 = "odd"; // error: not integral type
		// ...
	};

The basic idea for C++11 is to allow a non-static data member to be initialized where it is declared (in its class). A constructor can then use the initializer when run-time initialization is needed. Consider:


	class A {
	public:
		int a = 7;
	};

This is equivalent to: 


	class A {
	public:
		int a;
		A() : a(7) {}
	};

This saves a bit of typing, but the real benefits come in classes with multiple constructors. Often, all constructors use a common initializer for a member:


	class A {
	public:
		A(): a(7), b(5), hash_algorithm("MD5"), s("Constructor r




猜你喜欢

转载自blog.csdn.net/doitsjz/article/details/73656946
今日推荐
《美国对全球网络空间安全与发展的威胁和破坏》报告发布
火速冲上 GitHub 热榜 —— 开源编程语言、框架哪有这么可爱？
北京人形机器人创新中心发布全球首个纯电驱拟人奔跑的全尺寸人形机器人“天工”
LFOSSA 源来如此公开课 | 掌握云原生未来：CNCF 认证全面攻略与备考秘籍
周排行
循环神经网络（rnn）讲解
Tigao教程四：单独的关节运动
金蝶K3WISE15.0-注册套打教程
如何在Mac上配置Kubernetes
Android应用结束自身进程的方法
SpringMVC学习 十三 拦截器栈
中国驻洛杉矶总领馆举行新春招待会
HttpClient get post 发送
11 - three.js 笔记 - 绘制三维字体模型
Mysql递归获取某个父节点下面的所有子节点和子节点上的所有父节点
每日归档
更多
2024-05-01(4)
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)
2024-04-27(56)
2024-04-26(39)
2024-04-25(22)
2024-04-24(36)
2024-04-23(26)
2024-04-22(39)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022