rossbencina / staticmode Goto Github PK

I am trying to work out whether this is a gcc bug or something else. gcc 4.8 - 6.3

Example:
https://godbolt.org/g/YIH3JD

Some unit tests were using this idiom. It compiles fine if the enum is declared at global scope.

I have also asked on SO:

http://stackoverflow.com/questions/42328208/

Right now, each Mode instance provides a value_type operator() to get at the underlying enum value. If the enums being used are bit-masks, it may be useful to fold all of the Mode values together using operator-| to get a runtime value for the mode expression as a whole.

I have no use for this right now. But if someone wants it we could look at implementing it.

Similar to has_mode but takes a type_pack. The idea is to provide a way to check for all required modes at once.

For an empty mode set, should we define an empty type such as staticmode::empty_mode_expr or none or something?

Right now we are using staticmode::ModeSet<> but ModeSet is not used elsewhere in the public API.

Allow for idempotent expressions construction:

solid|solid -> solid
(dotted|solid)|solid -> dotted|solid

This could be a global behavior, or controlled by a trait.

The implementation for Mode|Mode could just use a separate specialization for when the modes match.

The implementation for ModeSet|Mode could use enable_if to select the idempotent version if ModeSet already exactly contains Mode.

Travis is using ancient versions of clang and gcc. Ideally we'd test all significant versions.

I'm not sure whether this is a good idea:

At the moment, each function that takes a mode expression has to specify the default mode that it will use (if any) for each mode category. This is sometimes required (the default mode for a particular category may be different for different functions). Other times, it would be preferable to have a mode-global default. This could be handled automatically with traits (although if we don't have to supply a default to get_mode_t it may be confusing whether this means "required" or "use global default")

Could provide a trait to allow a default mode for a given mode category to be specified at the type level. Specialize this for client modes:

namepspace staticmode {
    default_mode<ModeEnumClass>
    {
        using value_type = no_default_mode;
    }
}

Right now, get_type_t depends on the types of its arguments being correct. The examples/ all use is_mode_expr to verify the input and display an error.

static_assert(staticmode::is_mode_expr<ModeExpr>::value == true,
                "/modes/ argument has unexpected type. Expected a Mode or ModeSet.");

While this is a good place to perform the check from the point of view of the user (e.g. the user will see immediately that the expr passed to the drawLine function is the problem) it would be convenient if this check were also performed by get_mode_t.

Also, there is currently no check that the Default parameter is compatible with the KeyEnumClass parameter.

There are two sub-tasks to this ticket:

In the implementation of get_mode_t:

1. static_assert that the ModeExpr parameter is a mode expression using is_mode_expr
2. static_assert that Default is a Mode and that it is a member of the KeyEnumClass mode category.

In both cases display useful error messages.

First step is to develop tests for these cases.

From older notes:

Rework get_mode/get_mode_t so that it checks its parameters:

• it fails to compile if the passed mode expression is not a mode expression
• if fails to compile if the last parameter is not a mode
• it fails to compile if the last parameter is not the same mode type
  as specified by the first parameter, or the no_default_mode type

Not sure what the best way to run code sanitizers is. Should we just run them with Travis CI or is there a better Git Hub integration that specifically runs multiple sanitizers?

As it stands, get_mode_t has a required third parameter called Default, which specifies the mode to return if the mode expression does not contain a mode of the category KeyEnumClass. examples/required_mode.cpp illustrates how to implement a required mode using a static_assert on has_mode. In such a situation, requiring a default to get_mode_t makes no sense.

Upshot:

The Default parameter to get_mode_t should be optional. If a default mode is not specified, and the supplied mode expression does not have the requested mode, get_mode_t should fail to compile with an error message along the lines of "get_mode_t requires a mode of the requested category because no default has been specified."

With this change, the use of has_mode to check for required modes becomes merely a convenience for error reporting.

As things mature, I would like to add two new pieces of documentation:

An API Guide would walk you through all of the capabilities of StaticMode. Starting with the Mode class and how you can instantiate and use it. It would mention ModeSets and the concept of mode expressions. Then talk about get_mode_t.

An API Reference would be more like the format of cppreference.com. It would describe each public API, it's members and its usage.

This ticket is a placeholder for an idea that may not be necessary to implement. No requirement currently exists.

Add a trait or other mechanism for user specified mode cardinality (right now all modes are 0...1)

Right now each mode appears 0..1 times in a mode set, But could provide some way to express a constraint like 0..k times. where k is specified per mode type.

As an alternative to checking cardinality during expression construction, could do it at the use site.

My current view is that if you want to avoid mutual exclusion, put each mode in a separate category. But I don't have enough experience doing that to know whether it's a good idea.

The talk was given using clang on Linux. It would be nice if all of the talk code also compiled and ran correctly on Windows under MSVC 2015.

Right now, the CI builds compile the examples (and will fail the CI process if there are any issues). But they don't run the examples. Ideally we would:

• Run each example (this is easy to set up by adding the example as a test in CMakeLists.txt using add_test (see CMakeLists.txt in the tests/ directory for an example).
• Verify that the output is as expected (not sure how to do this, can CMake do it?) maybe a python script?)