My bug or C++ bug

[Emilio Garavaglia]

Consider several classes like this:

class Class
{
public:
Class& operator&=(const Class& c)
{ /* some stuff */ return *this; }
};

Now consider this template:

template<class A, class B>
A operator&(const A& a, const B& b)
{ return A(a)&=b; }

for any Class-like, now we have & available. Now, consider a fragment like this

{
....
int i, flag;
....
if(i & flag)
... some action
... other actions
}

Althought not intentional (I didn't wrote that template for that), the compiler use the templetized & operator. It should not be a problem, but ... for some reasons i becomes NULL because of the templatized operator& execution even if passed as const& (suppose i and flags have no bits in common). Am I wrong in something or ... it's one of the C7.0 misteries ? 2 bugs found. > recompile ... 65534 bugs found. :doh:

[Antony M Kancidrowski]

emilio_grv wrote: return A(a)&=b; Did you mean this? return A(a & b); You are modifying a by using &= Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)

[Emilio Garavaglia]

Antony M Kancidrowski wrote: Did you mean this? return A(a & b); No, I meant "create a copy of "a" (through A(a)) and call the &= operator on that copy, that modifies the copy retuning a reference to the copy itself, that is copyed as a return value. It works perfectly when A is a class having an &= operator defined, but if used with a primitive type, it seems it doesn't generate the copies, modifying the passed "value", even if it is a const& 2 bugs found. > recompile ... 65534 bugs found. :doh:

[John R Shaw]

emilio_grv wrote: My bug or C++ bug Neither: I think it is a compiler optimization/inlining bug. There is a recurring pattern that is used in most books on the subject and what you are seeing might be why. I would try the following:

template<class A, class B>
A operator&(const A& a, const B& b)
{ A tmp(a); return( tmp&=b ); }

OR

template<class A, class B>
A operator&(const A& a, const B& b)
{ A tmp(a); tmp&=b; return tmp; }

Hopefully one or both of these will solve the problem, since they provide more than enough information for the compiler to get it right. INTP "The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes." Andrew W. Troelsen

[Emilio Garavaglia]

I got your point: By splitting the compound instruction you try (and -in fact - it works) to force the compiler to don't optimize. But I'm still surprised 'bout the following:

• The compilet was told to "disable optimizations", but was still "optimizing" :omg:
• the optimization side effects were out of the optimization scope, treating in fact, a constant as a variable.

I didn't test if(2 & flag): whould it turn number 2 into 0 and add 0 to every subsecuent x+2? Terrificant! 2 bugs found. > recompile ... 65534 bugs found. :doh:

[John R Shaw]

Well the compiler will still do some optimising. The real problem probably lays in how it is inlining the code. I do not have the 7.0 compiler, but it would be interesting to see if it would choke on (2 & flag) with your code. I suspect that it would see that and produce the correct inline code instead of what ever it was producing. The only real way to see what it is doing is to look at the asymbly code, before and after modifying the code. :laugh:No I do not believe it would turn 2 to 0, every place that 2 is in your code is unique to that piece of code, so subsequent statements where 2 is applied is unique. 2 is a true constant where the variable i was a temporay constant with a specific address location. INTP "The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes." Andrew W. Troelsen