Does not even compile ... about kiwi HOT 23 CLOSED

Sorry, this seems like much ado about nothing. Is the claim that there is a C++ 14/17 compiler that people want to use which doesn't also support C++ 11?

Assoc vector is used over unordered map because it's faster for this use case. You can test it yourself on your compiler by switching the relevant typedef in the code.

from kiwi.

Nothing in this code base requires C++ 17

from kiwi.

After discussing with @sccolbert we concluded that:

• we will drop Python 2 support
• it is reasonable to require c++11 and hence to use unique_ptr and function in place of auto_ptr and binary_function
• we should try to benchmark https://github.com/wo3kie/assocVector/blob/master/AssocVector.hpp which claims to be a faster implementation and is c++11 compatible.
  I need to do some work on the C/Python wrapper so I am fine doing also the unique_ptr and function change. If somebody beats me to it it is fine too. If @PDeveloper or @Qix- can try to benchmark unordered_map, and both implementation of AssocVector it would be great !

from kiwi.

For the time being the library support Python 2.7 which means it should compile with VS2008. When we drop support for it (which may happen at the beginning of 2019), we will consider fully updating to c++11. If you want to contribute a PR in that direction I would be happy to review it.
In the meantime please note that the testsuite passes on Travis (Ubuntu xenial gcc 5.4). If you can indicate to me what compiler you use, it will also help me replicate the issue and possibly fix it.

from kiwi.

Why not typedef the STL classes out? Keeps compatibility and allows non-stl environments to compile.

from kiwi.

The need has never shown up before. And my time and c++ expertise being limited (@sccolbert has even less time, even though he is much more knowledgeable where c++ is concerned), I never invested time in it since my main use for this library is in enaml.

from kiwi.

Would be a worthwhile PR if someone wanted to undertake it. OP is right - STL is rarely used anymore - but the need to keep backwards compatibility is understandable. If it's just memory management classes that are the problem, a few typedefs should fix things.

from kiwi.

@Qix- @MatthieuDartiailh So fixing the issues, this library is using pre-C++11 STL, various things are removed in C++14 and C++17 now, so building it for modern projects is impossible.

I'll work on a PR, auto_ptr luckily can just be replaced with unique_ptr, and binary_function with function I think, perhaps in a new branch for C++17 support.

enaml is the Python layout library?

EDIT: I'm using VS2017 with all options to enable C++17 and future features / restrictions.

from kiwi.

@PDeveloper targeting c++11 with those changes should suffice and wouldn't black out a whole army of C++ developers that don't yet use C++17 for platform compatibility reasons 🙃

from kiwi.

You can look through the PR history. One PR already proposed to switch to unique pointer but was rejected due to Python 2.7 support. I do hope to drop Python 2 so your PR should get merged at one point.
If you can figure out a way to use a GCC version recent enough on Travis and with the proper flags to enforce c++17 for at least one build it would be great.

from kiwi.

@MatthieuDartiailh which is why you would use typedefs and a build flag. You could support both...

from kiwi.

Sure but at the time c++17 was not a concern and now that we are close to dropping Python 2.7 I am not sure it is worth complicating the code to support pre-c++11 compilers.

from kiwi.

c++17 isn't remotely supported by all compilers yet. c++11 is the most commonly targeted right now. c++14 if you're feeling adventurous.

Requiring c++17 will make new versions unusable for a large userbase for a very long time with absolutely no benefit if all you're changing are a few pointer classes and maybe a few stl classes.

Seriously, typedef's are the answer here if you're looking for compatibility, and come with zero overhead. Please consider them.

from kiwi.

I am not suggesting we target only c++17. I am simply saying that eliminating references to deprecated stl types in c++11 (and removed in c++17) can be done if we drop support for pre-c++11 compilers, which seems reasonable, no ? (as soon as we don't need vs 2008 because of Python 2)
The only modifications are auto_ptr -> unique_ptr and binary_function -> function which works from c++11 to c++17 at least, or did I miss something ?

from kiwi.

Those are the main changes, fairly straight forward, as well as I'm seeing I might need to restructure AssocVector (any reason unordered_map won't work?), since std::less does not typedef its template parameters anymore.

@Qix- I don't think this will all be a huge concern - enabling C++17 for tests, and since I'm targeting it, would be best to ensure future compatibility. The actual features introduced should all be basic C++11 stuff, but several elements of the STL have been completely removed in C++14 and C++17, so it would end up being cleaner.

from kiwi.

For AssocVector @sccolbert, as the original author, is likely to know more than I do.

from kiwi.

Aha, I understand now.

This library use non-existent STL

So fixing the issues, this library is using pre-C++11 STL

eliminating references to deprecated stl types in c++11

The STL is not the C++ Standard Library, this is a common misconception. The STL is an old archaic library that predates C++ standards. It only exists in older projects and should be completely phased out now (I didn't know how old Kiwi was).

That's why I was confused.

At any rate, this sounds fine.

from kiwi.

This library use non-existent STL like std::auto_ptr and std::binary_function

std::auto_ptr and std::binary_function are not non-existent, they are part of the C++03 standard. They were deprecated in C++11, that doesn't mean that library can't be compiled with -std=c++11.

from kiwi.

@Qix- I keep running into this ... my bad, I've always used STL to refer to the C++ Standard Library ye, and once in a while people keep reminding me after confusion about the original STL, will try to remember it this time ... :s

@peterazmanov Those features are indeed non-existent, if you look at the C++14 and C++17 standards. Even then, deprecated features aren't something desirable if there are clear and clean upgrade paths available, in my opinion, especially with standards moving forward.
(Compiling with -std=c++11 isn't a solution for projects targeting anything newer ... )

from kiwi.

Compiling with -std=c++11 isn't a solution for projects targeting anything newer

That's a misconception. The standard library dictates purely C++ things, it doesn't have any leverage on syscalls and the like. Therefore, you're really only going to be impacted by the compilation step, not the linkage step.

Which means for codebases that use Kiwi by adding it as a dependency (e.g. add_subdirectory() in CMake projects) it doesn't matter which flags you use and which standard they use - it'll compile just fine.

You don't have to make your library c++17 compatible in order to allow people to build with c++17. It's not like compilers just "drop" support for c++11 or earlier.

What @peterazmanov says is correct. If you target c++11, you'll support everyone that has c++11 support or newer, cutting out users with compilers that have an upper support bound of <c++11 - which in this case is fine.

However, by explicitly specifying -stdc++17 in the build scripts, you will be preventing builds for most users in 2018 as many compilers do not support that high of a standard.

from kiwi.

Not sure who you're addressing, but I'm claiming the inverse - that there are compilers that do not yet support c++17.

from kiwi.

Agreed.

from kiwi.

Please see #55

from kiwi.