This PR does the following things:

• uses conan to acquire Catch2 if and only if the nameof lib is build using the build_test option
• uses Appveyor and travis to make sure that the nameof library is usable on certain configuration and all the tests pass and the example builds
• it will upload the package (recipe, nameof.hpp and the generated nameofConfig,cmake ... files) to bintray with the version specified in the conanfile.py.

Note that

The CI services can run any time you push a commit, it won't upload any versions to bintray, only if you create a new tag (with any name pattern) like v0.9.1 It won't upload any built binaries (neither tests, nor example), but it will upload the sources of the tests and example, since a consumer may want to build it himself.

Our nightly static code analysis build with VS 2017 15.9.4 reported this warning:

Severity	Code	Description	Line	File	Project	Suppression State
Warning	C26495	Variable 'nameof::cstring<14>::chars' is uninitialized. Always initialize a member variable (type.6).	92	c:\users\hutchinsons\source\dart\ng-dart\source\vs2012\ng-dart base\nameof.hpp	NG-DART	Active

I attempted to fix it by changing const std::array<char, N + 1> chars; to const std::array<char, N + 1> chars{ {} };, but that did not help.

Any idea how to fix this? Thanks

For the following template class:

template <typename T>
class SomeClass {};

msvc and gcc returns different results for the following expression:

nameof::nameof_type<SomeClass<int>>()

msvc returns class SomeClass<int> unlike gcc which returns just SomeClass<int>.

Should it be in this way?

There are several questions to the structure of your CMakeLists.txt.

1. Why branch on this? CMakeLists.txt:7-11 link there

if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
    set(IS_TOPLEVEL_PROJECT TRUE)
else()
    set(IS_TOPLEVEL_PROJECT FALSE)
endif()

2. Why do you try to specify the standard by hand? example/CMakeLists.txt link there You could use generator expressions which are well described in this blogpost. This would be more readable I think.

include(CheckCXXCompilerFlag)

if((CMAKE_CXX_COMPILER_ID MATCHES "GNU") OR (CMAKE_CXX_COMPILER_ID MATCHES "Clang"))
    check_cxx_compiler_flag(-std=c++17 HAS_CPP17_FLAG)
    if(!HAS_CPP17_FLAG)
        MESSAGE(FATAL_ERROR "The compiler ${CMAKE_CXX_COMPILER} has no C++17 support.")
    endif()

    set(CMAKE_VERBOSE_MAKEFILE ON)
    set(OPTIONS -Wall -Wextra -pedantic-errors -Werror -std=c++17)
elseif(CMAKE_CXX_COMPILER_ID MATCHES "MSVC")
    check_cxx_compiler_flag(/std:c++17 HAS_CPP17_FLAG)
# more ...

3. At the same CMakeLists.txt you should depend on the nameof target, instead of just simply including the nameof header. link there

add_executable(example
                    example.cpp
                    ${CMAKE_SOURCE_DIR}/include/${CMAKE_PROJECT_NAME}.hpp)

4. Is it a bad practice to bake in the projects name? I think that would be more readable than using the ${CMAKE_PROJECT_NAME}. (It's only a question.)

5. What is going on in test/CMakeLists.txt I don't really get it. Like creating two test binaries, but why? I think it should be simplified. It also suffers from the problem which I described at the second bullet-point. link there

if(HAS_CPP17_FLAG)
    make_test(${CMAKE_PROJECT_NAME}-cpp17.t c++17)
endif()

if(HAS_CPPLATEST_FLAG)
    make_test(${CMAKE_PROJECT_NAME}-cpplatest.t c++latest)
endif()

I see that there's an operator std::string_view; could you add an operator std::string? Functions that take a std::string require an explicit cast to pass in.

Example:

void foo(const std::string &asdf) {}
void bar()
{
	const char *foo1;
	foo(NAMEOF(foo1));  // error: no suitable user-defined conversion from "nameof::cstring<4UL>" to "const std::string" exists
	foo(NAMEOF(foo1).data()); // ok
	foo(std::string(NAMEOF(foo1))); // ok
}

This is compiling using MSVC's CL version 19.00.24234.1

I did not find your email address, so I write to you here.

I created a Conan recipe for your package. You can find it here: https://github.com/steakhal/conan-nameof

If you are no familiar with Conan, you can find more about it here: https://conan.io/ tldr. it is a package manager for c++

We can merge the recipe into your repository if you want to.

Hi guys. Today Micorsoft release VS2022 17.2, then the nameof is not happy with "Error C2338: static_assert failed: 'nameof::nameof_enum requires enum implementation and valid max and min.'" The code is in 897 line: static_assert(detail::count_v<D> > 0, "nameof::nameof_enum requires enum implementation and valid max and min.");

Until C++20, MSVC doesn't supply the member name from member pointer in __FUNCSIG__.

https://godbolt.org/z/nbGMMjrTf

With this technique, from the member pointer can be extract the member name.

Will try to find the code that triggers this when I have time. ...\nameof.hpp (579, 0) ...\nameof.hpp(579,0): Warning C28020: The expression '0<=Param(1)&&Param(1)<=1-1' is not true at this call.

Hi, I finally got around to updating nameof in my project to test the fix of #46 by @schaumb. Unfortunately, it doesn't work when TestStruct has a member with a non-constexpr user-provided constructor. Is it possible to fix it? I looked into the source, but I don't understand the union trick used in the member_name_v implementation for MSVC, so I can't tell if it can be fixed.

As previously, the following code doesn't compile on MSVC (2022) using the latest master of nameof, but works fine with clang and gcc

struct Foo{
    ~Foo(){};
};

struct TestStruct{
    std::string teststringfield = std::string{nameof::nameof_member<&TestStruct::teststringfield>()};
    Foo foo;
};

This is more a feature request/idea than issue. But it would be possibly more useful if NAMEOF_ENUM could fallback to using NAMEOF_TYPE with the literal underlying value something like this example.

enum Colour { Red, Green, Blue = 0xFFFFFFFF };

Blue would be definitely out of range. So instead of Blue you would get Colour[4294967295] or in hex Colour[0xFFFFFFFF]

This seems useful in providing partial support for enums with large ranges.

struct A{};
class B{};
enum C{};
template<typename T>
class D{};
constexpr auto name_A = nameof::nameof_type<A>(); // "struct A"
constexpr auto name_B = nameof::nameof_type<B>(); // "class B"
constexpr auto name_C = nameof::nameof_type<C>(); // "enum C"
constexpr auto name_D_A = nameof::nameof_type<D<A>>(); // "class D<struct A>"

but I want

• name_A == "A"
• name_B == "B"
• name_C == "C"
• name_D_A == D<A>

Is it possible to get them in compile-time?