On 2010-11-27, 20:22:02 -0600, Roman Kononov
wrote:
> Should this one emit the same error then? 4.6 compiles it.
>
> typedef int X;
> X test() {
>X const& a={};
>return std::move(a);
> }
Never mind. I've figured it out.
Thanks.
On 2010-11-27, 16:37:07 -0800, James Dennett
wrote:
> 4.6 appears to be right -- you cannot bind an X&& to a const X (which
> is good, as otherwise you could change the const X).
Should this one emit the same error then? 4.6 compiles it.
typedef int X;
X test() {
X const& a={};
return std:
On Sat, Nov 27, 2010 at 4:13 PM, Roman Kononov wrote:
> Hello,
>
> Is it a bug or am I missing something?
>
> $ cat test.cpp
> #include
>
> struct X {
> X()=default;
> X(X&&)=default;
> };
>
> X test() {
> X const a={};
> return std::move(a);
> }
>
> $ g++ -c -std=c++0x test.cpp
> test.cp
Hello,
Is it a bug or am I missing something?
$ cat test.cpp
#include
struct X {
X()=default;
X(X&&)=default;
};
X test() {
X const a={};
return std::move(a);
}
$ g++ -c -std=c++0x test.cpp
test.cpp: In function 'X test()':
test.cpp:10:22: error: no matching function for call
Snapshot gcc-4.6-20101127 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
>> the include order should generally start
>>
>> #include "config.h"
>> #include "system.h"
>> #include "coretypes.h"
I've run into similar problems trying to port Dehydra to 4.6 (it works with 4.5)
Here's the basic header structure which builds only because I'm
commenting out a bunch of headers
On Sat, 27 Nov 2010, Mingjie Xing wrote:
> The first error occurs due to that using diagnostic_context in the
> plugin.h without including diagnostic.h. The second error is about
diagnostic_context is declared in coretypes.h. All headers are expected
to depend on coretypes.h; the include order
On 26 November 2010 22:17, Jay K wrote:
>
> I somewhat tracked down the odd/dubious reason extern "C" is "good".
This behaviour of Apple's gdb is a poor reason to modify GCC sources.
It's probably just that gdb didn't use to be very good at matching C++
function names.
> ...
> (gdb) break F2
Wh
