[Bug c++/30962] New: cause compile error for "const anonymous class object"
First I cannot find the exact C++ definition of "const anonymous object" so I
am not sure the below reporting is valid or not. The question to me is: why
adding 'const' to the class declaration will invalidate the code while without
'const' is ok?
The following code will compile and run without error, but if add back the
"const" declaration before 'class', it will report an error of "
Error: uninitialized const `MyAnonymous'"
This had been tested with gcc 3.3.3 & 4.1.2.
/* const */ class
{
public:
int foo() const
{
return 1;
}
} MyAnonymous;
int
main()
{
return MyAnonymous.foo();
}
--
Summary: cause compile error for "const anonymous class object"
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30962] cause compile error for "const anonymous class object"
--- Comment #2 from gzljg at hotmail dot com 2007-02-26 22:55 ---
Not sure what you mean by "MyAnonymous = {};" to initialize it... if change to:
const class { /* */ } MyAnonymous = {};
will cause another error:
"MyAnonymous' must be initialized by constructor, not by '{...}'
--
gzljg at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30962] cause compile error for "const anonymous class object"
--- Comment #4 from gzljg at hotmail dot com 2007-02-26 23:14 ---
I would rather to blame on Suse 10(I happend to verify on that machine). It
doesn't work for a gcc 3.3.5(prerelease) version ===>
myweb:> g++ -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
myweb:> make
g++ -g -DDEBUG -Wall -c test.C -o test.o
test.C:17: error: `Anonymous' must be initialized by constructor, not by
`{...}'
make: *** [test.o] Error 1
Anyways, I rerun the test case with other compiler, such as gcc 3.3.3, 4.1.2,
both works fine now.
PS. I don't have a gcc 3.3.5 official release version to verify.
--
gzljg at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30962] cause compile error for "const anonymous class object"
--- Comment #5 from gzljg at hotmail dot com 2007-02-26 23:35 ---
Subject: RE: cause compile error for "const anonymous class object"
CORRECTION: "Suse 10" should be read as "Suse 9".
Can some one verify the official release of gcc 3.3.5?
>From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: [Bug c++/30962] cause compile error for "const anonymous class
object"
>Date: 26 Feb 2007 23:00:22 -
>
>--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 23:00
---
>(In reply to comment #2)
> > Not sure what you mean by "MyAnonymous = {};" to initialize it... if
change to:
>
>You example which you gave works for me with that:
> const class
>{
> public:
>int foo() const
>{
> return 1;
>}
>} MyAnonymous = {};
>
>int
>main()
>{
> return MyAnonymous.foo();
>}
>
>[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc
>[EMAIL PROTECTED]:~$ gcc t.cc
>
>Anyways this is not a GCC bug but rather you not knowing C++.
>
>
>--
>
>pinskia at gcc dot gnu dot org changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |RESOLVED
> Resolution||INVALID
>
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
>
>--- You are receiving this mail because: ---
>You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/30962] cause compile error for "const anonymous class object"
--- Comment #6 from gzljg at hotmail dot com 2007-02-27 01:57 ---
Subject: RE: cause compile error for "const anonymous class object"
Hi Pinskia,
I update the notes there, can you take a look?
Thanks.
Gavin
>From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: [Bug c++/30962] cause compile error for "const anonymous class
object"
>Date: 26 Feb 2007 23:00:22 -
>
>--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 23:00
---
>(In reply to comment #2)
> > Not sure what you mean by "MyAnonymous = {};" to initialize it... if
change to:
>
>You example which you gave works for me with that:
> const class
>{
> public:
>int foo() const
>{
> return 1;
>}
>} MyAnonymous = {};
>
>int
>main()
>{
> return MyAnonymous.foo();
>}
>
>[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc
>[EMAIL PROTECTED]:~$ gcc t.cc
>
>Anyways this is not a GCC bug but rather you not knowing C++.
>
>
>--
>
>pinskia at gcc dot gnu dot org changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |RESOLVED
> Resolution||INVALID
>
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
>
>--- You are receiving this mail because: ---
>You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
[Bug c++/33762] New: partial template specialization question
Probably this is not a bug, but just I want to make clear to myself...
I have a 'general' template class, and can specialize it for one class(say
base), can I then assume all other classes that derived from 'base' class are
using the specialized version template function(same as the base one)?
Example code:
#include
using namespace std;
class Dummy{};
class Base {} ;
class Derive : virtual public Base{};
template class Stub : virtual public T
{
public:
Stub()
{
std::cout << "template class Stub : virtual public T"
<< std::endl;
}
};
template <> class Stub
{
public:
Stub()
{
std::cout << "template <> class Stub "
<< std::endl;
}
};
/*
I have to enable this to make it work as expected, but this is definitely not I
wants, since this mean I had to specialize _all_ the dervied classes like this,
which may be too much
template <> class Stub
{
public:
Stub()
{
std::cout << "template <> class Stub "
<< std::endl;
}
};
*/
class A : public Stub
{
};
class B : public Stub
{
};
class C : public Stub
{
};
int main()
{
A a; // expected, use the most general template.
B b; // expected, use the specialized template since T=Base
C c; // ?? I expected it will use the specialized template as well, since
T=Derive, which Derive is derived from Base.Am I wrong here??
return 0;
}
program output:
template class Stub : virtual public T
template <> class Stub
template class Stub : virtual public T // I expected should be "
template <> class Stub" as above here.
--
Summary: partial template specialization question
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33762
[Bug libstdc++/49506] New: reusing a file stream object will always get eof after openning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506 Summary: reusing a file stream object will always get eof after openning Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gz...@hotmail.com Created attachment 24581 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24581 test programe to reproduce the file stream open-eof bug It seems that if I reuse a std::ifstream object by "open(another_file)" it will always return EOF right away. See the attached file for details. I had confirmed this can be reproduced with gcc 3.3.3 but NOT in gcc 4.3.3. (Not sure which exact version fixed the problem -- I had searched the similar bug description but could not find one ). In a good case, the test program should return 0 silently. In a bad case, the test program print out "eof" and some of the bits of the stream state and return 1;
[Bug c++/33885] New: member reference to a temporary object being deleted too eary
class A{
//
};
class B{
public:
explicit B(const A& a)
: i_a(a)
{
}
~B()
{
}
private:
const A& i_a;
};
A returnA( const char* arg )
{
return A(/*arg*/);
}
foo()
{
const A& aRef = returnA("FirstObject"); // . (1)
{
const B b(returnA("SecondObject"));// . (2)
///...
typedef int outofscope_block; // . (3)
}
typedef char outofscope_function;// . (4)
}
temporary object created and referenced by aRef is being deleted when aRef goes
out of scope in foo, as Expected.
temporary object created and referenced by B::i_a is being deleted right after
object b's construction, Not expected. It should(?) have the same life time as
the B::i_a(thus b), such as deleted _after_ line (3) --- If this assumpsion is
false, then what's the difference between a 'plain reference' and 'member
reference' herein??
BTW, it works as expected on SunCC compiler. It core dumps on gcc 3.3.3 while
having (empty/invalid) data for i_a on gcc 4.1.2 but not coring.
--
Summary: member reference to a temporary object being deleted too
eary
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33885
[Bug c++/33885] member reference to a temporary object being deleted too eary
--- Comment #1 from gzljg at hotmail dot com 2007-10-24 20:15 --- Created an attachment (id=14408) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14408&action=view) a compilable C source compile and run it to see the actual outcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33885
[Bug c++/33940] New: call of overloaded 'basic_string(const&)' is ambiguous for a template member function
#include
const
class {
public:
template operator T() const
{
return T(); // even I change this to "return std::string();", same error.
}
} MYNULLOBJECT = {};
int main()
{
const unsigned int myInt(MYNULLOBJECT);// OK, myInt is 0
const std::string myString(MYNULLOBJECT); // cannot compile
return myInt;
}
my compiler output >
>g++ --version
g++ (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>g++ -g -c test.C
test.C: In function 'int main()':
test.C:17: error: call of overloaded 'basic_string(const&)' is
ambiguous
/mnts/cdstools/gcc-4.1.2/linux-i386-2.3/include/c++/bits/basic_string.tcc:225:
note: candidates are: std::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char,
_Traits = std::char_traits, _Alloc = std::allocator]
/mnts/cdstools/gcc-4.1.2/linux-i386-2.3/include/c++/bits/basic_string.tcc:182:
note: std::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with
_CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]
/mnts/cdstools/gcc-4.1.2/linux-i386-2.3/include/c++/bits/basic_string.tcc:190:
note: std::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits =
std::char_traits, _Alloc = std::allocator]
make: *** [test.o] Error 1
Please note that, this test case passed on SunCC compiler.
--
Summary: call of overloaded 'basic_string(const&)' is ambiguous for a template member function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33940
[Bug c++/33940] call of overloaded 'basic_string(const&)' is ambiguous for a template member function
--- Comment #2 from gzljg at hotmail dot com 2007-10-29 17:00 --- (In reply to comment #1) > A couple of quick comments. First, there is nothing special about std::string, > the same happens with std::vector, for example, because really the issue > is about multiple constructors. Second, I checked that at least 2 other > compilers + library behave the same as GCC. In short, I don't think this issue > is valid, there is a real ambiguity in the user code. > Thanks for Paolo's input. I understand it's nothing to do with std::string, just because my test case use std::string that causes the error. What I was confused is why the compiler is ambiguious about the T()'s constructor, _even_ I hard coded to use "std::string()" in the example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33940
[Bug c++/33940] call of overloaded 'basic_string(const&)' is ambiguous for a template member function
--- Comment #5 from gzljg at hotmail dot com 2007-10-29 17:56 ---
(In reply to comment #4)
> In practice, consider this:
>
> const
> class {
> public:
> template operator T() const
> {
> return int();
> }
>
> } MYNULLOBJECT = {};
>
> void f(int);
> void f(unsigned);
>
> int main()
> {
> f(MYNULLOBJECT);
> }
>
> No conforming compiler accepts it.
>
In this test case, "int" and "unsigned" are different class(thus causes
ambiguity in my view), while in the original test case, only ONE class
"std::string" involved---even with different type of constructors. Is it
sufficient for the compiler to pick up one from all its definitions? Such as ,
when we say "std::string s();" it knows which constructor it expects?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33940
[Bug c++/30390] New: cannot declare friend class of the parameter type in a template class
class R{};
class B{
friend class R;// ok.
};
template class A{
friend class T; // error???
};
when using g++(3.3.3 or 4.1) to compile above code, it reports:
error: using template type parameter 'T' after 'class'
error: friend declaration does not name a class or function
Pls note that, SunCC works fine for above code.
--
Summary: cannot declare friend class of the parameter type in a
template class
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30390
