Wrong Constructor Called

[Joe]

I have a situation where the wrong constructor is being called. I
have defined 2 constructors with different parameter types that are
defined as follows...

class __declspec(dllexport)CColumn : public CColumnBase
{
public:

CColumn(CString columnType,CObject *aOwner, CString anId);
CColumn(CString columnType,CObject *aOwner, bool batchUpdated);
....
}

The implementation of these functions looks like this...

CColumn::CColumn(CString columnType, CObject *aOwner, CString anId)
{
setColumnType(columnType);
setOwner(aOwner);
setId(anId);
setLength(10);
setPrecision(5);
setField();
setBatchUpdated(false);
}

CColumn::CColumn(CString columnType, CObject *aOwner, bool
batchUpdated)
{
setColumnType(columnType);
setOwner(aOwner);
setId("");
setLength(10);
setPrecision(5);
setField();
setBatchUpdated(batchUpdated);
}

When the line below in the CDual() constructor gets called, the
constructor with the signature of CColumn::CColumn(CString columnType,
CObject *aOwner, bool batchUpdated) gets invoked, rather than the one
I want.


//////////////////////////////////////////////////////////////////////
// Construction/Destruction
//////////////////////////////////////////////////////////////////////
IMPLEMENT_DYNCREATE( CDual, CDomain )

CDual::CDual()
{
...
addColumn(new CColumn(TIMESTAMP_COLUMN,this,"TIMESTAMP"));
...
}

Does anyone have any idea why this is happening and how to avoid this
issue?

Thanks,

Joe

 

[Ron Natalie]

When the line below in the CDual() constructor gets called, the
constructor with the signature of CColumn::CColumn(CString columnType,
CObject *aOwner, bool batchUpdated) gets invoked, rather than the one
I want.

Because the bool is a better match for char* than CString is. Any pointer
can be converted to bool, and that is a standard conversion sequence.
I assume CString has a converting constructor that takes a char*. This
is a user-defined conversion sequence. The standard conversion sequence
wins out.

You'll either have to make your overloads less ambiguous, or explicitly do
something to the call to make it not match bool (like converting it to CString yourself).
new CColumn(TIMESTAMP_COLUMN, this, CString("TIMESTAMP"));

 

[Karl Heinz Buchegger]

CDual::CDual()
{
...
addColumn(new CColumn(TIMESTAMP_COLUMN,this,"TIMESTAMP"));
...
}

Does anyone have any idea why this is happening

I am not sure if this is a compiler bug or not.
But obviously the compiler prevers the conversion
from a character pointer to a bool over the construction
of a temporary object.

and how to avoid this
issue?

Simple. Force the compiler to do it:

{
...
addColumn(new CColumn(TIMESTAMP_COLUMN,this,CString( "TIMESTAMP" )));
...
}

another workaround would be to introduce a third constructor which
takes a const char*

 

[Kevin Saff]

I have a situation where the wrong constructor is being called. I
have defined 2 constructors with different parameter types that are
defined as follows...

class __declspec(dllexport)CColumn : public CColumnBase
{
public:

CColumn(CString columnType,CObject *aOwner, CString anId);
CColumn(CString columnType,CObject *aOwner, bool batchUpdated);
...
}
[SNIP implementation details]

CDual::CDual()
{
...
addColumn(new CColumn(TIMESTAMP_COLUMN,this,"TIMESTAMP"));
...
}

Does anyone have any idea why this is happening and how to avoid this
issue?

Thanks,

Joe

It's because you aren't calling the constructor with a (CString) - you are
calling it with "TIMESTAMP" which is a (char const*). There is a
language-defined conversion from a pointer to a bool (non-NULL -> true,
NULL -> false), which beats out the user-defined conversion from (char
const*) to (CString). I don't remember the exact language rule here, but
it's come up in my code before. You have several options:

1) Instead call CColumn (TIMESTAMP_COLUMN, this, CString ("TIMESTAMP"));
2) Create a new constructor CColumn (CString columnType,CObject *aOwner,
char const *anId);
3) Change the argument orders, or add an argument to a constructor.
4) Use the named constructor idiom. (static CColumn *createById (...);
static CColumn *createBatch (...).
5) Passing a bool to a constructor is often a hint to break the class into
two, using polymorphism.

What you do depends on several factors, including what code is yours. I
don't recall if CColumn is an MFC class or not.

HTH

 

[jeffc]

Because the bool is a better match for char* than CString is. Any pointer
can be converted to bool, and that is a standard conversion sequence.
I assume CString has a converting constructor that takes a char*. This
is a user-defined conversion sequence. The standard conversion sequence
wins out.

Is this true for the language as part of the standard, or is it compiler
dependent and you're inferring that's his implementation?

 

[Ron Natalie]

I am not sure if this is a compiler bug or not.
But obviously the compiler prevers the conversion
from a character pointer to a bool over the construction
of a temporary object.

It's not a bug. The conversion of a pointer to bool is a standard
conversion sequence. The conversion to CString is a user-defined
conversion. A standard conversion sequence is preferred over a
user-defined conversion. That's the language.

 

[Ron Natalie]

Is this true for the language as part of the standard, or is it compiler
dependent and you're inferring that's his implementation?

It's the way the C++ language works. There's nothing wrong
with his compiler in this regard.

 

[Chris Theis]

I have a situation where the wrong constructor is being called. I
have defined 2 constructors with different parameter types that are
defined as follows...
[SNIP]
Does anyone have any idea why this is happening and how to avoid this
issue?

This is a problem of the conversion sequence. The standard states that the
order of conversions are 1. standard-conversion, 2. user defined
conversions, 3. elipsis conversions. The conversion to bool is a valid
standard conversion for any pointer as it is indicated in section 4.12 of
the standard. CString has a ctor enable implicit user conversions for string
literals. However, the standard conversion to bool wins due to the ordering.
What you have to do is to disamiguate the ctor call by supplying a CString
object as the 3rd parameter or provide another ctor which can take a const
char*.

Regards
Chris

 

[Chris Theis]

Is this true for the language as part of the standard, or is it compiler
dependent and you're inferring that's his implementation?

It's defined by the standard in section 13.3.3.1 (ISO:IEC 14882:1998(E))

Chris

 

[Karl Heinz Buchegger]

It's not a bug. The conversion of a pointer to bool is a standard
conversion sequence. The conversion to CString is a user-defined
conversion. A standard conversion sequence is preferred over a
user-defined conversion. That's the language.

Thank's for clearification.

 

[jeffc]

It's the way the C++ language works. There's nothing wrong
with his compiler in this regard.

Whaddya know. Personally I don't think that conversion should be there - it
seems meaningless for a literal string.

 

[Ron Natalie]

Whaddya know. Personally I don't think that conversion should be there - it
seems meaningless for a literal string.

What conversion are you talking about? First off, it's pure conjecture what CString
does because it's not a standard type. I'm just assuming it has a constructor of the
form CString(const char*). Second, string literals don't make a string. They make
a character array. It's braindamage carried over from C. char* sucks as a string
type.

 

[Howard]

Whaddya know. Personally I don't think that conversion should be there - it
seems meaningless for a literal string.

It's because a string literal is treated as a const char array, and a
pointer to that array is created and used. The conversion is then really
from a char* to a bool, which makes a great deal of sense, since it is
common to check for a non-null pointer by writing something like

if (pointer_to_something){......}


-Howard

 

[Ron Natalie]

It's because a string literal is treated as a const char array,

That's because it IS a const char array.

 

[jeffc]

What conversion are you talking about? First off, it's pure conjecture what CString
does because it's not a standard type. I'm just assuming it has a constructor of the
form CString(const char*). Second, string literals don't make a string. They make
a character array. It's braindamage carried over from C. char* sucks as a string
type.

You're quite correct, but I was talking about a string literal to bool.
It's a silly conversion, virtually certain to be a mistake.

 

[jeffc]

there -
it
It's because a string literal is treated as a const char array, and a
pointer to that array is created and used. The conversion is then really
from a char* to a bool, which makes a great deal of sense, since it is
common to check for a non-null pointer by writing something like

if (pointer_to_something){......}

Yeah, I understand your point. It just seems to me that when a compiler can
distinguish between a literal and a pointer, it should. To put it another
way, I don't see why a string literal has to blindly be treated like a
pointer in all cases. Keep in mind that bools aren't implied in your
example. For example,
if ("asdf")
is one thing, because it doesn't imply conversion to bool. Forcing
conversion to bool specifically is another thing.

 

[Ron Natalie]

Yeah, I understand your point. It just seems to me that when a compiler can
distinguish between a literal and a pointer, it should. To put it another
way, I don't see why a string literal has to blindly be treated like a
pointer in all cases.

Well the real culprit is the array-to-pointer translation. Frankly, I think that
was a mistake. If people wanted a pointer to the first element, they should
be forced to do something like &x[0]. That and arrays should work like
all the other data types:
int x[3] = { 0, 1, 2};
int y[3];

y = x;
etc...

 

[jeffc]

Yeah, I understand your point. It just seems to me that when a compiler can
distinguish between a literal and a pointer, it should. To put it another
way, I don't see why a string literal has to blindly be treated like a
pointer in all cases.

Well the real culprit is the array-to-pointer translation. Frankly, I think that
was a mistake. If people wanted a pointer to the first element, they should
be forced to do something like &x[0].

I also don't see any problem with that.