C++11 and boost::any

[ian.rees]

And it's not at all targeting "sneakily different platforms", we'd just take Boost up on its promise not to change its API when we tell it not to use C++11 (or parts thereof) internally on older distros.

Well, I guess that's subjective. The point of that #define is to remove a move constructor, which is an API change which I wouldn't expect to see on a C++11 project using a version of Boost that nominally supports C++11. In addition, we'd need to put a bit of effort into making sure that's the only change. I just think that it's better to keep things as simple as possible - have personally spent a lot of time trying to track down bugs caused by this sort of thing.

So, I think the right thing to do in this case is not use -std=c++11 or the minimum Boost requirement. Maybe it would be better to have a cmake flag for building without C++11 rather than conditioning on the gcc version? I imagine that on Ubuntu 12.04 or similar, if one were to try building without that flag set, then they'd get a fairly distinctive error (gcc 4.6 won't know what -std=c++11 means).

Anyway, I feel I'm starting to annoy, so I better shut up. Thanks for the explanations so far!

Sorry if I gave you that impression - I think the OpenSUSE issue you brought up is exactly what this thread had been lacking!

[jan]

Uh, I'm getting religious about little things. 10 posts after I've signed up. Please stop me if I'm getting into the habit.

And it's not at all targeting "sneakily different platforms", we'd just take Boost up on its promise not to change its API when we tell it not to use C++11 (or parts thereof) internally on older distros.

Well, I guess that's subjective. The point of that #define is to remove a move constructor, which is an API change which I wouldn't expect to see on a C++11 project using a version of Boost that nominally supports C++11.

In boost::any, you mean? Yes, good example: A move constructor that wrongly kicks in when you don't want it to. The official fix is to exclude that case. You don't even want that ctor to run in the crash's case, so it could just as well get lost in the first place, AFAICS .
BTW: you could also have your FC-private any-class, derived from the original, add the same precaution to the ctor as in the official fix, and be done with it.

Strictly speaking I'm not the biggest Boost fanboy around - but it does support C++11. Turns out that there's a bug in that support. Honestly, Ian, why do you care? It can be disabled. It has worked inside FreeCAD this way for a long time now. Boost may not use all move ctors where it could, so performance is a little worse than it could be. But it's source-code compatible. All C++11 code you write should still compile. Also new syntax that is unique to C++11, a thing you'd have to #ifdef out all over the place in FC if you wanted to maintain a codebase optionally supporting strict non-C++11 builds as well. Why precisely does that help unleash C++11 integration into FC? Or C++14 later on, for that matter?

That said: All this applies only to distros not having a libboost-dev / boost-devel 1.55+ installed. Distros that are already slashed off the list currently. All others would remain unaffected, so certainly no workbenches lost or anything. What's wrong with just giving the oldies a chance? You can always declare their support end of life if it doesn't work. On my machine, it does work. Not thoroughly tested, granted.

I just think that it's better to keep things as simple as possible - have personally spent a lot of time trying to track down bugs caused by this sort of thing.

Yeah, maybe some bugs will pop up here and there, but I currently don't understand where that could possibly be. And most importantly: incrementally phasing stuff out does help to understand things better in my experience. Steps as small as possible to a tested code path give problems that tend to be more understandable and helpful to find bugs. That's why you should always use an old engine in a newly constructed aircraft and vice versa. Not both new, ideally. Might be a matter of development habits, but I found my software's stability improving on all platforms if I compile it on as many as possible. So I tend to keep support for what I have as long as possible instead of removing it. Also keeping things does feel as if I've accomplished something meaningful.

Anyway, I feel I'm starting to annoy, so I better shut up. Thanks for the explanations so far!

Sorry if I gave you that impression - I think the OpenSUSE issue you brought up is exactly what this thread had been lacking!

Nah, ya didn't. I'm just being a sissy, I suppose. But I wasn't referring to packaging preferences, more to C++, and that case seems closed. I don't want to look like I'm filibustering decision-making processes I didn't attend early enough to make my case.

[ian.rees]

Honestly, Ian, why do you care?

Because I'm lazy, and I want to keep things easy for everyone else that works on FreeCAD. I'd personally rather work on making FreeCAD better and not try to figure out/maintain idiosyncrasies and corner cases unless there's a good reason to. -Ian-

[jan]

Because I'm lazy, and I want to keep things easy for everyone else that works on FreeCAD. I'd personally rather work on making FreeCAD better and not try to figure out/maintain idiosyncrasies and corner cases unless there's a good reason to. -Ian-

Certainly, we just don't agree on how to best achieve that.

Anyway, the OpenSUSE thing is a non-issue, as I wrote. People can have Boost 1.56 and higher from other than the default repos, and they will, so that should not stop you from raising the minimum required Boost version.

[wmayer]

Maybe it would be better to have a cmake flag for building without C++11 rather than conditioning on the gcc version?

From version 3.1 on cmake seems to offer some flags related to C++11.
http://stackoverflow.com/questions/1085 ... 1-in-cmake
http://stackoverflow.com/questions/1098 ... with-cmake

So, once C++11 is required the easiest is to raise the cmake version to 3.1 and use its macros and flags instead of playing with command line parameters for the various compilers.

[jmaustpc]

Maybe it would be better to have a cmake flag for building without C++11 rather than conditioning on the gcc version?

From version 3.1 on cmake seems to offer some flags related to C++11.
http://stackoverflow.com/questions/1085 ... 1-in-cmake
http://stackoverflow.com/questions/1098 ... with-cmake

So, once C++11 is required the easiest is to raise the cmake version to 3.1 and use its macros and flags instead of playing with command line parameters for the various compilers.

I just had a look at my Kubuntu 14.04 pc and it has only Cmake 2.8.12.2

I just checked my 12.04 box and it has cmake 2.8.12.2 as well, I must have updated it some time ago since they are the same version.

Once c++11 code is included somewhere in master (after 0.16), there would be no, or little, point in allowing anything to compile without C++11, or would there? For example once PartDesign has any C++11 code, a FreeCAD without c++11 would not be able to have PartDesign WB, which would make FreeCAD not very useful, or am I wrong?