The two programs below differ by the location of =default applied to
the move constructor. In the first program, it is defaulted inside
the class during declaration. In the second program, it is defaulted
outside the class in the definition.
The first program does not compile. The second does comp
2010-11-30 21:20 CST, Jonathan Wakely said:
>We do. The point is your question is off-topic on this list, because
>you are complaining about the C++0x language, which as far as we know
>GCC implements correctly. If you don't like the language, complain
>somewhere else.
>
Then please tell me whic
2010-11-30 15:13 CST, Gabriel Dos Reis
said:
>On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov wrote:
>> I exactly want to be unable to change an object during its lifetime
>> except when it is moved-and-destroyed.
>
>isn't that a question for C++ forums?
I hoped you knew the answer. :)
2010-11-30 13:03 CST, James Dennett said:
>
>If you want to be able to change an object during its lifetime, don't
>make it const.
I exactly want to be unable to change an object during its lifetime
except when it is moved-and-destroyed.
Thanks
2010-11-30 20:46 CST, Jonathan Wakely said:
>On 30 November 2010 20:40, Jonathan Wakely wrote:
>>> $ cat test1.cc
>>> struct X {
>>> X()=default;
>>> X(X&&)=default;
>>> X(X const&)=delete;
>>> //some very large or non-copyable content
>>> };
>>>
>>> X test() {
>>> X const x={};
>>> {
>>>
2010-11-30 20:40 CST, Jonathan Wakely said:
>On 30 November 2010 20:33, Roman Kononov wrote:
>> $ cat test1.cc
>> struct X {
>> X()=default;
>> X(X&&)=default;
>> X(X const&)=delete;
>> //some very large or non-copyable content
>> };
This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
I write about it again because the following seems too bad:
$ cat test1.cc
struct X {
X()=default;
X(X&&)=default;
X(X const&)=delete;
//some very large or non-copyable content
};
X test() {
X const x={};
{
//a l
On 2010-11-29, 22:26:31 -0800, Andrew Pinski wrote:
>
> Except it is documented as a Deprecated feature already so it is
> different from a documented extension. I would say we should just
> drop it as it is documented already as deprecated.
Are you going to drop the feature from g++98?
It is
2010-11-29 13:25 CST, Andrew Pinski wrote:
>well this code is not valid C++03 code to begin with.
I agree. I mean "existing gnu++" if you will.
$ cat test.cc
struct X { static float const v=1; };
$ g++ -c -std=gnu++0x test.cc
test.cc:1:33: error: 'constexpr' needed for in-class initialization of
static data member 'v' of non-integral type
This will break a great deal of existing c++ code preventing easy
transition to c++0x. Maybe, the
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:
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
On 2010-04-02, 20:50 CDT, Richard Guenther said:
>The patch is about debuginfo. Can you file a bugzilla and attach
>preprocessed source for the testcase?
$g++ -E -std=c++0x -I../ check.cpp | sed -r '/^( *|\#.*)$/d' | wc -l
24526
The preprocessed source has 24526 non-blank lines. Should I attach
Hi,
r157834 of the trunk made compilation time almost 8(eight!) times
longer. The time went from 38 to 291 seconds.
$ svnversion ~/src/gcc
157833
$ make -C ~/src/gcc install
...
$ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \
-Wno-parentheses -I../ check.cpp -o check -MMD -lrt
3
On Mon, 29 Mar 2010 12:55:47 -0400 Jack Howarth
wrote:
>I've not seen any discussion of testing gcc trunk
> against the newer gmp 5.0 or 5.0.1 releases. Has anyone
> done significant testing with the newer gmp releases
> ... ?
I use gcc 4.4.4 and 4.5.0 with gmp 5.0.1. I compile and use Postg
Hi,
Typeinfo for __float128 is undefined. Is it a bug?
Thanks.
$ cat test.cpp
#include
#include
int main() {
return strlen(typeid(__float128).name());
}
$ g++ test.cpp
/tmp/ccw01pnm.o: In function `main':
test.cpp:(.text+0x5): undefined reference to `typeinfo for __float128'
collect2: ld re
Hi,
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/rk/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/rk/gcc --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100112 (e
#g++ --version | head -1
g++ (GCC) 4.4.3 20091228 (prerelease)
#cat test.cc
typedef _Decimal32 my_type;
#gcc -c test.cc
#g++ -c test.cc
test.cc:1: error: '_Decimal32' does not name a type
G++ is unfamiliar with the _DecimalXX types. Is it a "feature", bug or lack
of development?
#cat test.cc
t
On 09/15/2006 04:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Consider:
#include
template T foo(T a) { return a; }
template T bar(T a) { return a; }
int
main() {
assert((int (*
20 matches
Mail list logo
