# Template-related compiler bug or... ?

This topic is 827 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

In VS 2015 I'm getting an error that I didn't expect and I'm wondering if this is a bug or if it's not expected to work.

The issue itself is trivial. I'd have used a cast in any case to suppress the warning, but I'm wanting to know whether I should report the bug to MS.

Code to recreate:

template <typename T>
struct Foo { T val; };

template <typename T>
Foo<T>& operator*=(Foo<T>& left, T right) {
left.val *= right;
return left;
}

void main() {
Foo<float> bar;
bar *= 4; //"no operator *= matches these operands"
}


I get why it's happening, but I kind of expect that when it doesn't find a float,int signature it will make the effort to check promotions.

Is this standard?

##### Share on other sites
Should the left.val *= right actually have right.val?

Because otherwise, whatever type T is needs to be implicitly convertable to something that can be multiplied by left.val. And that structure is not.

##### Share on other sites

My bad, I was fiddling with it. I'll fix it in the OP. 'left' should be Foo<T>&.

##### Share on other sites

C++ template parameter deduction rules are smart, but there are limits. Essentially you ran into one. Each template function parameter is independently used to deduce the type of T. If different parameters disagree on the type of T, then the template is not considered.

C++ template type deduction rules are spelled out in the standard in excruciating detail, and compilers implement it exactly as specified; they cannot be any more or less smart about it because it would change the semantics of the language. While bugs are possible, you would need to be well versed in the C++ standard to differentiate between compiler bugs and C++ limitations.

Edited by King Mir

##### Share on other sites

C++ template type deduction rules are spelled out in the standard in excruciating detail

Okay, so are you going to cite a relevant passage so the question is answered?

and compilers implement it exactly as specified

Except for when they don't.

While bugs are possible, you would need to be well versed in the C++ standard to differentiate between compiler bugs and C++ limitations.

There are people here that are extremely well-versed, so I'm asking those people.

##### Share on other sites
I told you the rule that is applied, but I cannot cite the standard. If you require that level of rigor, I recommend reading the standard yourself.

##### Share on other sites

You also told me that compilers always implement the standard correctly and asserted the reasoning that it's not possible to find a bug unless you've memorized the standard.

I am searching the standard right now, but I'm also allowed to ask other people that are more familiar with it in case someone knows with a satisfactory degree of confidence.

##### Share on other sites

The behavior is standard. The relevant section is §14.8.3, paragraph 1.

##### Share on other sites
The rules limit it to one implicit conversion and one user-supplied conversion. This is already enough to nearly overwhelm some compilers with large code bases. Being able to consider a larger number of conversion chains would have an enormous search space when trying to figure out conversions for template types. So this can work if you reduce the levels of indirection by one.

The rules also only allow the implicit conversions when used explicitly as a parameter, (so if you specified the value was a float explicitly) but it does not need to consider all implicit conversions when doing template argument deduction, which can get quite complex and compilation complexity would be worse if it needed to consider everything that could possibly be implicitly converted.

You say you already see what you need to do. Make the number a float rather than relying on an implicit int to float conversion, as you know you should. With no implicit conversion, template argument deduction will work exactly as it should.

1. 1
2. 2
Rutin
24
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 22
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631766
• Total Posts
3002221
×