`auto` follows the template argument deduction rules and is always an object type; `decltype(auto)` follows the `decltype` rules for deducing reference types based on value categories. So if we have

    int x;
    int &amp;&amp; f();

then

    expression    auto       decltype(auto)
    ----------------------------------------
    10            int        int
    x             int        int
    (x)           int        int &amp;
    f()           int        int &amp;&amp;


`auto` returns what value-type would be deduced of you assigned the `return` clause to an `auto` variable.  `decltype(auto)` returns what type you would get if you wrapped the return clause in `decltype`.

`auto` returns by value, `decltype` maybe not.


I&#39;m developing packaged app for chrome store using one-time chrome wallet payments. For my app I need to check during the runtime if user bought the app or not to decide should it be demo functionality or full functionality.

According to the chrome [identity API documentation][1] :

&gt; to keep application ID constant, You need to copy the key in the
&gt; installed manifest.json to your source manifest.

I have 2 questions about this procedure:  

1) under what condition the id of my application may change? I&#39;ve tried to re-install the app and made updates but the apps id remains the same.. If there is no way to change apps id than why do I need this procedure for?

2) how can I upload my zip archive with manifest.json (which contains &quot;key&quot; field) to chrome dashboard? The problem is that uploader throw an error at me: 

&gt; An error occurred: Failed to process your item.

&gt; key field is not allowed in manifest. 


  [1]: http://developer.chrome.com/apps/app_identity.html#copy_key

How to change chrome packaged app id Or Why do we need key field in the manifest.json?

Can anyone tell me why I&#39;m getting this error with AndroidStudio?

    Execution failed for task &#39;:sampleapp:preBuild&#39;.
    &gt; Build Tools Revision 19.0.0+ is required.

I have installed Android Build-tools 19.0.1 from the Android SDK manager

Failed to build project with Android studio

I rarely see `decltype(auto)` but when I do it confuses me because it seems to do the same thing as `auto` when returning from a function.

    auto g() { return expr; }
    decltype(auto) g() { return expr; }

What is the difference between these two syntaxes?

What is the difference between auto and decltype(auto) when returning from a function?

I rarely see <code>decltype(auto)</code> but when I do it confuses me because it seems to do the same thing as <code>auto</code> when returning from a function.
<pre><code class="hljs language-arduino">auto g() { return expr; }
decltype(auto) g() { return expr; }
</code></pre>
What is the difference between these two syntaxes?

What is the proper way to create an unique_ptr that holds an array that is allocated on the free store? Visual studio 2013 supports this by default, but when I use gcc version 4.8.1 on Ubuntu I get memory leaks and undefined behaviour.

The problem can be reproduced with this code:   

    #include &lt;memory&gt;
    #include &lt;string.h&gt;
    
    using namespace std;
    
    int main()
    {
    	unique_ptr&lt;unsigned char&gt; testData(new unsigned char[16000]());
    
    	memset(testData.get(),0x12,0);
    
    	return 0;
    }

Valgrind will give this output:

    ==3894== 1 errors in context 1 of 1:
    ==3894== Mismatched free() / delete / delete []
    ==3894==    at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==3894==    by 0x400AEF: std::default_delete&lt;unsigned char&gt;::operator()(unsigned char*) const (unique_ptr.h:67)
    ==3894==    by 0x4009D0: std::unique_ptr&lt;unsigned char, std::default_delete&lt;unsigned char&gt; &gt;::~unique_ptr() (unique_ptr.h:184)
    ==3894==    by 0x4007A9: main (test.cpp:19)
    ==3894==  Address 0x5a1a040 is 0 bytes inside a block of size 16,000 alloc&#39;d
    ==3894==    at 0x4C2AFE7: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==3894==    by 0x40075F: main (test.cpp:15)



Proper way to create unique_ptr that holds an allocated array

Consider this:

    #include &lt;functional&gt;
    #include &lt;iostream&gt;
    
    std::function&lt;void()&gt; make_function(int&amp; x) {
        return [&amp;]{ std::cout &lt;&lt; x &lt;&lt; std::endl; };
    }
    
    int main() {
        int i = 3;
        auto f = make_function(i);
        i = 5;
        f();
    }

Is this program guaranteed to output `5` without invoking undefined behavior?

I understand how it works if I capture `x` by value (`[=]`), but I am not sure if I am invoking undefined behavior by capturing it by reference. Could it be that I will end up with a dangling reference after `make_function` returns, or is the captured reference guaranteed to work as long as the originally referenced object is still there?

Looking for definitive standards-based answers here :) It works well enough in practice _so far_ ;)

Capturing a reference by reference in a C++11 lambda

Given the new toolset provided by c++ lots of programmers, aiming at code simplification, expressiveness, efficiency, skim through their old code and make tweaks (some pointless, some successful) to achieve their goals. Whilst trying not to loose too much time on such labors and just make non intrusive and self contained changes, what are the best practices? 

Let me cross out the obvious :

- Use **auto** to run iterator based loops :
     
        for (std::vector&lt;foo&gt;::const_iterator it(lala.begin()), ite(lala.end()); it != ite;     
        ++it);
        // becomes
        for (auto it(lala.cbegin()), ite(lala.cend()); it != ite; ++it);


- Use **tie** for multiple assignments that just produce C-style rows of code ( https://stackoverflow.com/questions/9269825/how-to-assign-multiple-values-into-a-struct-at-once/21513616#21513616 )

        a = 1;
        b = 2; 
        c = 3;
        d = 4; 
        e = 5;
        // becomes
        std::tie(a, b, c, d, e) = std::make_tuple(1, 2, 3, 4, 5);

- To make a class non inheritable just declare it as &quot;final&quot; and delete the code that achieved such a behavior http://www.parashift.com/c++-faq/final-classes.html 

- Use the delete keyword to explicitly hide constructors/destructors instead of declaring them private (eg code to create heap based objects, non copyable objects etc)

- Turn trivial functors created just to facillitate the execution of a single STL algorithm into **lambda** functions (apart from reducing code cluttering you&#39;ll have guaranteed inlined calls)

- Simplify RAII wrapping of an object by just using a **smart pointer**

- Get rid of bind1st, bind2nd and just use **bind**

- Replace hand written code for type traits (Is_ptr_but_dont_call_for_const_ptrs&lt;&gt; and such :) ) with standard code provided by **&lt; type_traits &gt;**

- Stop including boost headers for functionallity now implented in STL (BOOST_STATIC_ASSERT vs static_assert) 

- Provide move semantics to classes (although this wouldn&#39;t qualify as a dirty/quick/easy change)

- Use **nullptr** where possible instead of the NULL macro and get rid of the code that filled containers of pointers with 0&#39;s casted to object type

        std::vector&lt;foo*&gt; f(23);
        for (std::size_t i(0); i &lt; 23; ++i)
        { f[i] = static_cast&lt;foo*&gt;(0); }
        // becomes
        std::vector&lt;foo*&gt; f(23, nullptr);

- Clear the vector data accessing syntax

        std::vector&lt;int&gt; vec;
        &amp;vec[0];    // access data as a C-style array
        vec.data(); // new way of saying the above

- Replace throw() with **noexcept** (apart from avoiding the deprecated exception specifiation you get some speed benefits http://channel9.msdn.com/Events/GoingNative/2013/An-Effective-Cpp11-14-Sampler @ 00.29.42) 

        void some_func() noexcept; // more  optimization options
        void some_func() throw();  // fewer optimization options
        void some_func() ;         // fewer optimization options

- Replace code where you&#39;d push a tempory in a container and hoped that the optimizer would ellide the copy away, with an **&quot;emplace&quot;** function where available, in order to perfectly forward the argument and construct directly an object into a container without temporary at all.

        vecOfPoints.push_back(Point(x,y,z)); // so &#39;03
        vecOfPoints.emplace_back(x, y, z);   // no copy or move operations performed

UPDATE
------

[The answer by Shafik Yaghmour](https://stackoverflow.com/a/21519186/2567683) was rightfully awarded the bounty for having the greatest acceptance by the audience. 

[The answer by R Sahu](https://stackoverflow.com/a/22802574/2567683) was my accepted one, because the **combination** of features it proposes captures the [**spirit of refactoring**](http://c2.com/cgi/wiki?WhatIsRefactoring) :  making code clearer and cleaner and simpler and elegant.

Refactoring with C++ 11

How does C++ STL unordered_map resolve collisions?

Looking at the http://www.cplusplus.com/reference/unordered_map/unordered_map/, it says &quot;Unique keys
No two elements in the container can have equivalent keys.&quot;

That should mean that the container is indeed resolving collisions. However, that page does not tell me how it is doing it. I know some ways to resolve collisions like using linked lists and/or probing. What I want to know is how the c++ STL unordered_map is resolving it.

How does C++ STL unordered_map resolve collisions?

I&#39;ve just lost three days of my life tracking down a very strange bug where unordered_map::insert() destroys the variable you insert. This highly non-obvious behaviour occurs in very recent compilers only: I found that clang 3.2-3.4 and GCC 4.8 are the **only** compilers to demonstrate this &quot;feature&quot;.

Here&#39;s some reduced code from my main code base which demonstrates the issue:

&lt;!-- language: c++ --&gt;

    #include &lt;memory&gt;
    #include &lt;unordered_map&gt;
    #include &lt;iostream&gt;
    
    int main(void)
    {
      std::unordered_map&lt;int, std::shared_ptr&lt;int&gt;&gt; map;
      auto a(std::make_pair(5, std::make_shared&lt;int&gt;(5)));
      std::cout &lt;&lt; &quot;a.second is &quot; &lt;&lt; a.second.get() &lt;&lt; std::endl;
      map.insert(a); // Note we are NOT doing insert(std::move(a))
      std::cout &lt;&lt; &quot;a.second is now &quot; &lt;&lt; a.second.get() &lt;&lt; std::endl;
      return 0;
    }

I, like probably most C++ programmers, would expect output to look something like this:

    a.second is 0x8c14048
    a.second is now 0x8c14048

But with clang 3.2-3.4 and GCC 4.8 I get this instead:

    a.second is 0xe03088
    a.second is now 0

Which might make no sense, until you examine closely the docs for unordered_map::insert() at http://www.cplusplus.com/reference/unordered_map/unordered_map/insert/ where overload no 2 is:

&lt;!-- language: c++ --&gt;

    template &lt;class P&gt; pair&lt;iterator,bool&gt; insert ( P&amp;&amp; val );

Which is a greedy universal reference move overload, consuming anything not matching any of the other overloads, and *move constructing* it into a value_type. So why did our code above choose this overload, and not the unordered_map::value_type overload as probably most would expect?

The answer stares you in the face: unordered_map::value_type is a pair&lt;*const* int, std::shared_ptr&lt;int&gt;&gt; and the compiler would correctly think that a pair&lt;*int*, std::shared_ptr&lt;int&gt;&gt; isn&#39;t convertible. Therefore the compiler chooses the move universal reference overload, and that destroys the original, **despite** the programmer not using std::move() which is the typical convention for indicating you are okay with a variable getting destroyed. Therefore the insert destroying behaviour is in fact *correct* as per the C++11 standard, and older compilers were *incorrect*.

You can probably see now why I took three days to diagnose this bug. It was not at all obvious in a large code base where the type being inserted into unordered_map was a typedef defined far away in source code terms, and it never occurred to anyone to check if the typedef was identical to value_type.

So my questions to Stack Overflow:

1. Why do older compilers not destroy variables inserted like newer compilers? I mean, even GCC 4.7 doesn&#39;t do this, and it&#39;s pretty standards conforming.

2. Is this problem widely known, because surely upgrading compilers will cause code which used to work to suddenly stop working?

3. Did the C++ standards committee intend this behaviour?

4. How would you suggest that unordered_map::insert() be modified to give better behaviour? I ask this because if there is support here, I intend to submit this behaviour as a N note to WG21 and ask them to implement a better behaviour.

Is it intended by the C++ standards committee that in C++11 unordered_map destroys what it inserts?

**C++11**
&gt; 14.8.2 - **Template Argument Deduction** - `[temp.deduct]`&lt;br /&gt;
&gt; &gt; &lt;sup&gt;7&lt;/sup&gt; The substitution occurs in all types and expressions that are used in the function type and in template parameter declarations. The expressions include not only constant expressions such as those that appear in array bounds or as nontype template arguments but also general expressions (ie. non-constant expressions) inside `sizeof`, `decltype`, and other contexts that allow non-constant expressions.

------

**C++14**
&gt; 14.8.2 - **Template Argument Deduction** - `[temp.deduct]`&lt;br /&gt;
&gt; &gt; &lt;sup&gt;7&lt;/sup&gt; The substitution occurs in all types and expressions that are used in the function type and in template parameter declarations. The expressions include not only constant expressions such as those that appear in array bounds or as nontype template arguments but also general expressions (ie. non-constant expressions) inside `sizeof`, `decltype`, and other contexts that allow non-constant expressions. **The substitution proceeds in lexical order and stops when a condition that causes deduction to fail is encountered**.

------

------

The added sentence explicitly states the order of substitution when dealing with template parameters in C++14.

The order of substitution is something that most often isn&#39;t given a lot of attention. I have yet to find a single paper on why this matters. Maybe this is because C++1y hasn&#39;t been fully standardized yet, but I&#39;m assuming such a change must have been introduced for a reason. 

**The question:**

 * Why, and when, does the order of template argument substitution matter?


Why does the order of template argument substitution matter?

Does `std::make_unique` have any efficiency benefits like `std::make_shared`?

Compared to manually constructing `std::unique_ptr`:

    std::make_unique&lt;int&gt;(1);         // vs
    std::unique_ptr&lt;int&gt;(new int(1));

Differences between std::make_unique and std::unique_ptr with new

According to the [cppreference.com][1] reference site on [std::shufle][2], the following method is being deprecated in c++14:

    template&lt; class RandomIt &gt;
    void random_shuffle( RandomIt first, RandomIt last );

Why will we no longer be able to call the following function without passing a third parameter?

    std::random_shuffle(v.begin(),v.end()); //no longer valid in c++14

It doesn&#39;t appear as though a different function deceleration has a default parameter set.  What is the reason behind this?  Was there some kind of alternative added?

  [1]: http://cppreference.com
  [2]: http://en.cppreference.com/w/cpp/algorithm/random_shuffle

Why are std::shuffle methods being deprecated in C++14?

As covered in [Does initialization entail lvalue-to-rvalue conversion? Is `int x = x;` UB?](https://stackoverflow.com/questions/14935722/does-initialization-entail-lvalue-to-rvalue-conversion-is-int-x-x-ub) the C++ standard has a surprising example in section `3.3.2` *Point of declaration* in which an `int` is initialized with it&#39;s own indeterminate value:

&gt;     int x = 12;
&gt;     { int x = x; }
&gt; 
&gt; Here the second x is initialized with its own (indeterminate) value.
&gt; — *end example* ]

Which Johannes answer to this question indicates is undefined behavior since it requires an lvalue-to-rvalue conversion.

In the latest C++14 draft standard `N3936` which can be found [here](https://github.com/cplusplus/draft/tree/b7b8ed08ba4c111ad03e13e8524a1b746cb74ec6/papers) this example has changed to:

&gt;     unsigned char x = 12;
&gt;     { unsigned char x = x; }
&gt; 
&gt; Here the second x is initialized with its own (indeterminate) value.
&gt; — *end example* ]

Has something changed in C++14 with respect to indeterminate values and undefined behavior that has driven this change in the example?

Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++14?

Traditionally, the standard and portable way to avoid multiple header inclusions in C++ was/is  to use the `#ifndef - #define - #endif`pre-compiler directives scheme also called [macro-guard scheme][1] (see code snippet below).

    #ifndef MY_HEADER_HPP
    #define MY_HEADER_HPP
    ...
    #endif

In most implementations/compilers (see picture below) however, there&#39;s a more &quot;elegant&quot; alternative that serves the same purpose as the macro-guard scheme called [`#pragma once`][2]. `#pragma once` has several advantages compared to the macro-guard scheme, including less code, avoidance of name clashes, and sometimes improved compile speed.

![enter image description here][4]

Doing some research, I realized that although `#pragma once` directive is supported by almost all known compilers, there&#39;s a turbidness on whether `#pragma once` directive is part of the C++11 standard or not.

**Questions:**
--------------

- Could someone clarify whether `#pragma once` directive is part of the C++11 standard or not?
- If it&#39;s not part of the C++11 standard, are there any plans on including it on later releases (e.g., C++14 or later)?
- It would also be nice if someone could further elaborate on the advantages/disadvantages in using either one of the techniques (i.e., macro-guard versus `#pragma once`).

  [1]: http://en.wikipedia.org/wiki/Include_guard
  [2]: http://en.wikipedia.org/wiki/Pragma_once
  [3]: http://en.wikipedia.org/wiki/Pragma_once
  [4]: http://i.stack.imgur.com/qDohP.png

Content Type	Original Author	Original Content on Stackoverflow
Question	template boy	View Question on Stackoverflow
Solution 1 - C++	Kerrek SB	View Answer on Stackoverflow
Solution 2 - C++	Yakk - Adam Nevraumont	View Answer on Stackoverflow

What is the difference between auto and decltype(auto) when returning from a function?

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Solution 2 - C++

Failed to build project with Android studio

How to change chrome packaged app id Or Why do we need key field in the manifest.json?

Attributions