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

C++ : if constexpr isn't broken

brevzin.github.io

Post reply on HN
Print view View original

61–70 of 83 posts

Re: C++ : if constexpr isn't broken

#61

Post by pjmlp »

strmpnk wrote: post #46
steveklabnik wrote: post #36

Earlier quoted context omitted.

I think C# is a good language, but I also am not sure that it's a poster child for this particular language feature. (I mean this literally; I don’t have enough experience to really know how it compares to the usual suspects in this area.)

.NET's and thus C#'s generics are very well designed but they rely on the design of .NET as a whole being a managed language, so it can get away with a slightly more sophisticated runtime representation. An example of this is that generics are "reified". This is to say that you can treat each instantiation as a unique type at runtime. This is not the same as monomorphisation though, as there are rules used to promote…

.NET also does monomorphisation when doing AOT compilation to native code, on .NET Native or Xamarin for iOS for example.

Re: C++ : if constexpr isn't broken

#62

Post by Rusky »

mattnewport wrote: post #44
steveklabnik wrote: post #36

Earlier quoted context omitted.

I think C# is a good language, but I also am not sure that it's a poster child for this particular language feature. (I mean this literally; I don’t have enough experience to really know how it compares to the usual suspects in this area.)

A bit of a test case for me, coming from the domain of games / 3D graphics programming, as to whether a language has a 'sufficiently powerful' generics feature set is whether it is possible to implement a generic 'short vector' type as used in any type of graphics programming. I think 'good' generics / metaprogramming support should let you meet most of these goals in a generic 'short vector' type: - Support 'n' dime…

None of these require C++'s gradual typing- the only real reason C# can't meet them is that it lacks value parameters to generics, and perhaps some limitations to its value types.

Re: C++ : if constexpr isn't broken

#63

Post by inetknght »

adrianN wrote: post #33
inetknght wrote: post #28

Earlier quoted context omitted.

Nothing stops "everyone" from using the features which suit library developers.

Except ever increasing time to learn all the language features and associated best practices.

While true on the face of it: I haven't had the need to learn many other languages so I haven't had the need to learn the best practices of them.

Use what you need, learn what you need. Don't pay for what you don't use :)

Re: C++ : if constexpr isn't broken

#64

Post by gumby »

choeger wrote: post #56
gumby wrote: post #43

Earlier quoted context omitted.

I discussed this once with Stroustrup. He mourned that the word "macro" had been "polluted" (his word, though I completely agreed) by the preprocessor and said "templates was the best we could do within the constraints of C". This was in the mid 90s and things are a lot better these days but still, I had better macro support writing Lisp in the 1970s.

I am ready to believe that hygienic macros would have been difficult, but just using lisp macros should have been straightforward. Tbh, I think that templates were an adhoc, amateurish design decision.

A lot of the arcanity in templates is the arcane C syntax they are shackled to. I wouldn’t call it ad HPC.

Lisp is so much easier. But current C++ is surprisingly expressive and generates pretty good production code. Instrumenting your Lisp with a lot of type declaration is pretty messy too.

Re: C++ : if constexpr isn't broken

#65

Post by mattnewport »

Rusky wrote: post #62
mattnewport wrote: post #44

Earlier quoted context omitted.

A bit of a test case for me, coming from the domain of games / 3D graphics programming, as to whether a language has a 'sufficiently powerful' generics feature set is whether it is possible to implement a generic 'short vector' type as used in any type of graphics programming. I think 'good' generics / metaprogramming support should let you meet most of these goals in a generic 'short vector' type: - Support 'n' dime…

None of these require C++'s gradual typing- the only real reason C# can't meet them is that it lacks value parameters to generics, and perhaps some limitations to its value types.

This comment wasn't about gradual typing, it was about power / generality of generics / metaprogramming support. C# fails at this in more ways than lacking value parameters and having limitations on value types.

There is no efficient and syntactically pleasant way to work with numeric types generically for example (I can't write 'a + b' and have it work for any types that provide operator+). That doesn't require C++ compile time duck typing (you could mandate something like C++ Concepts to specify a numeric interface, I believe this is sort of what Haskell typeclasses do) but it's easy, efficient and syntactically pleasant to do in C++.

The limitations of C# generics bite it in other ways too - the members of Enumerable are useful and the syntax is ok (not as nice as F# or C++ Ranges) but C# can't match the performance of C++ Ranges given the way they are implemented. They also get bitten by the operator problem - look at how Enumerable.Sum() has implementations for every built in numeric type and doesn't out of the box support your custom Numeric type.

Re: C++ : if constexpr isn't broken

#66

Post by strmpnk »

pjmlp wrote: post #61
strmpnk wrote: post #46

Earlier quoted context omitted.

.NET's and thus C#'s generics are very well designed but they rely on the design of .NET as a whole being a managed language, so it can get away with a slightly more sophisticated runtime representation. An example of this is that generics are "reified". This is to say that you can treat each instantiation as a unique type at runtime. This is not the same as monomorphisation though, as there are rules used to promote…

.NET also does monomorphisation when doing AOT compilation to native code, on .NET Native or Xamarin for iOS for example.

Interesting. I've been meaning to look into the AOT compilation strategies at some point. I'll have to do some comparisons with the code I'm working with.

Re: C++ : if constexpr isn't broken

#67

Post by MichaelSalib »

steveklabnik wrote: post #58
MichaelSalib wrote: post #51

Earlier quoted context omitted.

Zero-cost abstractions only exist in a world where you don't highly value language simplicity and comprehensibility. Simplicity and comprehensibility were things the committee had to give up in order to pretend they had "zero-cost" abstractions. Nothing in life comes free: everything, including all abstractions, comes at some cost.

> Nothing in life comes free: everything, including all abstractions, comes at some cost. Yes. As a slogan, it is imprecise. But it's always been talking about a very specific kind of cost: runtime costs. You're 100% right about there always being some kind of cost, but the slogan doesn't disagree with you. (Some prefer "zero-overhead principle" instead to make this a bit more clear.)

(1) I love your writing.

(2) Even reducing it to runtime costs, it seems a bit nonsensical. Are C++ exceptions a zero cost abstraction? All the googlers I argued with about them would insist that they have unacceptably high runtime costs.

OK, but templates are surely zero (runtime) cost abstractions, right? Unless you start to worry about duplicate code blowing out your instruction cache but if that's a problem, no profiler in the world will ever be able to tell you, so I guess you'll never know just how costly the abstraction is, so you might as well continue believing it is zero...?

Re: C++ : if constexpr isn't broken

#68

Post by mattnewport »

MichaelSalib wrote: post #67
steveklabnik wrote: post #58

Earlier quoted context omitted.

> Nothing in life comes free: everything, including all abstractions, comes at some cost. Yes. As a slogan, it is imprecise. But it's always been talking about a very specific kind of cost: runtime costs. You're 100% right about there always being some kind of cost, but the slogan doesn't disagree with you. (Some prefer "zero-overhead principle" instead to make this a bit more clear.)

(1) I love your writing. (2) Even reducing it to runtime costs, it seems a bit nonsensical. Are C++ exceptions a zero cost abstraction? All the googlers I argued with about them would insist that they have unacceptably high runtime costs. OK, but templates are surely zero (runtime) cost abstractions, right? Unless you start to worry about duplicate code blowing out your instruction cache but if that's a problem, no p…

Zero cost abstraction is not the same thing as a free lunch. It's a goal that using the abstraction will have no runtime cost relative to implementing the same or equivalent functionality manually. It goes hand in hand in C++ with the "don't pay for what you don't use" principle (again talking about runtime performance cost).

When it comes to exceptions, it's generally true on x64 that you don't pay for what you don't use (there's no performance penalty to exception handling if you don't throw) although that hasn't always been true for all platforms and implementations. It's also generally true that you couldn't implement that kind of non local flow control more efficiently yourself, although the value of that guarantee is a little questionable with exception handling.

I'd argue that no language has a really good story for error handling. It's kind of tragic that we have yet to find a good way to deal with errors as an industry IMO. The most promising possible direction I've seen is in some of the possible future extensions to C++ - it's widely recognized as an area for improvement.

Template code bloat is another case of not imposing more cost than if you implemented it yourself and you have pretty good mechanisms in C++ for managing the tradeoffs.

Re: C++ : if constexpr isn't broken

#69

Post by Rusky »

mattnewport wrote: post #65
Rusky wrote: post #62

Earlier quoted context omitted.

None of these require C++'s gradual typing- the only real reason C# can't meet them is that it lacks value parameters to generics, and perhaps some limitations to its value types.

This comment wasn't about gradual typing, it was about power / generality of generics / metaprogramming support. C# fails at this in more ways than lacking value parameters and having limitations on value types. There is no efficient and syntactically pleasant way to work with numeric types generically for example (I can't write 'a + b' and have it work for any types that provide operator+). That doesn't require C++…

Fair enough, typeclasses/traits were what I had in mind here. You're right that C# doesn't have a common interface to constrain your generics with for operator+/etc.

Re: C++ : if constexpr isn't broken

#70

Post by flukus »

JabavuAdams wrote: post #50

I used to be a C++ guy from the early 90s 'till about 2010. Every few months, I think "I should really learn the new C++ hotness", and then I read something like this. It's like a bunch of priests arguing about how best to fit a bunch of ugly angels on a pointless pin. It just feels so pointless. If you must use C++, just use another language to generate the C++. All this template mumbo jumbo. Who says your meta-prog…

> Who says your meta-programming language has to be the same as your target language?

I'd lay blame at IDE's and they way the take over the build system along with intellisense. They don't play well with anything generated before the compile step. Even adding a build step is and alien concept to many, so we end up with the build step shoe horned into languages.

Post reply on HN