title: terminate called after throwing an instance of 'std::bad_alloc'
body: <p>This is my setup (boiled down). I have a "layout function":</p>
  
  <pre><code>  struct LayoutFunc {
      LayoutFunc( int limit , int value ) { lim.push_back(limit); val.push_back(value); }
      //LayoutFunc(LayoutFunc&amp;&amp; func) : lim(func.lim),val(func.val) {}
      LayoutFunc(const LayoutFunc&amp; func) : lim(func.lim),val(func.val) {} // error: std::bad_alloc
      LayoutFunc(const std::vector&lt;int&gt;&amp; lim_, 
                 const std::vector&lt;int&gt;&amp; val_ ) : lim(lim_),val(val_) {}
      LayoutFunc curry( int limit , int value ) const {
        std::vector&lt;int&gt; rlim(lim);
        std::vector&lt;int&gt; rval(val);
        rlim.push_back(limit);
        rval.push_back(value);
        LayoutFunc ret(rlim,rval);
        return ret;
      };
      std::vector&lt;int&gt; lim;
      std::vector&lt;int&gt; val;
    };
  </code></pre>
  
  <p>Then I have a class that uses <code>LayoutFunc</code>:</p>
  
  <pre><code>template&lt;class T&gt; class A
  {
  public:
    A( const LayoutFunc&amp; lf_ ) : lf(lf_), member( lf.curry(1,0) ) {}
    A(const A&amp; a): lf(lf), member(a.function) {}  // corresponds to line 183 in real code
  private:
    LayoutFunc lf;
    T member;
  };
  </code></pre>
  
  <p>The order of data members is correct. There are more types like <code>class A</code> which use slightly different numbers to "curry" the layout function. I don't print them here to save space (they have the same structure, only different numbers). At the end I use something like:</p>
  
  <pre><code>A&lt; B&lt; C&lt;int&gt; &gt; &gt; a( LayoutFunc(1,0) );
  </code></pre>
  
  <p>which would build the "curried" layout function according to the template type order.</p>
  
  <p>Now, probably this simple (boiled down) example works. However, in my real application at runtime I get a <code>terminate called after throwing an instance of 'std::bad_alloc'</code> in the copy constructor of <code>LayoutFunc</code>.</p>
  
  <p>I think there is a flaw in the setup that has to do with taking a reference to a temporary and this temporary is destroyed before the consumer (in this case the copy constructor of <code>LayoutFunc</code>) uses it. This would explain <code>lim(func.lim),val(func.val)</code> to fail. But I can't see where the flaw is especially because <code>curry</code> returns a true <code>lvalue</code>. Also I tried it with the move constructor and compiled in c++11 mode. Same behaviour.</p>
  
  <p>Here the backtrace:</p>
  
  <pre><code>#0  0x00007ffff6437445 in __GI_raise (sig=&lt;optimised out&gt;) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
  #1  0x00007ffff643abab in __GI_abort () at abort.c:91
  #2  0x00007ffff6caa69d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #3  0x00007ffff6ca8846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #4  0x00007ffff6ca8873 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #5  0x00007ffff6ca896e in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #6  0x00007ffff6c556a2 in std::__throw_bad_alloc() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  #7  0x00000000004089f6 in allocate (__n=18446744073709551592, this=0x7fffffffdaf8) at /usr/include/c++/4.6/ext/new_allocator.h:90
  #8  _M_allocate (__n=18446744073709551592, this=0x7fffffffdaf8) at /usr/include/c++/4.6/bits/stl_vector.h:150
  #9  _Vector_base (__a=..., __n=18446744073709551592, this=0x7fffffffdaf8) at /usr/include/c++/4.6/bits/stl_vector.h:123
  #10 vector (__x=..., this=0x7fffffffdaf8) at /usr/include/c++/4.6/bits/stl_vector.h:279
  #11 LayoutFunc (func=..., this=0x7fffffffdae0) at layoutfunc.h:17
  #12 A (a=..., this=0x7fffffffdad0) at A.h:183
  </code></pre>
  
  <p>A.h:183 is the copy constructor of <code>A</code>:</p>
  
  <pre><code>  A(const A&amp; a): lf(lf), member(a.function) {}
  </code></pre>