I know you can use C++ keyword &#39;explicit&#39; 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&#39;ll replace the bool, but for now don&#39;t want to break the other routines as this new routine is developed.

Can you use keyword explicit to prevent automatic conversion of method parameters?

Consider this piece of code:

    struct Base
    {
        int x;
    };
    
    struct Bar : Base
    {
        int y;
    };
    
    struct Foo : Base
    {
        int z;
    };
    
    Bar* bar = new Bar;
    Foo* foo = new Foo;
    
    Base* returnBase()
    {
    	Base* obj = !bar ? foo : bar;
    	return obj;
    }
    
    int main() {
    	returnBase();
    	return 0;
    }

This doesn&#39;t work under Clang or GCC, giving me :

&gt; error: conditional expression between distinct pointer types ‘Foo*’
&gt; and ‘Bar*’ lacks a cast   Base* obj = !bar ? foo : bar;

Which means for it to compile I have to change the code to : 

    Base* obj = !bar ? static_cast&lt;Base*&gt;(foo) : bar;

Since an implicit cast to a `Base*` exists, what is preventing the compiler from doing so?

In other words, why does `Base* obj = foo;` work without a cast but using the `?:` operator doesn&#39;t? Is it because it&#39;s not clear that I want to use the `Base` part?

Ternary operator implicit cast to base class

This is a weird behaviour that I cannot make sense of. In my example I have a class `Sample&lt;T&gt;` and an implicit conversion operator from `T` to `Sample&lt;T&gt;`. 

    private class Sample&lt;T&gt;
    {
       public readonly T Value;

       public Sample(T value)
       {
          Value = value;
       }

       public static implicit operator Sample&lt;T&gt;(T value) =&gt; new Sample&lt;T&gt;(value);
    }

The problem occurs when using a nullable value type for `T` such as `int?`. 

    {
       int? a = 3;
       Sample&lt;int&gt; sampleA = a;
    }

**Here is the key part:**  
In my opinion this should not compile because `Sample&lt;int&gt;` defines a conversion from `int` to `Sample&lt;int&gt;` but not from `int?` to `Sample&lt;int&gt;`. **But it compiles and runs successfully!** (By which I mean the conversion operator is invoked and `3` will be assigned to the `readonly` field.)

And it gets even worse. Here the conversion operator isn&#39;t invoked and `sampleB` will be set to `null`:

    {
       int? b = null;
       Sample&lt;int&gt; sampleB = b;
    }

A great answer would probably be split into two parts:

1. Why does the code in the first snippet compile?
2. Can I prevent the code from compiling in this scenario?

Why does an implicit conversion operator from &lt;T&gt; to &lt;U&gt; accept &lt;T?&gt;?

Given some Dictionaries

    Dictionary&lt;string, string&gt; GroupNames = new Dictionary&lt;string, string&gt;();
    Dictionary&lt;string, string&gt; AddedGroupNames = new Dictionary&lt;string, string&gt;();

I am unable to merge them into one:

    GroupNames = GroupNames.Concat(AddedGroupNames);

because &quot;the type can&#39;t be implicitly converted&quot;. I believe (and my code proves me true) their type is the same - what am I overlooking?

Concatenate two Dictionaries

Could someone give me an explanation why I get two different 
numbers, resp. 14 and 15, as an output from the following code?

    #include &lt;stdio.h&gt;  

    int main()
    {
        double Vmax = 2.9; 
        double Vmin = 1.4; 
        double step = 0.1; 

        double a =(Vmax-Vmin)/step;
        int b = (Vmax-Vmin)/step;
        int c = a;

        printf(&quot;%d  %d&quot;,b,c);  // 14 15, why?
        return 0;
    }

I expect to get 15 in both cases but it seems I&#39;m missing some fundamentals of the language.

I am not sure if it&#39;s relevant but I was doing the test in CodeBlocks. However, if I type the same lines of code in some on-line compiler ( [this one for example][1]) I get an answer of 15 for the two printed variables.


  [1]: https://www.onlinegdb.com/online_c_compiler

Nonintuitive result of the assignment of a double precision number to an int variable in C

I recently found this code:

     public static implicit operator XElement(XmlBase xmlBase)
     {
         return xmlBase.Xml;
     }

What does `static implicit operator` mean?


Static implicit operator

I&#39;m working through some exercises and have got a warning that states: 

&gt;*Implicit conversion loses integer precision: &#39;NSUInteger&#39; (aka &#39;unsigned long&#39;) to &#39;int&#39;*

    #import &lt;Foundation/Foundation.h&gt;
    
    int main (int argc, const char * argv[])
    {
        @autoreleasepool {
            
            NSArray *myColors;
            
            int i;
            int count;
            
            myColors = @[@&quot;Red&quot;, @&quot;Green&quot;, @&quot;Blue&quot;, @&quot;Yellow&quot;];
            
            count = myColors.count; //  &lt;&lt;&lt; issue warning here
            
            for (i = 0; i &lt; count; i++)
                
            NSLog (@&quot;Element %i = %@&quot;, i, [myColors objectAtIndex: i]);
        }
        
        return 0;
    }

![Screenshot][1]


  [1]: https://i.stack.imgur.com/SvdgN.png

Objective-C implicit conversion loses integer precision &#39;NSUInteger&#39; (aka &#39;unsigned long&#39;) to &#39;int&#39; warning

Why does the first and second Write work but not the last? Is there a way I can allow all 3 of them and detect if it was 1, (int)1 or i passed in? And really why is one allowed but the last? The second being allowed but not the last really blows my mind.

[Demo to show compile error](http://ideone.com/tQjCm)

	using System;
	class Program
	{
		public static void Write(short v) { }
		static void Main(string[] args)
		{
			Write(1);//ok
			Write((int)1);//ok
			int i=1;
			Write(i);//error!?
		}
	}




Why can I pass 1 as a short, but not the int variable i?

Is it possible to define an implicit conversion of enums in c#?

something that could achieve this?

    public enum MyEnum
    {
        one = 1, two = 2
    }

    MyEnum number = MyEnum.one;
    long i = number;

If not, why not?

Can we define implicit conversions of enums in c#?

How does the following code work?

    typedef char (&amp;yes)[1];
    typedef char (&amp;no)[2];
    
    template &lt;typename B, typename D&gt;
    struct Host
    {
      operator B*() const;
      operator D*();
    };
    
    template &lt;typename B, typename D&gt;
    struct is_base_of
    {
      template &lt;typename T&gt; 
      static yes check(D*, T);
      static no check(B*, int);
    
      static const bool value = sizeof(check(Host&lt;B,D&gt;(), int())) == sizeof(yes);
    };
    
    //Test sample
    class Base {};
    class Derived : private Base {};
    
    //Expression is true.
    int test[is_base_of&lt;Base,Derived&gt;::value &amp;&amp; !is_base_of&lt;Derived,Base&gt;::value];

1. Note that `B` is private base. How does this work? 

2. Note that `operator B*()` is const. Why is it important?

3. Why is `template&lt;typename T&gt; static yes check(D*, T);` better than `static yes check(B*, int);` ? 

**Note**: It is reduced version (macros are removed) of `boost::is_base_of`. And this works on wide range of compilers.

 


How does `is_base_of` work?

For example:

    operator bool() const 
    { 
        return col != 0; 
    }

`col` is an int.
How does `operator bool() const` work?


What is the meaning of &quot;operator bool() const&quot;

*This post is meant to be used as a FAQ regarding implicit integer promotion in C, particularly implicit promotion caused by the usual arithmetic conversions and/or the integer promotions.*


Example 1)  
Why does this give a strange, large integer number and not 255?

    unsigned char x = 0;
    unsigned char y = 1;
    printf(&quot;%u\n&quot;, x - y); 

Example 2)  
Why does this give &quot;-1 is larger than 0&quot;?

    unsigned int a = 1;
    signed int b = -2;
    if(a + b &gt; 0)
      puts(&quot;-1 is larger than 0&quot;);

Example 3)  
Why does changing the type in the above example to `short` fix the problem?

    unsigned short a = 1;
    signed short b = -2;
    if(a + b &gt; 0)
      puts(&quot;-1 is larger than 0&quot;); // will not print


(These examples were intended for a 32 or 64 bit computer with 16 bit short.)

Implicit type promotion rules

Worth a thousand words:

    #include&lt;string&gt;
    #include&lt;iostream&gt;
    
    class SayWhat {
        public:
        SayWhat&amp; operator[](const std::string&amp; s) {
            std::cout &lt;&lt; s &lt;&lt; &quot;\n&quot;;
            return *this;
        }
    };
    
    int main() {
        SayWhat ohNo;
        // ohNo[1]; // Does not compile. Logic prevails.
        ohNo[0]; // you didn&#39;t! this compiles.
        return 0;
    }

The compiler is not complaining when passing the number 0 to the bracket operator accepting a string. Instead, this compiles and fails before entry to the method with:

    terminate called after throwing an instance of &#39;std::logic_error&#39;
      what():  basic_string::_S_construct null not valid

For reference:

    &gt; g++ -std=c++17 -O3 -Wall -Werror -pedantic test.cpp -o test &amp;&amp; ./test
    &gt; g++ --version
    gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)

**My guess**

The compiler is implicitly using the `std::string(0)` constructor to enter the method, which yields the same  problem (google the above error) for no good reason.

**Question**

Is there anyway to fix this on the class side, so the API user does not feel this and the error is detected at compile time? 

That is, adding an overload

    void operator[](size_t t) {
        throw std::runtime_error(&quot;don&#39;t&quot;);
    }

is not a good solution.



Prevent function taking const std::string&amp; from accepting 0

In Scala, we can use at least two methods to retrofit existing or new types. Suppose we want to express that something can be quantified using an `Int`. We can define the following trait.

###Implicit conversion

    trait Quantifiable{ def quantify: Int }

And then we can use implicit conversions to quantify e.g. Strings and Lists.

    implicit def string2quant(s: String) = new Quantifiable{ 
      def quantify = s.size 
    }
    implicit def list2quantifiable[A](l: List[A]) = new Quantifiable{ 
      val quantify = l.size 
    }

After importing these, we can call the method `quantify` on strings and lists. Note that the quantifiable list stores its length, so it avoids the expensive traversal of the list on subsequent calls to `quantify`.

###Type classes

An alternative is to define a &quot;witness&quot; `Quantified[A]` that states, that some type `A` can be quantified.

    trait Quantified[A] { def quantify(a: A): Int }

We then provide instances of this type class for `String` and `List` somewhere.

    implicit val stringQuantifiable = new Quantified[String] {
      def quantify(s: String) = s.size 
    }

And if we then write a method that needs to quantify its arguments, we write:

    def sumQuantities[A](as: List[A])(implicit ev: Quantified[A]) = 
      as.map(ev.quantify).sum

Or using the context bound syntax:

    def sumQuantities[A: Quantified](as: List[A]) = 
      as.map(implicitly[Quantified[A]].quantify).sum

###But when to use which method?
Now comes the question. How can I decide between those two concepts?

What I have noticed so far.

**type classes**

 - type classes allow the nice context bound syntax
 - with type classes I don&#39;t create a new wrapper object on each use
 - the context bound syntax does not work anymore if the type class has multiple type parameters; imagine I want to quantify things not only with integers but with values of some general type `T`. I would want to create a type class `Quantified[A,T]`

**implicit conversion**

 - since I create a new object, I can cache values there or compute a better representation; but should I avoid this, since it might happen several times and an explicit conversion would probably be invoked only once?

###What I expect from an answer
Present one (or more) use case(s) where the difference between both concepts matters and explain why I would prefer one over the other. Also explaining the essence of the two concepts and their relation to each other would be nice, even without example.



Implicit conversion vs. type class

The statement

    printf(&quot;%f\n&quot;,0.0f);

prints 0.

However, the statement

    printf(&quot;%f\n&quot;,0);

prints random values.  

I realize I&#39;m exhibiting some kind of undefined behaviour, but I can&#39;t figure out why specifically.  

A floating point value in which all the bits are 0 is still a valid `float` with value of 0.  
`float` and `int` are the same size on my machine (if that is even relevant).  

Why does using an integer literal instead of a floating point literal in `printf` cause this behavior?

P.S. the same behaviour can be seen if I use

    int i = 0;
    printf(&quot;%f\n&quot;, i);

Why does printf(&quot;%f&quot;,0); give undefined behavior?

An _implicit_ question to newcomers to Scala seems to be: where does the compiler look for implicits? I mean implicit because the question never seems to get fully formed, as if there weren&#39;t words for it. :-) For example, where do the values for `integral` below come from?

    scala&gt; import scala.math._
    import scala.math._
    
    scala&gt; def foo[T](t: T)(implicit integral: Integral[T]) {println(integral)}
    foo: [T](t: T)(implicit integral: scala.math.Integral[T])Unit
    
    scala&gt; foo(0)
    scala.math.Numeric$IntIsIntegral$@3dbea611
    
    scala&gt; foo(0L)
    scala.math.Numeric$LongIsIntegral$@48c610af

Another question that does follow up to those who decide to learn the answer to the first question is how does the compiler choose which implicit to use, in certain situations of apparent ambiguity (but that compile anyway)?

For instance, `scala.Predef` defines two conversions from `String`: one to `WrappedString` and another to `StringOps`. Both classes, however, share a lot of methods, so why doesn&#39;t Scala complain about ambiguity when, say, calling `map`?

**Note:** this question was inspired by [this other question][1], in the hopes of stating the problem in a more general manner. The example was copied from there, because it is referred to in the answer.


  [1]: https://stackoverflow.com/questions/5512397/passing-scala-math-integral-as-implicit-parameter

Where does Scala look for implicits?

The pimp-my-library pattern allows me to seemingly add a method to a class by making available an implicit conversion from that class to one that implements the method.

Scala does not allow two such implicit conversions taking place, however, so I cannot got from `A` to `C` using an implicit `A` to `B` and another implicit `B` to `C`. Is there a way around this restriction?

How can I chain implicits in Scala?

To my astonishment, this compiles:

	const char* c_str()
	{
		static const char nullchar = &#39;\0&#39;;
		return nullchar;
	}


and it introduced a bug in my code. Thankfully, I caught it.

Is this intentional by C++, or a compiler bug? Is there a reason why the data type is actively ignored?  
It worked in Visual C++ 2010 and [GCC](http://ideone.com/Crhv2), but I don&#39;t understand why it should work, given the obvious data type mismatch. (The `static` isn&#39;t necessary, either.)

Why is C++ allowing me to assign a const char to a const char *?​!

How do I avoid implicit casting on non-constructing functions?  
I have a function that takes an integer as a parameter,  
but that function will also take characters, bools, and longs.  
I believe it does this by implicitly casting them.  
How can I avoid this so that the function only accepts parameters of a matching type, and will refuse to compile otherwise?  
There is a keyword &quot;explicit&quot; but it does not work on non-constructing functions. :\  
what do I do?

The following program compiles, although I&#39;d like it not to:

    #include &lt;cstdlib&gt;
    
    //the function signature requires an int
    void function(int i);
    
    int main(){
    
    	int i{5};
    	function(i); //&lt;- this is acceptable
    
    	char c{&#39;a&#39;};
    	function(c); //&lt;- I would NOT like this to compile
    
    	return EXIT_SUCCESS;
    }
    
    void function(int i){return;}

*please be sure to point out any misuse of terminology and assumptions 

How do I avoid implicit conversions on non-constructing functions?

For example the following query works fine:

    SELECT * 
      FROM quotes 
     WHERE expires_at &lt;= &#39;2010-10-15 10:00:00&#39;;

But this is obviously performing a &#39;string&#39; comparison - I was wondering if there was a function built in to MySQL that specifically does &#39;datetime&#39; comparisons.

mysql datetime comparison

My class has an explicit conversion to bool:

    struct T {
        explicit operator bool() const { return true; }
    };

and I have an instance of it:

    T t;

To assign it to a variable of type `bool`, I need to write a cast:

    bool b = static_cast&lt;bool&gt;(t);
    bool b = bool(t);
    bool b(t);  // converting initialiser
    bool b{static_cast&lt;bool&gt;(t)};

I know that I can use my type directly in a conditional without a cast, despite the `explicit` qualifier:

    if (t)
        /* statement */;

Where else can I use `t` as a `bool` without a cast?

When can I use explicit operator bool without a cast?

I have a generic class that I&#39;m trying to implement implicit type casting for.  While it mostly works, it won&#39;t work for interface casting.  Upon further investigation, I found that there is a compiler error: &quot;User-defined conversion from interface&quot; that applies.  While I understand that this should be enforced in some cases, what I&#39;m trying to do does seem like a legitimate case.

Here&#39;s an example:

    public class Foo&lt;T&gt; where T : IBar
    {
        private readonly T instance;
    
        public Foo(T instance)
        {
            this.instance = instance;
        }
        public T Instance
        {
            get { return instance; }
        }
        public static implicit operator Foo&lt;T&gt;(T instance)
        {
            return new Foo&lt;T&gt;(instance);
        }
    }

Code to use it:

    var concreteReferenceToBar = new ConcreteBar();
    IBar intefaceReferenceToBar = concreteReferenceToBar;
    Foo&lt;ConcreteBar&gt; concreteFooFromConcreteBar = concreteReferenceToBar;
    Foo&lt;IBar&gt; fooFromConcreteBar = concreteReferenceToBar;
    Foo&lt;IBar&gt; fooFromInterfaceBar = intefaceReferenceToBar; // doesn&#39;t work

Does anyone know a workaround, or can anyone explain in a satisfactory way why I shuouldn&#39;t be able to cast `interfaceReferenceToBar` implicitly to `Foo&lt;IBar&gt;`, since in my case it is not being converted, but only contained within Foo?

**EDIT:**
It looks like covariance might offer salvation.  Let&#39;s hope the C# 4.0 specification allows for implicit casting of interface types using covariance.

implicit operator using interfaces

A pointer to non-const data can be implicitly converted to a pointer to const data of the same type:

    int       *x = NULL;
    int const *y = x;

Adding additional const qualifiers to match the additional indirection should logically work the same way:

    int       *      *x = NULL;
    int       *const *y = x; /* okay */
    int const *const *z = y; /* warning */

Compiling this with GCC or Clang with the `-Wall` flag, however, results in the following warning:

    test.c:4:23: warning: initializing &#39;int const *const *&#39; with an expression of type
          &#39;int *const *&#39; discards qualifiers in nested pointer types
        int const *const *z = y; /* warning */
                          ^   ~

Why does adding an additional `const` qualifier &quot;discard qualifiers in nested pointer types&quot;?

Double pointer const-correctness warnings in C

I&#39;m a little stumped by this little C# quirk:

Given variables:

    Boolean aBoolValue;
    Byte aByteValue;

The following compiles:

    if (aBoolValue) 
        aByteValue = 1; 
    else 
        aByteValue = 0;

But this will not:

    aByteValue = aBoolValue ? 1 : 0;

Error says: &quot;Cannot implicitly convert type &#39;int&#39; to &#39;byte&#39;.&quot;

And of course, this monstrosity will compile:

    aByteValue = aBoolValue ? (byte)1 : (byte)0;

What&#39;s going on here?

EDIT:

Using VS2008, C# 3.5

Conditional operator cannot cast implicitly?

Say I&#39;m writing an extension method

    implicit class EnhancedFoo(foo: Foo) {
      def bar() { /* ... */ }
    }
Should you always include `extends AnyVal` in the class defininition? Under what circumstances would you not want to make an implicit class a value class?

Should implicit classes always extend AnyVal?

I have created a couple of interfaces and generic classes for working with agenda appointments:

    interface IAppointment&lt;T&gt; where T : IAppointmentProperties
    {
        T Properties { get; set; }
    }

    interface IAppointmentEntry&lt;T&gt; where T : IAppointment&lt;IAppointmentProperties&gt;
    {
        DateTime Date { get; set; }
        T Appointment { get; set; }
    }

    interface IAppointmentProperties 
    {
        string Description { get; set; }
    }

    class Appointment&lt;T&gt; : IAppointment&lt;T&gt; where T : IAppointmentProperties
    {
        public T Properties { get; set; }
    }

    class AppointmentEntry&lt;T&gt; : IAppointmentEntry&lt;T&gt; where T : IAppointment&lt;IAppointmentProperties&gt;
    {
        public DateTime Date { get; set; }
        public T Appointment { get; set; }
    }

    class AppointmentProperties : IAppointmentProperties
    {
        public string Description { get; set; }
    }

I&#39;m trying to use some constraints on the type parameters to ensure that only valid types can be specified. However, when specifying a constraint defining that `T` must implement `IAppointment&lt;IAppointmentProperties&gt;`, the compiler gives an error when using a class that is `Appointment&lt;AppointmentProperties&gt;`:

    class MyAppointment : Appointment&lt;MyAppointmentProperties&gt;
    {
    }

    // This goes wrong:
    class MyAppointmentEntry : AppointmentEntry&lt;MyAppointment&gt;
    {
    }

    class MyAppointmentProperties : AppointmentProperties
    {
        public string ExtraInformation { get; set; }
    }

The error is:

`The type &#39;Example.MyAppointment&#39; cannot be used as type parameter &#39;T&#39; in the generic type or method &#39;Example.AppointmentEntry&lt;T&gt;&#39;. There is no implicit reference conversion from &#39;Example.MyAppointment&#39; to &#39;Example.IAppointment&lt;Example.IAppointmentProperties&gt;&#39;.`


Could anybody explain why this does not work?

Why does a generic type constraint result in a no implicit reference conversion error?

I think this question will bring me instant fame here on Stack Overflow.

Suppose you have the following type:

    // represents a decimal number with at most two decimal places after the period
    struct NumberFixedPoint2
    {
        decimal number;

        // an integer has no fractional part; can convert to this type
        public static implicit operator NumberFixedPoint2(int integer)
        {
            return new NumberFixedPoint2 { number = integer };
        }
        
        // this type is a decimal number; can convert to System.Decimal
        public static implicit operator decimal(NumberFixedPoint2 nfp2)
        {
            return nfp2.number;
        }

        /* will add more nice members later */
    }

It has been written such that only safe conversions that don&#39;t lose precision are allowed. However, when I try this code:

        static void Main()
        {
            decimal bad = 2.718281828m;
            NumberFixedPoint2 badNfp2 = (NumberFixedPoint2)bad;
            Console.WriteLine(badNfp2);
        }

I am surprised this compiles and, when run, **writes out `2`**. The conversion from `int` (of value `2`) to `NumberFixedPoint2` is important here. (An overload of `WriteLine` that takes in a `System.Decimal` is preferred, in case anyone wonders.)

Why on Earth is the conversion from `decimal` to `NumberFixedPoint2` allowed? (By the way, in the above code, if `NumberFixedPoint2` is changed from a struct to a class, nothing changes.)

Do you know if the C# Language Specification says that an implicit conversion from `int` to a custom type &quot;implies&quot; the existence of a &quot;direct&quot; explicit conversion from `decimal` to that custom type?

It becomes much worse. Try this code instead:

        static void Main()
        {
            decimal? moreBad = 7.3890560989m;
            NumberFixedPoint2? moreBadNfp2 = (NumberFixedPoint2?)moreBad;
            Console.WriteLine(moreBadNfp2.Value);
        }

As you see, we have (lifted) `Nullable&lt;&gt;` conversions here. But oh yes, that does compile.

When compiled in **x86** &quot;platform&quot;, this code writes out an unpredictable numeric value. Which one varies from time to time. As an example, on one occasion I got **`2289956`**. Now, that&#39;s one serious bug!

When compiled for the **x64** platform, the above code crashes the application with a `System.InvalidProgramException` with message **Common Language Runtime detected an invalid program.** According to the documentation of the `InvalidProgramException` class:

&gt; Generally this indicates a bug in the compiler that generated the program.

Does anyone (like Eric Lippert, or someone who has worked with lifted conversions in the C# compiler) know the cause of these bugs? Like, what is a sufficient condition that we don&#39;t run into them in our code? Because the type `NumberFixedPoint2` is actually something that we have in real code (managing other people&#39;s money and stuff).

All Implicit Conversion Solutions on Gang of Coders

Total of 27 Implicit Conversion Solutions