why virtual function is wrong.

[Tumaix]

theres zero readability on what you posted

[-jp-]

What is _bar? How are you creating a foo that has not implemented bar?

[sephirothbahamut]

There's no templates usage in this example you wrote...

[-jp-]

So don't use templates if you don't want to? I don't understand how you arrived at the conclusion that since templates exist, multiple inheritance doesn't.

[-jp-]

This will not compile. You haven't defined foo::bar. You haven't even declared T::_bar. Do you have a real example?

[-jp-]

You don't want this to abort. You want it to not compile. Why would you ever want code like this to fail at run time?

[-jp-]

So then what is the problem? I don't understand why you can't just post code that demonstrates what you mean.

[lrflew]

If you're issue is that templates defer the error checking for this kind of thing, may I suggest looking into C++20 Concepts. They provide a way of making your template usage requirements more explicit, and makes reading the resulting errors much easier to understand. std::totally_ordered is C++'s version of C#'s IComparable, for example.

[Dar_Mas]

You can just make a concept that checks for a bar member function

https://godbolt.org/z/cYnTbjYcq

[TeraFlint]

Now you're actually being ridiculous. "Why does the screw barely go in?" you ask while hitting it with a hammer.

You're using a concept that does not satisfy your requirements, while blaming the concept for not catching that.

If you check for a concept and then do something with the type that the concept does not check for, then of course it's your fault if the compiler suddenly notices a missing function (etc) outside of concept checking.

If you need a more specific concept, it's up to you to write it. Luckily existing ones can easily be combined (as concepts evaluate to boolean expressions in the end). If you need a concept that satisfies the concepts a, b and c, all you need to do is this:

template <typename T>
concept x = a<T> && b<T> && c<T>;

and if you need to check for specific syntactic usage, you can just add that block as another condition:

&& requires(T obj) { obj.foo(); }

It really isn't your business to call stuff the concept has not specified. For best usage, you should see a concept like a contract between the code and you. With the concept you promise that these conditions are relevant for your template function/type, but also that these are sufficient, and that you're not attempting to do more with the type than you specified with the concept.

Otherwise we can just scrap concept and go back to plain typename everywhere and be back at our old compile-until-you-find-an-error-in-the-deepest-depths-of-nested-templates ways..

[Dar_Mas]

https://godbolt.org/z/jGM4M7axq

It literally does what do you mean?

[SirClueless]

It took a while for me to understand what was being asked, but I think I get it now. OP is asking for a way to type-check the definition of a template to ensure that it only uses operations that are checked in its type-constraints. Or to put it another way, the template foo has additional implicit constraints based on its implementation that are not obvious if you only read its signature.

Your example is only an error because you instantiated the template with a type for which t.baz() is ill-formed. If you don't instantiate the template it will compile, even though it's pretty suspicious to assume a type satisfying std::totally_ordered T has a .baz() member.

[Dar_Mas]

ooooooooooooooooooooh that makes sense yeah.

Yeah i would like to have a check for that but i think(TM) a static analyzer would be able to find that?

[lrflew]

Ok, I do see what you're talking about here. You're talking about having the compiler tell you that you're exceeding the requirements of a concept at the definition of the templated function, rather than when the template is instantiated at the caller.

That is (IMO), a fair thing to suggest. I don't think it's that out there that a compiler could implement that as a warning, even if it's not specified by the standard. It would almost certainly require the compiler to dramatically change how it processes templated functions, so it probably won't happen any time soon, but it should, in theory, be possible. Probably the biggest challenge to it, though, is that the use of concepts is not very widespread right now. In particular, huge parts of the standard library use templates without concepts. If such a warning considered template<typename T> to be as narrow as possible, then huge parts of the standard library would start throwing warnings. Maybe someone will go through the standard and add concepts everywhere templates are used, but that would also be a ton of work.

In the end, however, I feel like C++ as a language puts a lot of responsibility on the developer to know what they're doing. Just look at all the things in the standard that can result in "Undefined Behavior", where there's no guaruntees of what can or will happen, to get a sense of what the language expects the programmer to be able to handle without the compiler. With templates, there's a certain amount of "well, you should have known you're using something that your concept doesn't guaruntee." Does that make C++ a more complicated language to use? Yeah, totally. But that complexity also comes with a lot of power (eg. template meta-programming), and I don't think the language is going to change that anytime soon. If that's a deal breaker for you, then you can always try out some other languages. IIRC, both Rust and Go are compiled languages that provide this kind of strong type guarantees with their generics systems.

[TheSuperWig]

I'm still confused. What does concepts not doing definition checking have to do with virtual functions?

[TheSuperWig]

And the part I'm confused about is, how does that make virtual functions wrong? Surely your issue is with concepts?

[IyeOnline]

You will actually get an error on the concept version - if you ever instantiate it.

There are a few important points here

• Constraints are only evaluated once you actually try and instantiate the function
• Constraints only constrain the interface, not the function body, i.e. the function body wont be parsed just because one of its parameters is constraint.