 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
nutty
Guest
|
 Posted: Mon Jun 12, 2006 2:13 am Post subject: Just another difference between compilers. |
 |
|
Hi,
In my code I use two implicit casts in a row. VC compiled it in all
version I have. 7.1 and 8.0, but it seems not to be standard. Comeau in
strict mode and gcc don't accept it.
Of course, I can just throw a cast in C c = (C)b;
but this is not what I want. I want to enable implicit conversion.
Any idea?
Ingo
// main.cpp:
class A{};
class B
{
public:
operator A( )
{
return a;
}
A a;
};
class C
{
public:
C( A const& a ) { }
};
int main()
{
B b;
C c = b;
} |
|
| Back to top |
|
 |
Axter
Guest
|
| Posted: Mon Jun 12, 2006 4:36 am Post subject: Re: Just another difference between compilers. |
|
|
nutty wrote:
| Quote: | Hi,
In my code I use two implicit casts in a row. VC compiled it in all
version I have. 7.1 and 8.0, but it seems not to be standard. Comeau in
strict mode and gcc don't accept it.
Of course, I can just throw a cast in C c = (C)b;
but this is not what I want. I want to enable implicit conversion.
Any idea?
Ingo
// main.cpp:
class A{};
class B
{
public:
operator A( )
{
return a;
}
A a;
};
class C
{
public:
C( A const& a ) { }
};
int main()
{
B b;
C c = b;
}
|
Very strange.
On my GNU compiler, it compiles if you use the following sysntax:
int main()
{
B b;
C c(b);
But technically, both syntax should evaluate to the same thing.
C c(b);
C c = b;
The compiler should fail with both, or accept both. |
|
| Back to top |
|
|
Alf P. Steinbach
Guest
|
| Posted: Mon Jun 12, 2006 4:53 am Post subject: Re: Just another difference between compilers. |
|
|
* Axter:
| Quote: | C c(b);
C c = b;
The compiler should fail with both, or accept both.
|
The declaration
C c(b);
is a "direct initialization" and involves one user-defined conversion
before c is reached: from B to A (the C constructor argument type).
C c = b;
is a "copy initialization" and involves two user-defined conversions
before c is reached: from B to A, and from A to C, because the right
side is a C object that c is copy-constructed from (although that copy
construction can and usually will be optimized away, it's there).
The standard allows only one implicit user-defined conversion, so that
the compiler won't outsmart the programmer (at least not a genius one).
You have the same situation with std::auto_ptr.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? |
|
| Back to top |
|
|
nutty
Guest
|
| Posted: Mon Jun 12, 2006 9:10 am Post subject: Re: Just another difference between compilers. |
|
|
| Quote: | The standard allows only one implicit user-defined conversion, so that
the compiler won't outsmart the programmer (at least not a genius one).
You have the same situation with std::auto_ptr.
|
And in my real code it is actually a situation similar to auto_ptr,
where I use a reference counting pointer class. The pointer class
should be assigned the internal value of a proxy object, which is a raw
pointer.
So, next question: How do people resolve the issue with the auto ptr? I
mean, almost any issues that can be thought of, have been solved at
some time by somebody, right?  |
|
| Back to top |
|
|
nutty
Guest
|
| Posted: Mon Jun 12, 2006 9:10 am Post subject: Re: Just another difference between compilers. |
|
|
| Quote: | Very strange.
On my GNU compiler, it compiles if you use the following sysntax:
int main()
{
B b;
C c(b);
But technically, both syntax should evaluate to the same thing.
C c(b);
C c = b;
The compiler should fail with both, or accept both.
|
by technicaly, you mean the generated instructions.
Of course, in this case I could write it like this. But then I have
peaces of code, where an assignment is affected, or an argument to a
function:
void func( C c );
func( b );
and
C c;
c = b;
in these cases I should either write
func( (C)b );
or
func( C(b) );
and
c = (C)c;
or
c = C( b );
That would surely work, but is actually an explicit cast.
The reason for my concern is, that I don't want to think and care that
there are casts involved. Also casts are even more powerful and may do
things that I don't want in some situations. They may invoke a
cunstructer which is declared explicit, where for some reason a
function returns the exact type that matches the cunstructor parameter. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
