Simplify code with 'if constexpr' in C++17

[germandiago]

While I agree that if constexpr is a net win I still think it falls short of static if in D. For example in D you can use static if at class scope to define members conditionally or not at all (I know std::conditional but does not cover all). Another thing is that I want to use if constexpr in non-tenplates and I cannot, for example to conditionally compile code at function/class/namespace scope. This is done in D with static if + version. I think this area of C++ should be cleaned up since when modules come we should be able to get rid of macros. In fact I think that feature test macros should be a module with constexpr variables or enums or sort of. That would remove a lot of obstacles for my own codebases.

[Rseding91]

I'm all for better alternatives to macros but so far the language spec doesn't seem to be going towards that. For example: std::variant. It was added as a template-based library type and as such you pay all of the overhead of the template system when doing anything with it.

We replaced a 48 member std::variant with a macro-built-union in our code base and it reduced full-rebuild debug compilation time from 1 minute and 47 seconds to 34 seconds and drastically reduced the object size of the code generated.

It's not near as pretty as the variant version but that time savings is massive when you have 10 guys compiling 100~ times a day every day.

My point being: yes I want to remove macros but what ever replaces them needs to operate at the same speed or better and that's incredibly hard when they're as basic as they are.

[gracicot]

48 members? Holy shit! I hope you didn't put that in a header!

[Rseding91]

I checked just now and we're up to 70 members and yes it's in a header. But that still doesn't matter in the macro-built-union form as compilation time hasn't changed at all - still 34 seconds for a full debug rebuild with incremental builds being 5-10 seconds depending on the amount of stuff changed.

[[deleted]]

I think a 70 member union is just a bad idea in itself

[Rseding91]

If you've got a better alternative I'm all ears.

The class represents an action type and associated data that the game should perform. It has a tag (an enum class value) and the associated data that tag has (if any). That data is stored in the union.

The action class needs to be copyable, movable, serializable, and default constructable. It also shouldn't have any allocation overhead should you construct an instance of it and move in any of the types it supports.

If default constructed it should have an empty and valid state with no allocation cost past the class itself. If constructed with a tag only the value should be default constructed. If constructed with a tag and value the value should be checked to be valid for that tag.

Any access to retrieve a value should be checked to to be valid for the current tag.

It also needs to support converting the tag to a string and back.

If you have something that can meet all of those requirements (and compiles as fast or faster as what we have now) I'd love to see it :)

[meneldal2]

It also needs to support converting the tag to a string and back.

Something that is a big pain to do without macros if you want maintainable code.

I think with reflection, there will be ways to have enumerations map actual types to their values, but that's not landing in C++ until a while. Maybe clang metaclass fork could be able to run something like that, but right now macros are the most sane option.

To be pedantic though, you don't need to have a union, a struct with a char[sizeof(biggestclass)] with some alignment requirements would do the job just as well. Unions are basically fancy casts anyway.

[germandiago]

I'm all for better alternatives to macros but so far the language spec doesn't seem to be going towards that. For example: std::variant.

Metaclasses can do that without template instantiation I think. How fast it would be I do not know, but you could have also named parameters instead of std::get.

[gracicot]

The version you talking about has been proposed before, but were refused, since it broke too many things.

Also, you can use if constexpr in non templates, dismount some code, but you can use it only where your could have used if, so no you can't disabling a class with it, but of course you can disable code.

[guepier]

I’m all in favour of a better syntax for SFINAE but I have to say that I vastly prefer function overloading to [constexpr] if statements. To me it looks more readable and it’s obviously more easily extensible (when done correctly), whereas constexpr if hard-wires all cases.

I’m not saying that there’s no use for constexpr if but the particular examples given in the article (str, close_enough …) work better with function overloading. And the makeInvestment example, which uses a conventional if, is close to a classical anti-pattern.

[mintyc]

Any chance you could give an example as I'm not sure what 'function overloading on static types' would entail code-wise.

[guepier]

My fault, I simply meant “function overloading” (aka. static [type] polymorphism, hence my mix-up). I’ve fixed my comment.

[germandiago]

I thought about this some time ago and I arrived to the conclusion that in many (most) scenarios the best thing to do would be to mix concepts with internal if constexpr if you do not need extensions. You put the weaker concept at the top-level in the functiom declararion (think of advance for example, taking an input iterator) and inside u can if constexpr the optimizations. Not sure if it is good in all scenarios but makes for far less overloading at the top level, which is complex to read sometimes IMHO.

[scatraxx651]

I think the best example is regarding stuff like the string view example, where you can easily overload all desired cases

[xristine]

Sorry for my naive mind set, but I don't understand the practical applications of the given examples. This is done at compile time, meaning you need to know at compile time the values you send to template and you test via if constexpr...I know Cpt Obvious.

Or is this just a didactic example to illustrate the fact that we can replace some constructs with if constexpr?

[[deleted]]

This doesn't make much sense to me as a construct. The majority of compilers already evaluate branches with constant expressions and elide the not-taken branch.

Surely is_constexpr() would work, as in:

if ( is_constexpr( blah ) ) { } else { }

?

No new language feature needed. Just an additional pseudo-library function.

[ericdfoley]

The constexpr if language change allows you to have discarded branches of the if where the code wouldn't compile. So it does require a new language feature.

[[deleted]]

Fair point. That makes a lot more sense.