[Bug c++/42470] New: Conversion Constructor not accepted/recognized

2009-12-22 Thread Curatica at gmail dot com
The C++ code:

#include 
using namespace std;
class Base
{
int i;

public:

Base(): i( -1 ) { cout << "Base()" << endl; }
Base( int a ) : i( a ) { cout << "Base(int), i: " << i << endl; }
Base( Base& b ) { i = b.i; cout << "Base(Base&), i: " << i << endl; }
Base& operator = ( Base& b )
{
i = b.i;
cout << "Base::operator =(), i: " << i << endl;
return *this;
}
virtual ~Base(){}
operator int() { cout << "Base::operator int()" << endl; return i; }
};
void test1()
{
cout << endl << "Example 1" << endl;
Base b1;
cout << "b1: " << b1 << endl;

cout << endl << "Example 2" << endl;
Base b2 = 5;
cout << "b2: " << b2 << endl;

cout << endl << "Example 3" << endl;
Base b3(6);
cout << "b2: " << b3 << endl;

cout << endl << "Example 4" << endl;
Base b4 = b1;
cout << "b4: " << b4 << endl;

cout << endl << "Example 5" << endl;
Base b5; b5 = b2;
cout << "b5: " << b5 << endl;
}
int main( int argc, char** argv )
{
test1();
}
/

The compile command:

g++ construction.cc -o construction

Compilation errors:

construction.cc: In function 'void test1()':
construction.cc:28: error: no matching function for call to 'Base::Base(Base),
construction.cc:11: note: candidates are: Base::Base(Base&)
construction.cc:10: note: Base::Base(int)
construction.cc:28: error:   initializing temporary from result of
'Base::Base(int)'

We believe that         

  Base b2 = 5;

should call Base::Base( int ). The same code compiles and executes fine under
Microsoft Visual Studio.


-- 
   Summary: Conversion Constructor not accepted/recognized
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Curatica at gmail dot com
 GCC build triplet: What is this?
  GCC host triplet: Not sure what this means; here is the result of uname -
a: Linux
GCC target triplet: What is this?


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470



[Bug c++/42471] New: No return value from operator =() is accepted by the compiler

2009-12-22 Thread Curatica at gmail dot com
The following C++ code compiles and executes correctly:

#include 
using namespace std;
class Base
{
int i;

public:

Base(): i( -1 ) { cout << "Base()" << endl; }
Base( int a ) : i( a ) { cout << "Base(int), i: " << i << endl; }
Base( Base& b ) { i = b.i; cout << "Base(Base&), i: " << i << endl; }
Base& operator = ( Base& b )
{
i = b.i;
cout << "Base::operator =(), i: " << i << endl;
//  return *this;
}
virtual ~Base(){}
operator int() { cout << "Base::operator int()" << endl; return i; }
};
void test1()
{
cout << endl << "Example 1" << endl;
Base b1;
cout << "b1: " << b1 << endl;

cout << endl << "Example 2" << endl;
Base b2 = Base( 5 );
cout << "b2: " << b2 << endl;

cout << endl << "Example 3" << endl;
Base b3(6);
cout << "b2: " << b3 << endl;

cout << endl << "Example 4" << endl;
Base b4 = b1;
cout << "b4: " << b4 << endl;

cout << endl << "Example 5" << endl;
Base b5; b5 = b2;
cout << "b5: " << b5 << endl;
}
int main( int argc, char** argv )
{
test1();
}
/

But the operator =() does not return a value! This error is caught by MS Visual
Studio.


-- 
   Summary: No return value from operator =() is accepted by the
compiler
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Curatica at gmail dot com
 GCC build triplet: What is this?
  GCC host triplet: Linux lambrusco 2.6.16.13-4-smp #1 SMP Wed May 3
04:53:23 UTC 20
GCC target triplet: What is this?


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42471



[Bug c++/42471] No return value from operator =() is accepted by the compiler

2009-12-24 Thread Curatica at gmail dot com


--- Comment #2 from Curatica at gmail dot com  2009-12-25 00:08 ---
Thanks (not sure what 4.1.0 referred to)...


-- 

Curatica at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42471



[Bug c++/42470] Conversion Constructor not accepted/recognized

2009-12-24 Thread Curatica at gmail dot com


--- Comment #2 from Curatica at gmail dot com  2009-12-25 02:04 ---
Please, understand that for me this is just a disinterested, academic
discussion: no offense. I am not sure that I agree with the theory.

The standard (8.5.1) states that:

T x = a;

is a "copy-initialization" but does not infer that this has anything to do with
the copy constructor. If I "fix" the source by adding "const" to the copy c-tor
argument:

Base( const Base& b ) { /*...*/ }

the code compiles indeed but there is no evidence whatsoever that the copy
c-tor is being invoked when the code 

Base b2 = 5;

is executed (as one could see, the copy c-tor prints a specific text to stdout,
which does not appear in this case). Furthermore, if I take out the copy c-tor
altogether, the code compiles and executes correctly. In either case, it seems
clear to me that 

Base( int a ) { /*...*/ }

is invoked. This is in accordance to "12.3.1 Conversion by constructor" in the
standard [class.conv.ctor].

My guess is that different people interpreted the standard differently: the
machine code is generated correctly in all cases but the compilation error
which depends on the "constatness" or lack thereof of the copy c-tor argument
is bogus.


-- 

Curatica at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470



[Bug c++/42470] Conversion Constructor not accepted/recognized

2009-12-25 Thread Curatica at gmail dot com


--- Comment #4 from Curatica at gmail dot com  2009-12-25 21:11 ---
Whatever...


-- 

Curatica at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470



[Bug c++/42470] Conversion Constructor not accepted/recognized

2009-12-25 Thread Curatica at gmail dot com


--- Comment #5 from Curatica at gmail dot com  2009-12-25 21:12 ---
Whatever...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470