NULL promoted to class

[jimdempseyatthecove]

I was performing a major re-write of some code and ran into one of those situations where looking at the code did not did not convey anything was wrong with it.

The former code had a class that contained pointers to some objects, and the ctor of that class nulled out the pointers.

fee = NULL;
fi = NULL;
fo = NULL;

Where NULL is promoted to pointer of any type.

In the rewrite of the code the pointers were replaced with the class objects using same names in the code.
However, a programming error on my part, I left the former pointer NULL-ing code in the ctor.

The compiler did not produce an error, I do not know if it should or should not, but the result was:

The compiler promoted the NULL to the class object,
peformed a default copy operator,
then destroyed the NULL class object.

Is this a feature or bug???

Jim Dempsey

[SergeyKostrov]

Quoting Jennifer Jiang (Intel)

1. "NULL" is a valid value for any pointer variable (as an init value).

[SergeyK] Correct. But in Jim's case this is not a problem.

2. compiler created a tempoary object with "NULL" based on ctor A(B*p, C*p2=NULL) ---- the 2nd parameter is optional.

[SergeyK] Did you debug the Jim's Test-Case? Or, you're simply assuming? '...temporary object...' of what type? It must be of some type if it really creates it!

3. compiler uses the "default assignment operator" generated by the compiler itself to assign the temp object to variable "input" when there is no assignment operator overloading.

[SergeyK] Two default C++ operators '=' are generated by an MSC/C++ compiler, for 'parallel_manifold_SPSC_FIFO' and 'parallel_manifold_base' classes.

4. in my testcase the overloading assignement operator is "B& operator (B& in)", but it should be "B& operator (B const & in)" instead. if changing to the later one, the compiler will not issue the error.

[jimdempseyatthecove]

Untested abstract sketch

struct foo
{
char junk[1234];
foo() { junk[0] = 0; }
foo(char* x, char* y = NULL) { strncpy(junk, x, 1233); if(y) strncat(junk, y, 1233);}
};

no operator=()

foo A;
foo B;
foo C("test data"); //OK
foo D("test", " data"); // OK

A = B; // uses compiler generated operator=() OK
A = C; // same (with test data)
// I have no intention of doing any of the following
// the = NULL on next line was in the code when pointer was in use
A = NULL; // ought to report error
// this errors out, no suitable conversion operator
A = 12345;
// this does not error out
A = "abc"; // ought to report error
// the above behaved as if the following were issued
A = foo("abc");

Maybe I need to go back to programming school...
What this means is a strong type checked language (C++) is performing loosly type checked operations not intended. i.e. if I want the A="abc"; I would be required to supply the conversion operator. but apparently this is not the case.

Is there a way to force the compiler to generate an error as opposed to implicit ctoring a "faulty" statement?

Jim

[Judith_W_Intel · Accepted solution]

If you declare a constructor "explicit" it can only be used for construction of an object, not for conversions.

Explanation here:

http://www.glenmccl.com/tip_023.htm

Is that what you want?

Judy

[jimdempseyatthecove]

Yes Judy, that is exactly what I want.

IMVHO, I would rather that required "implicit A(int)" to enable the auto conversion operator, as opposed to "explicit A(int)" to disable it. But this is the way it is....

Thanks for the tip.

Jim Dempsey