tags:

views:

569

answers:

7

I know you can use C++ keyword 'explicit' for constructors of classes to prevent an automatic conversion of type. Can you use this same command to prevent the conversion of parameters for a class method?

I have two class members, one which takes a bool as a param, the other an unsigned int. When I called the function with an int, the compiler converted the param to a bool and called the wrong method. I know eventually I'll replace the bool, but for now don't want to break the other routines as this new routine is developed.

Thanks

A: 

Compiler gave "ambiguous call" warning, which will be sufficient.

I was doing TDD development and didn't realize I forgot to implement the corresponding call in the mock object.

Dan Pieczynski
You may want to consider updating the question to reflect that what you indicated was the problem (wrong method being selected) was not actually the problem. I was revisiting this for my own purposes and realized that even my solution does not necessarily address that, depending on the arguments.
Patrick Johnmeyer
A: 

You could also write an int version that calls the bool one.

aib
+3  A: 

No. explicit prevents automatic conversion between specific classes, irrespective of context. And of course you can't do it for built-in classes.

Lev
Voted up; this does answer the question correctly, after all.
Patrick Johnmeyer
A: 

bool IS an int that is limited to either 0 or 1. That is the whole concept of return 0;, it is logically the same as saying return false;(don't use this in code though).

WolfmanDragon
I believe bool is an actual type of its own, in C++.
Head Geek
Yes it is a type , but the type can hold only int values of 0 and 1. actually if I remember my C++ instructor from my collage days, 0 is false and anything else is true. This is the inner working of bool, not how it should be applied.
WolfmanDragon
Not to be a jerk, but "collage days"? Hehehe... made me chuckle.
Patrick Johnmeyer
You are right that bools can only hold the values 0 and 1; convert a bool to an int, you will get 0 or 1. "0 is false and anything else is true" applies in the reverse case; if you evaluate an int or other numeric as a bool. The concept of return 0 actually comes from C when there was no bool type.
Patrick Johnmeyer
I must still be in one, it took me until today to catch my pun.
WolfmanDragon
+10  A: 

No, you can't use explicit, but you can do this instead:

class ClassThatOnlyTakesBoolsAndUIntsAsArguments
{
public:
  void Method(bool arg1);
  void Method(unsigned int arg1);

  // Below just an example showing how to do the same thing with more arguments
  void MethodWithMoreParms(bool arg1, SomeType& arg2);
  void MethodWithMoreParms(unsigned int arg1, SomeType& arg2);

private:
  template<typename T>
  void Method(T arg1);

  // Below just an example showing how to do the same thing with more arguments
  template<typename T>
  void MethodWithMoreParms(T arg1, SomeType& arg2);
};

Repeat this pattern for every method that takes the bool or unsigned int. Do not provide an implementation for the templatized version of the method.

This will force the user to always explicitly call the bool or unsigned int version.

Any attempt to call Method with a type other than bool or unsigned int will fail to compile because the member is private, subject to the standard exceptions to visibility rules, of course (friend, internal calls, etc.). If something that does have access calls the private method, you will get a linker error.

Patrick Johnmeyer
But this will disable ALL automatic conversions.
Lev
Yes, it will disable ALL automatic conversions. Dan wants to "prevent the conversion of parameters for a class method", per the question text, and this method satisfies that. There are ways using template specialization that we could 'map' basic types to specific methods if so desired.
Patrick Johnmeyer
+1  A: 

Something that might work for you is to use templates. The following shows the template function foo<>() being specialized for bool, unsigned int, and int. The main() function shows how the calls get resolved. Note that the calls that use a constant int that don't specify a type suffix will resolve to foo<int>(), so you'll get an error calling foo( 1) if you don't specialize on int. If this is the case, callers using a literal integer constant will have to use the "U" suffix to get the call to resolve (this might be the behavior you want).

Otherwise you'll have to specialize on int and use the "U" suffix or cast it to an unsigned int before passing it on to the unsigned int version (or maybe do an assert that the value isn't negative, if that's what you want).

#include <stdio.h>

template <typename T>
void foo( T);

template <>
void foo<bool>( bool x)
{
    printf( "foo( bool)\n");
}


template <>
void foo<unsigned int>( unsigned int x)
{
    printf( "foo( unsigned int)\n");
}


template <>
void foo<int>( int x)
{
    printf( "foo( int)\n");
}



int main () 
{
    foo( true);
    foo( false);
    foo( static_cast<unsigned int>( 0));
    foo( 0U);
    foo( 1U);
    foo( 2U);
    foo( 0);
    foo( 1);
    foo( 2);
}
Michael Burr
I thought about doing it this way, too; having foo<int> call foo<unsigned int> to explicitly map. This is a better way if he wants to allow some conversions but not all.
Patrick Johnmeyer
Actually, this is really the same method as yours. When I quickly scanned yours shortly before posting I got thrown off by the multi-parameter prototypes and thought your technique was doing something different that I didn't fully understand. I should have read more closely.
Michael Burr
Ah -- the multi-parameter versions were supposed to be to clarify that it didn't only apply to single parm methods, and that only the argument in question had to be templatized. Perhaps they were more confusing than beneficial? I'll add a comment to clear this up.
Patrick Johnmeyer
Just because they confused me for a bit doesn't mean they were confusing. If that makes any sense.
Michael Burr
+2  A: 

The following is a very basic wrapper that can be used to create a strong typedef:

template <typename V, class D> 
class StrongType
{
public:
  inline explicit StrongType(V const &v)
  : m_v(v)
  {}

  inline operator V () const
  {
    return m_v;
  }

private:
  int m_v;
};

class Tag1;
typedef StrongType<int, Tag1> Tag1Type;


void b1 (Tag1Type);

void b2 (int i)
{
  b1 (Tag1Type (i));
  b1 (i);                // Error
}

One nice feature of this approach, is that you can also distinguish between different parameters with the same type. For example you could have the following:

class WidthTag;
typedef StrongType<int, WidthTag> Width;  
class HeightTag;
typedef StrongType<int, HeightTag> Height;  

void foo (Width width, Height height);

It will be clear to the clients of 'foo' which argument is which.

Richard Corden