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

51–60 of 83 posts

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

#51

Post by MichaelSalib »

mattnewport wrote: post #49
MichaelSalib wrote: post #48

Earlier quoted context omitted.

To clarify: of course they like simplicity when it costs nothing. But they consistently value other goods over simplicity. For example: maintaining backwards compatibility. The community believes that it is more important that 20 year old C++ code run unmodified than that the language should be simplified. There's lots of stuff you could do to simplify the language but options dry up in a world where 20 year old code…

Two other goals for C++ are 'zero-cost abstractions' and 'leaving no room for a lower level language'. It does better on both of these goals than Common Lisp and they are important reasons for its popularity (along with backwards compatibility and easy interop with C APIs).

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.

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

#52

Post by mattnewport »

MichaelSalib wrote: post #51
mattnewport wrote: post #49

Earlier quoted context omitted.

Two other goals for C++ are 'zero-cost abstractions' and 'leaving no room for a lower level language'. It does better on both of these goals than Common Lisp and they are important reasons for its popularity (along with backwards compatibility and easy interop with C APIs).

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.

Lots of things come with tradeoffs but relative to a certain set of goals and priorities there are design decisions that are net better than others. Not everything is a zero sum game.

In this context 'zero-cost abstractions' refers to zero runtime performance cost and C++ comes closer to achieving that than most other languages. It doesn't mean zero compile time cost or zero implementation complexity cost but both of those things can end up better or worse due to design decisions and quality of implementation. Given that zero cost refers to runtime performance however, the committee is not 'pretending' they have zero cost abstractions.

It is true that simplicity and comprehensibility are not C++'s highest goals / values but they are not ignored or seen as having no value. Indeed they are major topics of discussion when new features are being considered. Sometimes they are in tension with or even in direct conflict with other goals but not always.

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

#53

Post by nealabq »

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…

> fit a bunch of ugly angels on a pointless pin. It just feels so pointless.

A pointless pin would indeed be pointless.

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

#54

Post by mattnewport »

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…

I don't think anyone on the C++ committee is proposing banning you from generating C++ code with Python. I also doubt anyone who's interested in C++ metaprogramming has failed to consider the possibility of doing codegen via other means. In light of these facts what seems rather pointless is your comment.

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

#55

Post by gumby »

MichaelSalib wrote: post #48
gumby wrote: post #41

Earlier quoted context omitted.

>... the C++ community doesn't take language simplicity or comprehensibility seriously... I think this is an unreasonable assertion and not borne our by a read of the committee discussions.

To clarify: of course they like simplicity when it costs nothing. But they consistently value other goods over simplicity. For example: maintaining backwards compatibility. The community believes that it is more important that 20 year old C++ code run unmodified than that the language should be simplified. There's lots of stuff you could do to simplify the language but options dry up in a world where 20 year old code…

> For example: maintaining backwards compatibility. The community believes that it is more important that 20 year old C++ code run unmodified than that the language should be simplified. There's lots of stuff you could do to simplify the language but options dry up in a world where 20 year old code must be able to run unmodified.

This pains me but every time I think "just toss XXX out, gddammit!" I think of IPv6. C++11 is still the most popular dialect of C++, even for new development I believe, and c++14 is the hot new thing to many people.

> Don't get me wrong: I'm glad that finally, in 2020, C++ will be almost but not quite as good as Common Lisp was at metaprogramming back in 1982. But it remains the case that eval-when and defmacro are both more powerful and dramatically simpler than anything the C++ committee has ever considered.

C++ is held back by having statements. If the basic structure were an expression a lot of programming, much less metaprogramming, would be simpler.

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

#56

Post by choeger »

gumby wrote: post #43
choeger wrote: post #20

Oh my. If only C++ would have used proper macros from the start...

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.

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

#57

Post by choeger »

adev_ wrote: post #39
choeger wrote: post #20

Oh my. If only C++ would have used proper macros from the start...

There is nothing as "a proper macro". There is proper meta-programming support or a badly design language.

A macro is a metal-level abstraction. So proper macros require proper metaprogramming support. And, I would argue, the other way around.

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

#58

Post by steveklabnik »

MichaelSalib wrote: post #51
mattnewport wrote: post #49

Earlier quoted context omitted.

Two other goals for C++ are 'zero-cost abstractions' and 'leaving no room for a lower level language'. It does better on both of these goals than Common Lisp and they are important reasons for its popularity (along with backwards compatibility and easy interop with C APIs).

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

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

#59

Post by gHosts »

roywiggins wrote: post #2

"a somewhat more awkward and uglier, yet slightly more correct way... all the functionality is right there. We’re not missing anything" might as well be C++'s motto :)

Yup.

And while the rest of the world knew how to find a file size... how long was it before C++ cleaned that very very simple corner up?

And if you look under the hood at the implementation of std::conditional.... I feel ill.

The thing I like about Alexandrescu is he invented this meta programming stuff... super super super clever magic...

...and then backed away saying it shouldn't have to be so hard, we shouldn't need magic to program.

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

#60

Post by pjmlp »

p0nce wrote: post #26
dasloop wrote: post #16

Earlier quoted context omitted.

Probably because you are used to the paralysed C++ pre C++11. Nothing happens for years and now we have new functionalities every three years supported by all major compilers. But, also, many new functionalities are not for global consumption. The audience of many meta programming functionalities are library developers for example.

And that's exactly what's different in D, where the audience for meta-programming is "everyone". It's not just about more power, but how accessible this power is. To think you need to suffer to have this power is not true.

On the other hand, templates get abused on D as workaround to avoid writing attribute boilerplate across all functions definitions.
Post reply on HN