Comments (23)
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
andfunction
in place ofauto_ptr
andbinary_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 theunique_ptr
andfunction
change. If somebody beats me to it it is fine too. If @PDeveloper or @Qix- can try to benchmarkunordered_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
andstd::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.
Related Issues (20)
- Failed building wheel for kiwisolver :( HOT 4
- Cann't install on python 3.11b3 HOT 2
- 1.4.3 has no attribute __version__ HOT 2
- ERROR: Failed building wheel for kiwisolver: C2440: 'static_cast': cannot convert from 'expr_type' to 'type' HOT 2
- Provide cp311 releases HOT 1
- Objective cell memory leak? HOT 26
- Continuous fuzzing by way of Google's OSS-Fuzz HOT 1
- Tests fail on pypy
- #egg=kiwisolver See assertion error when installing kiwisolver HOT 4
- about duplicate constraints HOT 3
- Add Python API to get all constraints HOT 14
- Is it possible to get the absolute value of an expression? HOT 10
- Is it possible to tell the Solver to prefer smaller or larger solutions? HOT 3
- Missing type hint for `Constraint.violated()` HOT 1
- Python 3.12 manylinux wheels HOT 2
- PyInstaller executable with matplotlib cannot find _cext DLL HOT 6
- `top_level.txt` include a non existing module `src`
- DLL load failed while importing _cext HOT 2
- How do we define an "objective function" and maximize or minimize it? HOT 1
- On Windows 10 LTSC, import kiwisolver (and/or import matplotlib) fails with DLL _cext even after installing VS runtime (solution incl) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kiwi.