Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add macro to ease creating tagged bools #2

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

mlimber
Copy link

@mlimber mlimber commented May 25, 2017

This pull request adds a macro to eliminate boilerplate code when defining a tagged bool. At present, one has to do this to create some tagged_bools:

class is_ready_tag {};
using is_ready = ak_toolkit::xplicit::tagged_bool< is_ready_tag >;
class has_signaled_tag {};
using is_ready = ak_toolkit::xplicit::tagged_bool< has_signaled_tag >;

Or:

using is_ready = ak_toolkit::xplicit::tagged_bool< class is_ready_tag >;
using is_ready = ak_toolkit::xplicit::tagged_bool< class has_signaled_tag >;

With this change, the macro handles the boilerplate:

AKT_MAKE_TAGGED_BOOL( is_ready );
AKT_MAKE_TAGGED_BOOL( has_signaled );

@mlimber mlimber closed this May 25, 2017
@mlimber mlimber reopened this May 25, 2017
@mlimber
Copy link
Author

mlimber commented May 25, 2017

I waffled a bit on this, sorry. The two alternatives are my penultimate commit:

#define AKT_MAKE_TAGGED_BOOL( Name )                                   \
    class Name##ExplicitBoolTag { Name##ExplicitBoolTag() = delete; }; \
    using Name = ::ak_toolkit::xplicit::tagged_bool< Name##ExplicitBoolTag >

and my latest commit (using forward decl only):

#define AKT_MAKE_TAGGED_BOOL( Name ) \
    using Name = ::ak_toolkit::xplicit::tagged_bool< class Name##ExplicitBoolTag >

The difference is whether one can re-use existing class names as tags. The former says no, the latter says yes. I don't see a strong use case for such re-use, and it probably violates the single responsibility principle by making a functional class do double duty as a tag.

@viboes
Copy link

viboes commented May 25, 2017

I find

using is_ready = ak_toolkit::xplicit::tagged_bool< class is_ready_tag >;

quite simple, and even if the DRY principle is not respected completely I fill this kind of macros make the code more obscure.

@mlimber
Copy link
Author

mlimber commented May 25, 2017

Right: it's a trade-off, and totally optional. You can choose either to repeat yourself (boilerplate + tag name which is usually just name_tag), or you can use the slightly more obscured macro which gives less repetition, better adherence to the single responsibility principle, and (if the penultimate version above is used) slightly safer alternative since the tags can't be accidentally created and used.

Programmer's choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants