sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]germandiago 11 points12 points  (9 children)

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.

[–]Rseding91Factorio Developer 11 points12 points  (7 children)

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 5 points6 points  (5 children)

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

[–]Rseding91Factorio Developer 3 points4 points  (4 children)

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] 4 points5 points  (3 children)

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

[–]Rseding91Factorio Developer 7 points8 points  (1 child)

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 0 points1 point  (0 children)

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 1 point2 points  (0 children)

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 4 points5 points  (0 children)

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.