Defining interfaces in C++ with ‘concepts’ (C++20)

https://lemire.me/blog/2023/04/18/defining-interfaces-in-c-with-concepts-c20/

by pjmlp • 3 years ago

73 54 3 years ago

In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector.

I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, being a statically typed language, lots of the same optimisations are available.

travisd2• 3 years ago

Go generally is pretty conservative about that kind of thing (namely, compiler optimizations). Go generally abides by a “what you write is what you get” kind of thing, especially when it comes to “non-local” optimizations. It’s generally opposed to anything that’s “clever.” (Just my feeling as someone who uses Go pretty often and who respects the choice they’ve made on that spectrum).

perfmode2• 3 years ago

it’s actually to keep compile times fast

and for the implementation of the compiler to remain simple

MarkMarine• 3 years ago

Interfaces always go to the heap in go, so yes, you can take some simple code that could easily live on the stack and make it slower by wrapping it in interfaces with go.

wahern• 3 years ago

Interface methods in Go are like virtual methods in C++. In principle C++ compilers when statically compiling everything can often remove virtual method indirection for some objects, but I think in general this optimization is still uncommon and difficult to coax out a compiler. Go definitely does not do this, even though in principle it should be easier.

Basically, "interfaces" in Go and C++ actually refer to quite different language features. (Or at least, the author is using the term to describe quite different language features.)

pjmlp4• 3 years ago

This is common when doing LTO, without it there is no guarantee that there isn't some dynamically loaded code that would be broken, this is one area where JIT focused languages have an advantage.

perfmode2• 3 years ago

There is overhead in interface indirection because the Go runtime needs to perform dynamic dispatch to determine which method to call at runtime.

C++ can optimize interface indirection away because it supports static polymorphism, which allows the compiler to generate specialized code for each concrete type used with a generic interface, eliminating the need for dynamic dispatch.

unwind• 3 years ago

As always, very informative and a perfect "snippet" size to quickly read and learn a new thing or two. Thanks!

Meta: I think the very first sentence is the victim of some drive-by editing, and needs one more pass. I'm not a native speaker, but I still suggest changing

In an earlier blog post, I showed on the Go programming language allow you to write generic functions once you have defined an interface.

Into perhaps

In an earlier blog post, I showed how the Go programming language allows you to write generic functions once you have defined an interface.

Considering the audience and author, I would seriously consider omitting the explanation of what Go is, but that's just polish. :)

psychphysic• 3 years ago

There are quite a few little language mistakes that I couldn't figure out if it was a language thing or just a typo.

Of course, it also limits to the tools that I use to program: they cannot much about the type I am going to have in practice within the count function.

I think dropping the 'me' is often a feature of those whose native language is eastern European/Russian. The second (possibly) missing 'know' seems to support just editing mistakes. The structure of both makes me think of Portuguese for some reason!

To avoid going off topic on HN, something... something... ChatGPT

formerly_proven• 3 years ago

I would argue Java interfaces are very different from Go interfaces and C++ concepts, because the former is nominally typed and the latter are structural.

aatd864• 3 years ago

That's something I have been pondering for some time.

I believe it's a false dichotomy.

My thought is still that structural supersedes nominal.

A nominal interface is just another constraint added to the list of constraints of an underlying structural interface?

mjburgess• 3 years ago

Well it depends on a runtime/compile-time distinction. A nominal type is a structural type with a compile-time constraint.

If you have compile-time only constants you can model nominals with structural,

    type Square
        static const IsSquare = true
        
        var length = 10

You can kinda hack-in subtyping,

    type Shape
        static const Shape = true

    type Square
        import static from Shape
        static const IsSquare = true
        
        var length = 10

stefncb3• 3 years ago

In a nominal type system, a method x() is part of the interface X, while in a structural one it's part of the implementor of said interface. In Go there's a Human.HasOrgan(), not an AbstractBody.HasOrgan().

A consequence of this is that in Rust, which has a nominal system, you can implement two traits that contain a method with the same name and are required to disambiguate at the call site. In Go you can't do that, since the method is part of the concrete type.

jcheng• 3 years ago

Nominal interfaces can still be useful though, as they convey a stronger sense of intent than structural. For example, java.io.Serializable is a completely empty interface that classes “implement” to signal that they are safe to serialize. As a structural interface, it’d be useless.

tialaramex3• 3 years ago

In practice C++ Concepts don't do what you're suggesting.

The C++ 20 Standard Library provides numerous concepts which have a very different semantic requirement than the syntax they're checking. If you violate the syntactic requirement of course that'll earn you a compiler error, but if you violate the semantic requirements that's silently an ill-formed C++ program, it has no meaning whatsoever and might do absolutely anything if run.

If these were nominal, we could say, well, nobody should have deliberately implemented this inappropriate Concept, similar to an unsafe Rust trait, the act of implementation is a promise to others. But C++ Concepts aren't nominal and so there was no opportunity to do that and so in practice such deviations are likely very common despite the potentially drastic consequences.

robocat• 3 years ago

Really good video by Conor Hoekstra on the differences between C++ Concepts vs. Haskell Typeclasses vs. Rust Traits vs. Swift Protocols.

https://youtu.be/E-2y1qHQvTg

It is a good intro overview to the subject. Unfortunately the video has far too much filler, so you need to skip a bit e.g. start at 22:30 when the video gets into examples.

planede• 3 years ago

So what are concept good for? I think it is mostly about documenting your code.

Emphasis mine. While it is somewhat good as documentation, sometimes static_assert with a custom diagnostic message is sometimes better for this purpose.

The hidden power of concepts/constraints is the way it shapes overload sets. You can have something like:

  template <forward_range R>
  void foo(R&& r) {
    /* some generic algorithm */
  }

  template <random_access_range R>
  void foo(R&& r) {
    /* optimized for random access */
  }

and it will work if you pass a random access range, as the compiler can deduce that it's more specific than a forward range to resolve the ambiguity. Prior to concepts writing code that did this was way more cumbersome.

gpderetta8• 3 years ago

Indeed. I haven't found concepts to be very good at generating error messages. But they are great for documentation and to get rid of SFINAE hacks for overloading.

The shorter template syntax is a bonus.

edit: concepts should also allow for better IDE tooling, for example proper completion inside template functions; although it is supposed to work, I didn't notice it firing yet in clangd.

pjmlp4• 3 years ago

They are also great for poor man's reflection, you can combine concepts with C++ traits (not the same as Rust's) and constexpr if, to check if the given type supports some specific capabilities.

jcelerier• 3 years ago

In Qt Creator I can see the interface defined by a concept upon autocomplete

pornel• 3 years ago

Rust requires trait bounds (its equivalent of concepts) to type-check the template code at definition site, when it's written, not at the instantiation site where it's used. This results in much better error messages. The downside is that trait bounds for numeric code are awfully verbose, and you can't sneak in a printf without declaring it as a requirement.

shilangyu2• 3 years ago

In Go, I found that using an interface was not free: it can make the code slower.

The Go version that was presented isn't equivalent though. In Go you are accepting an interface directly which will hide the value under some fat pointer for dynamic dispatch, in c++ you are using generics to monomorphise the function to specific types. If you want to compare the implementations fairly you should've used Go generics:

  func Count[T IntIterable](i T) (count int) {

mirashii• 3 years ago

Fair criticism, though I do wonder if it'd really make that much of a difference. Go doesn't really monomorphize generics either, and would end up with an equally if not more expensive lookup for the correct generic function at runtime.

Some reading: https://github.com/golang/proposal/blob/master/design/generi... https://planetscale.com/blog/generics-can-make-your-go-code-...

bheadmaster2• 3 years ago

That's true at the moment, but still an implementation detail. I think I remember early versions of C++ compilers doing the same thing with templates.

Considering the progress Go compiler has gone through, I think it's reasonable to expect the optimized implementations will come few versions down the road.

shilangyu2• 3 years ago

I don't know why I thought Go generics also do monomorphization, must've misremembered or it was an earlier proposal? Thanks for the correction!

signa112• 3 years ago

does this imply that type erasure via base classes will become a thing of past ?

gpderetta8• 3 years ago

In C++20, concepts don't really provide any new semantic feature that wasn't already available before. Just a nicer and cleaner syntax (often considerably so).

signa112• 3 years ago

i see, ok thanks ! so, the concept-model idiom is still (pretty) useful...

olliej• 3 years ago

concepts don't change codegen in any way, they just mean your error messages become actually sane :D

Essentially, in the past you would have your template code, say something dumb like:

    template <typename T> T halve(T t) { return t / 2; }

and if you instantiated with the wrong type, say:

    halve("foo")

you get an error message pointing to the t/2 in the halve implementation. As your templates become less trivial, so do the error messages. So we could apply concepts:

    template <typename T> concept Halvable = requires (T t) { t / 2; };
    template <Halvable T> T halve(T t) { return t / 2; }

Now our call to halve("foo") will complain that const char* is not Halvable. It will also produce an error similar to the original saying that we don't conform to Halvable because the `t / 2` expression fails. In this case it's not super valuable, but if you were instantiating a type or method that was more complicated instead of getting dozens or hundreds of errors in the instantiated body of the template, you just get an early error saying "you aren't conforming to X for these reasons:...".

Unfortunately this does not stop you writing a template that depends on things that your concepts don't guarantee. For example, if we can halve something, we must be able to double it, right? (silly example to demonstrate the issue)

    template <Halvable T> T double_it(T t) { return t * 2; }

Note, Halvable doesn't ensure that * is available, but this template is still "correct".

Now we can do `double_it(1)` and that will work, but `double_it("foo")` will say the error is at the t * 2 in the body, when we probably want the error to actually at the point we try to call double_it.

Preventing this kind of error is non-trivial (possibly actually impossible?) given how concepts are defined. It's literally just a list of statements and expressions that need to be valid for a type. But going from a list of "these statements and expressions are valid" to "is this specific expression or statement valid in a template" is at best nontrivial. This is core limitation of the entire feature.

ratorx• 3 years ago

Arguably, pointing to t/2 (in the second case) is the correct behaviour, because (if concepts are being used), then it is the function (double_it) that is mis-specifying it’s requirements. Even better would be to point at the function definition as well and say that there is nothing in the concept that allows this function.

I think the core problem (don’t know if this is still the case, haven’t actually used concepts) is that templates raise errors at the point of expansion, rather than at the point of definition, because of how they are specified/implemented.

I think it’s possible that the compiler could do something smart by auto-creating a temp type that is the minimal possible implementation of the concept and attempting to compile the function. Any errors that result, should be flagged at the concept specified in the function.

hoseja• 3 years ago

    uint32_t next() { index++; return array[index - 1]; }

I do like

    uint32_t next() { return array[index++]; }

, shame it's kinda unintuitive.

Defining interfaces in C++ with ‘concepts’ (C++20)

Related Stories