Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lemire.me

Post reply on HN
Print view View original

51–60 of 77 posts

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

#51

Post by shilangyu »

mirashii wrote: post #30
shilangyu wrote: post #28

> 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:…

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-...

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!

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

#52

Post by pjmlp »

gpderetta wrote: post #26
planede wrote: post #25

> 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 void foo(R&& r) { /* some generic algorithm */ } template void foo(R&…

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.

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.

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

#53

Post by pjmlp »

perfmode wrote: post #9
travisd wrote: post #4

Earlier quoted context omitted.

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).

it’s actually to keep compile times fast and for the implementation of the compiler to remain simple

The first one is doable in more complex languages, e.g. D, Ada, Delphi,...

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

#54

Post by pjmlp »

Maken wrote: post #41
otabdeveloper4 wrote: post #16

Earlier quoted context omitted.

Yeah, I agree, let's just rewrite all our system software in Javascript. Much better. (Well, except for your Javascript interpreter, that will still be written in C++, obviously.)

Why using an interpreter? Just go down the FJCVTZS route and make the CPU accept Javascript/WASM as assembly code at this point.

It is only a matter of implementing it on a FPGA actually.

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

#55

Post by pjmlp »

pornel wrote: post #48
pjmlp wrote: post #38

Earlier quoted context omitted.

Just wait until Rust gets 40 years old. Pity I won't be no longer around to check on it, given average human life expectancy.

I can't wait for C++64. But "just wait until Rust will repeat C++'s mistakes" is just pure speculation. Language evolution doesn't have to make the language worse. Java, JS, C#, or Ada are pretty old now, and have been doing fine. Rust is well prepared for a 40-year lifespan with its edition system.

You quite clearly are unware of the evolution pain points to move past Java 8, .NET Framework 4.8, and how the Java community embraces Java 20, or the C# one sees C# 12, and the rate they are adding new features.

As for JS, everyone knows the mess of the Web ecosystem and frontend development.

Ada is doing just fine, as most vendors are still adopting Ada 2012. Ada Core and PTC are the only ones with the latest version, from 7 remaining vendors.

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

#56

Post by gpderetta »

tialaramex wrote: post #50
gpderetta wrote: post #32

Earlier quoted context omitted.

I have been programming in C++ for almost 20 years [1] and I don't remember ever being bitten by accidental concept conformance. So I object to the "likely very common" description. Implicit conformance was very much an explicit design goal. [1] yes, concepts as an explicit language feature are new, but C++ has had de-facto concepts since Stepanov work on the original STL in the 90s.

Since I know better than to suggests C++ programmers might be more capable of making mistakes than they realise, lets try a different question: How do you spot this mistake when reviewing other people's code? Do you memorise a list of all the semantic requirements of each concept so that you can mentally check that the concept's requirements are satisfied appropriately by what was written each time ?

I expect other people to write tests (including compile time tests).

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

#57

Post by tialaramex »

pjmlp wrote: post #47
tialaramex wrote: post #46

Earlier quoted context omitted.

It's true, improvements to Rust ship on a six week cycle, the next will be Rust 1.69. Nice. I was inspired to improve a compiler diagnostic earlier this year†, I benefit from that improvement already in the stable compiler today. Whereas if you "miss the train" with standard C++ you've got three years to wait each time, and of course the Powers That Be can ensure that oops, you just missed the train again... Of cours…

Again, wait until Rust gets 40 years of history deployments, distributed from the tiny 8 CPU, to HPC workloads and FPGAs, or stuff running on Mars. I doubt very much that Rust editions and backwards compatibility history will be able to survive 40 years with such diverse use cases, without introducing accidental complexity and corner cases along the way. This assuming that we can still use Rust and not Crab , as if R…

Rust is not designed for 8-bit CPUs like Tiny8. The smallest usize is allowed to be is 16 bits.

In practice on these very tiny devices high level languages are total overkill. Grace's original "compiler" concept makes sense, but today's assemblers are more than sufficiently capable. You can literally memorise what all the individual memory locations (actually Tiny8 just admits they're registers, it's not as if it would make sense to also have registers when you only have 256 bytes of RAM) are used for which means even the idea of variable names is of doubtful value.

I don't know if it's practical to write a conforming C++ "freestanding" compiler for Tiny8, but I can't imagine it'd be any more useful than Rust would be if you did.

The reason there isn't stuff on Mars running Rust is mostly that it takes a long time both to get stuff approved for that kind of application and to send things to Mars. Still I'm sure in 40 years there will have been Rust on Mars because why not and I doubt it'll have significant impact on Rust syntax.

There already are inelegant decisions which cannot (for compatibility) be revoked, but they're much less numerous and egregious at this point in Rust's life than similar problems were in standard C++. If you want one to point at, for some reason, I suggest comparing ASCII predicates like char::is_ascii_lowercase(&self) -> bool with the non-ASCII ones like char::is_lowercase(self) -> bool

Because char is Copy, the latter design would be more elegant, and allows e.g. "C++".contains(char::is_uppercase) which is true, whereas the ASCII variant means we need the more awkward looking "C++".contains(|c: char| c.is_ascii_uppercase()) going via a lambda but alas the way we got here didn't allow that to happen.

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

#58

Post by bheadmaster »

rep_movsd wrote: post #44
bheadmaster wrote: post #43

Earlier quoted context omitted.

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.

C++ templates have never used runtime dispatch

I assume you've checked the version control history of every C++ compiler in existence?

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

#59

Post by seanhunter »

bheadmaster wrote: post #58
rep_movsd wrote: post #44

Earlier quoted context omitted.

C++ templates have never used runtime dispatch

I assume you've checked the version control history of every C++ compiler in existence?

Not the OP, however I have programmed in C++ since 1987 across many different operating systems and hardware platforms and I've literally never heard of a compiler that implements template stuff using runtime dispatch. CFront3 which was I think the first real template implementation that most people used certainly never did it that way, neither did any version of gcc, visual studio or Sun Workshop, which are the compliers I used the most from that period. Dug out my old copy of Coplien[1] which is from the early 90s and it discusses runtime dispatch in depth in the context of vtables and virtual function pointers and the cost of these things, so the concept was well understood but not a cost anyone was paying with templates.

[1] https://archive.org/details/advancedcbsprogr00copl "Advanced C++ Programming Styles and Idioms" aka the first programming book that genuinely kicked my ass when I first read it and made me realise how good it was possible to be at computer science.

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

#60

Post by tialaramex »

gpderetta wrote: post #56
tialaramex wrote: post #50

Earlier quoted context omitted.

Since I know better than to suggests C++ programmers might be more capable of making mistakes than they realise, lets try a different question: How do you spot this mistake when reviewing other people's code? Do you memorise a list of all the semantic requirements of each concept so that you can mentally check that the concept's requirements are satisfied appropriately by what was written each time ?

I expect other people to write tests (including compile time tests).

If you were worried about behavioural problems, including UB, tests would help.

But alas the problem here is IFNDR [Ill-formed No Diagnostic Required] so the compiler can't help you. All semantic constraints are your problem as the programmer, C++ decided that it's not the compiler's concern whether the program meets semantic constraints. Testing doesn't necessarily help at all, which is probably surprising.

Post reply on HN