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

Allow forward-declaration of level_enum #2245

Merged
merged 1 commit into from
Jan 11, 2022
Merged

Conversation

daverigby
Copy link
Contributor

spdlog::level::level_enum cannot be forward-declared at present, as
the definition does not specify an underlying type.

To allow users to make use of <spdlog/fwd.h> to refer to
level::level_enum without pulling in all of <spdlog/common.h> (which
can be quite costly), specify an underlying type (int) for
level::level_enum, then add a forward-declaration for it to
spdlog/fwd.h.

Note this required explicitly casting level_enum to size_t within ansicolor_sink due to sign-conversion errors:

implicit conversion changes signedness: 'const level::level_enum' to 'std::__1::array::size_type' (aka 'unsigned long') [-Wsign-conversion]

It would appear that an enum with an unspecified underlying type is in
some kind of superposition - it can be treated as both signed and
unsigned - using an underlying type of 'unsigned int' triggers even
more warnings of this kind...

spdlog::level::level_enum cannot be forward-declared at present, as
the definition does not specify an underlying type.

To allow users to make use of <spdlog/fwd.h> to refer to
level::level_enum without pulling in all of <spdlog/common.h> (which
can be quite costly), specify an underlying type (int) for
level::level_enum, then add a forward-declaration for it to
spdlog/fwd.h.

Note this required explicitly casting level_enum to size_t within ansicolor_sink due to sign-conversion errors:

    implicit conversion changes signedness: 'const level::level_enum' to 'std::__1::array::size_type' (aka 'unsigned long') [-Wsign-conversion]

It would appear that an enum with an unspecified underlying type is in
some kind of superposition - it can be treated as both signed _and_
unsigned - using an underlying type of 'unsigned int' triggers even
more warnings of this kind...
@gabime gabime merged commit 4cfdc8c into gabime:v1.x Jan 11, 2022
@gabime
Copy link
Owner

gabime commented Jan 11, 2022

Thanks @daverigby

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