Doesn't compile under clang 8. about cparse HOT 8 CLOSED

@mikepurvis these are good suggestions. I admit I have never used CMake on my own projects and I always felt that projects that use it are a little bit more complicated to use than with make, but this is from someone that never really learned to use CMake, I will search a little bit and see if I change my mind.

I will make this change on Travis, thanks for the suggestion.

If you have any other problems just tell me =].

from cparse.

Got it, I will take a look and try to fix it.

from cparse.

I'm assuming that gcc is making these test assertions work by promoting the long up to an int64_t, and then coercing that to a packToken using this constructor:

To be honest, that does seem like a bit of a stretch, so I'm not shocked that clang doesn't care for it. The problem goes away if you explicitly grab the int value out of the variant, eg:

    REQUIRE_NOTHROW(c1.compile("~10"));
    REQUIRE(c1.eval().asInt() == ~10l);

    REQUIRE_NOTHROW(c1.compile("2 * ~10"));
    REQUIRE(c1.eval().asInt() == 2 * ~10l);

    REQUIRE_NOTHROW(c1.compile("2 * ~10 * 3"));
    REQUIRE(c1.eval().asInt() == 2 * ~(10l*3));

Alternatively, the packToken class could get an operator int() method, which should allow it to be cast down to an integer (including implicitly). See: https://stackoverflow.com/a/4469907/109517

Blah, having problems making operator int work either— because of the overloaded operator==, there's an ambiguity. Hrmph.

from cparse.

Well that's sure a problem between different compilers. I think GCC does not differentiate between long and int64_t but clang does.

If GCC did differentiate between them I could just add a constructor for the type long.

I also noticed that all errors are reported on the test file, so I will make 2 changes:

1. I will accept your suggestion and use the .asInt() to fix these warnings
2. I will update the default action on the Makefile from all to release; this way it won't compile the test file and it should avoid future problems of this kind.

If you have another suggestion on the right way to solve this I would be happy to implement, this auto conversion was a feature I liked on the library, but it seems it can't be made to work on all compilers =/.

from cparse.

@mikepurvis can you test to see if the problems are fixed?

I have made the changes I mentioned so to reproduce the compilation of the tests you should use

• make all

Also, if no more errors appear you may be able to run only make to compile the release version without compiling the code.

Thanks for reporting the problem, I hope this fixes it.

from cparse.

I seem to get a link warning now with make (still on OS X):

6 warnings generated.
ld -r -O1 shunting-yard.o packToken.o functions.o containers.o -o core-shunting-yard.o
ld: unknown option: -O1

However, curiously enough the make test target now runs to completion:

6 warnings generated.
c++ -std=c++11 -Wall -pedantic -Wmissing-field-initializers -Wuninitialized -g  -c catch.cpp -o catch.o -g 
c++ -std=c++11 -Wall -pedantic -Wmissing-field-initializers -Wuninitialized -g  test-shunting-yard.o shunting-yard.o packToken.o functions.o containers.o builtin-features.o catch.o -o test-shunting-yard
./test-shunting-yard 
===============================================================================
All tests passed (419 assertions in 36 test cases)

from cparse.

That's good I think.
This -O1 option on the linkage step is for asking the linker to optimize the final binary.
Since it has only generated warnings it should be safe to use the library now, but I will search to understand why this option is not available on OSX (probably the ld binary is not exactly the same).

Were there any other warnings? I would be happy to fix them if possible.

Again thanks for reporting these problems.

from cparse.

If you're not opposed to it, just switching the buildsystem to CMake would take care of these kinds of cross-platform issues, since it has knowledge of what flags are appropriate for a debug vs release build across a wide range of compilers and platforms.

I think the main other warnings are as in the original post: complaints about const qualifier having no effect, and struct/class confusion between declaration and implementation.

Since you're already using Travis anyway, you could consider dropping the hard-coded CXX=g++ and then letting Travis set that envvar and use its build matrix feature to test both clang and gcc; with -Wall;-Werror, this would turn warnings from either compiler into errors.

Anyway, thanks for cleaning up and making available this library— it will definitely help on a project I'm working on!

from cparse.