Decltype

Quality 0.50 · 0 views · Updated 2 months ago

Feature introduced in C++11

title: "Decltype" type: doc version: 1 created: 2026-02-28 author: "Wikipedia contributors" status: active scope: public tags: ["c++", "articles-with-example-c++-code"] description: "Feature introduced in C++11" topic_path: "general/c" source: "https://en.wikipedia.org/wiki/Decltype" license: "CC BY-SA 4.0" wikipedia_page_id: 0 wikipedia_revision_id: 0

::summary Feature introduced in C++11 ::

In the C++ programming language, **decltype** (for "declared type") is a keyword used to query the type of an expression. Introduced in C++11, its primary intended use is in generic programming, where it is often difficult, or even impossible, to express types that depend on template parameters.

As generic programming techniques became increasingly popular throughout the 1990s, the need for a type-deduction mechanism was recognized. Many compiler vendors implemented their own versions of the operator, typically called [typeof](typeof), and some portable implementations with limited functionality, based on existing language features were developed. In 2002, Bjarne Stroustrup proposed that a standardized version of the operator be added to the C++ language, and suggested the name "decltype", to reflect that the operator would yield the "declared type" of an expression.

decltype's semantics were designed to cater to both generic library writers and novice programmers. In general, the deduced type matches the type of the object or function exactly as declared in the source code. Like the sizeof operator, decltype's operand is not evaluated.

Motivation

With the introduction of templates into the C++ programming language, and the advent of generic programming techniques pioneered by the Standard Template Library, the need for a mechanism for obtaining the type of an expression, commonly referred to as [typeof](typeof), was recognized. In generic programming, it is often difficult or impossible to express types that depend on template parameters, in particular the return type of function template instantiations.

Many vendors provide the typeof operator as a compiler extension. As early as 1997, before C++ was fully standardized, Brian Parker proposed a portable solution based on the [sizeof](sizeof) operator. His work was expanded on by Bill Gibbons, who concluded that the technique had several limitations and was generally less powerful than an actual typeof mechanism. In an October 2000 article of Dr. Dobb's Journal, Andrei Alexandrescu remarked that "having a typeof would make much template code easier to write and understand." He also noted that "typeof and sizeof share the same backend, because sizeof has to compute the type anyway." Andrew Koenig and Barbara E. Moo also recognized the usefulness of a built-in typeof facility, with the caveat that "using it often invites subtle programming errors, and there are some problems that it cannot solve." They characterized the use of type conventions, like the typedefs provided by the Standard Template Library, as a more powerful and general technique. However, Steve Dewhurst argued that such conventions are "costly to design and promulgate", and that it would be "much easier to ... simply extract the type of the expression." In a 2011 article on C++0x, Koenig and Moo predicted that "decltype will be widely used to make everyday programs easier to write."

In 2002, Bjarne Stroustrup suggested extending the C++ language with mechanisms for querying the type of an expression, and initializing objects without specifying the type. Stroustrup observed that the reference-dropping semantics offered by the typeof operator provided by the GCC and EDG compilers could be problematic. Conversely, an operator returning a reference type based on the lvalue-ness of the expression was deemed too confusing. The initial proposal to the C++ standards committee outlined a combination of the two variants; the operator would return a reference type only if the declared type of the expression included a reference. To emphasize that the deduced type would reflect the "declared type" of the expression, the operator was proposed to be named decltype.

One of the cited main motivations for the decltype proposal was the ability to write perfect forwarding function templates. It is sometimes desirable to write a generic forwarding function that returns the same type as the wrapped function, regardless of the type it is instantiated with. Without decltype, it is not generally possible to accomplish this. An example, which also utilizes the trailing-return-type: ::code[lang=cpp] int& foo(int& i); float foo(float& f);

template auto transparent_forwarder(T& t) −> decltype(foo(t)) { return foo(t); } ::

decltype is essential here because it preserves the information about whether the wrapped function returns a reference type.

Semantics

Otherwise, the result is defined simply as the type T of the expression if e is an rvalue, or "reference to T" if e is an lvalue

Similarly to the [sizeof](sizeof) operator, the operand of decltype is unevaluated, so expressions like decltype(i++) will not result in an increment of the variable i. Informally, the type returned by decltype(e) is deduced as follows:

  1. If the expression e refers to a variable in local or namespace scope, a static member variable or a function parameter, then the result is that variable's or parameter's declared type
  2. Otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e; if e is an xvalue, the result is T&&; otherwise, e is a prvalue and the result is T.
  3. As a special case, [decltype(auto)](decltype-auto) allows for type deduction like [auto](c-11-type-inference) but it preserves the value category of the initializer. More specifically, it is equivalent to decltype(*initializer*).

These semantics were designed to fulfill the needs of generic library writers, while at the same time being intuitive for novice programmers, because the return type of decltype always matches the type of the object or function exactly as declared in the source code. More formally, Rule 1 applies to unparenthesized id-expressions and class member access expressions. Example: Note for added lines for bar(). Below the type deduced for "bar()" is plain int, not const int, because prvalues of non-class types always have cv-unqualified types, despite the statically declared different type.

::code[lang=cpp] const int&& foo(); const int bar(); int i; struct A { double x; }; const A* a = new A(); decltype(foo()) x1; // type is const int&& decltype(bar()) x2; // type is int decltype(i) x3; // type is int decltype(a->x) x4; // type is double decltype((a->x)) x5; // type is const double& ::

The reason for the difference between the latter two invocations of decltype is that the parenthesized expression (a-x) is neither an id-expression nor a member access expression, and therefore does not denote a named object. Because the expression is an lvalue, its deduced type is "reference to the type of the expression", or const double&. The fact that extra parentheses introduce a reference qualifier to the type can be a source of errors for programmers who do not fully understand decltype.

In December 2008, a concern was raised to the committee by Jaakko Järvi over the inability to use decltype to form a qualified-id, which is inconsistent with the intent that decltype(e) should be treated "as if it were a typedef-name". While commenting on the formal Committee Draft for C++0x, the Japanese ISO member body noted that "a scope operator(::) cannot be applied to decltype, but it should be. It would be useful in the case to obtain member type(nested-type) from an instance as follows: ::code[lang=cpp] vector

This, and similar issues pertaining to the wording inhibiting the use of decltype in the declaration of a derived class and in a destructor call, were addressed by David Vandevoorde, and voted into the working paper in March 2010.

Availability

decltype is included in the C++ Language Standard since C++11. It is provided by a number of compilers as an extension. Microsoft's Visual C++ 2010 and later compilers provide a decltype type specifier that closely mimics the semantics as described in the standards committee proposal. It can be used with both managed and native code. The documentation states that it is "useful primarily to developers who write template libraries." decltype was added to the mainline of the GCC C++ compiler in version 4.3, released on March 5, 2008. decltype is also present in Codegear's C++ Builder 2009, the Intel C++ Compiler, and Clang.

References

--

References

  1. Kalev, Danny. (2008-05-08). "Clean Up Function Syntax Mess with ''decltype''". DevX.com.
  2. Gibbons, Bill. (2000-11-01). "A Portable "typeof" Operator". [[Dr. Dobb's Journal]].
  3. Alexandrescu, Andrei. (2000-10-01). "Generic: Mappings between Types and Values". [[Dr. Dobb's Journal]].
  4. Koenig, Andrew. (2002-02-01). "C++ Made Easier: Naming Unknown Types". [[Dr. Dobb's Journal]].
  5. Dewhurst, Steve. (2000-08-01). "Common Knowledge: A Bitwise typeof Operator, Part 1". [[Dr. Dobb's Journal]].
  6. Gregor, Douglas. (2003-04-28). "Decltype and auto". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  7. Dos Reis, Gabriel. (2004-10-12). "Decltype and auto (revision 4)". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  8. Miller, William M.. (2009-08-03). "C++ Standard Core Language Defect Reports, Revision 65". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  9. Becker, Pete. "Working Draft, Standard for Programming Language C++". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  10. Miller, William M.. (2009-08-03). "C++ Standard Core Language Closed Issues, Revision 65". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  11. "decltype Operator". [[Microsoft.
  12. (2009-08-27). "C++0x Support in GCC". [[Free Software Foundation]].
  13. (2009-08-13). "GCC 4.3 Release Series". [[Free Software Foundation]].
  14. "Type Specifier decltype (C++0x)". Embarcadero Technologies.
  15. "std, Qstd". [[Intel Corporation]].
  16. Gregor, Douglas. (2011-01-26). "New C++0x feature support in Clang".
  17. Miller, William M.. (2009-09-29). "C++ Standard Core Language Active Issues, Revision 66". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  18. Miller, William M.. (2009-08-03). "C++ CD1 Comment Status". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  19. Dos Reis, Gabriel. (2006-11-05). "Decltype (revision 6): proposed wording". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  20. Miller, William M.. (2010-03-29). "C++ Standard Core Language Defect Reports, Revision 69". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  21. Vandevoorde, Daveed. (2010-02-03). "Core issues 743 and 950: Additional decltype(...) uses". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.
  22. Mazières, David. (June 2021). "C++ value categories and decltype demystified".
  23. Vandevoorde, Daveed. (2009-09-22). "Core issue 743: decltype(...) name qualifiers". ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee.

::callout[type=info title="Wikipedia Source"] This article was imported from Wikipedia and is available under the Creative Commons Attribution-ShareAlike 4.0 License. Content has been adapted to SurfDoc format. Original contributors can be found on the article history page. ::

c++articles-with-example-c++-code