Discussion about supporting C++17

[2bbb]

Let's discussion about C++17.

[2bbb]

#6488

[2bbb]

https://forum.openframeworks.cc/t/does-of-not-work-with-c-17/29925

[2bbb]

on macOS early 10.14, we can't use C++17 with oF0.11.0 release, with both OF_USING_STD_FS 0 and OF_USING_STD_FS 1.
the biggest cause of this problem is by Apple LLVM/clang.

but essentially, I think it lies under extending std namespace adding filesystem.
extending std is so evil way.

I fixed bug about difference between std::filesystem and std::experimental::filesystem.
but it doesn't fix problem on macOS early 10.14.

and if try to use C++17 on macOS 10.14, then we need to remove boost::filesystem from std with OF_USING_STD_FS 0 or adding so many CPP macros and separating codes.

I want to propose what adding of (or other name) namespace and add boost::filesystem or std::experimental::filesystem or std::filesystem.
it still needs some macros to absorb the diff of some APIs, but doesn't need to adding macros.

what do you think?

[roymacdonald]

Hey @2bbb I think that this move to support C++17 will eventually happen so we should consider it right now how to address it. I think that it is important that these changes don't alter the way in which of is used in general, as far as this is possible and does not bloat the codebase or needs the use of hacky fixes.
Can you post the code changes that you are proposing?
best!

[oxillo]

Do we still need to use boost::filesystem in C++17 (meaning C++17 and OF_USING_STD_FS=0) ?
I would say that most people using C++17 will expect to use std::filesystem.
So I would suggest that OF_USING STD_FS is only applicable to C++14 and below.
This will also make solving #6587 a lot easier...

[2bbb]

@roymacdonald

i will push to my repository asap.

@oxillo
basically, i agree to what you say.
but, on older macOS (~Mojave) has C++17 option but can't use std::filesystem::path...
it still needs option to use boost::filesystem.

[arturoc]

boost was only used temporarily until there was filesystem support in std.

The idea is not to keep it but to remove it as soon as we can and stop even shipping the boost libraries.

This needs to happen gradually by first only enabling OF_USING_STD_FS for those compilers that already have full support for c++17 then after the minimum version supported by OF already supports c++17 fully remove boost completely

We would need to identify what versions of the supported compilers already support c++17 fully a way to detect the version.

I would say:

• Windows visual sutdio: already supported and since we only support the latest version we can already even remove boost from OF
• Windows msys2: is now at gcc10 so we can also already remove boost
• MacOS / iOS: we need a way to figure out the version in use and enable boost or std fs accordingly
• Linux (including arm): detect gcc 10 or greater in the makefiles and enable OF_USING_STD_FS there based on that
• Android: no idea and in any case we support a pretty old version of the NDK so we surely need to just stick to boost by now although we could also enable it through experimental which is also supported when enabling OF_USING_STD_FS

[oxillo]

I had a bad experience last year when enabling OF_USING_STD_FS on msys2 and running the tests. It deleted my OF dir...
I've managed to compile OF on MSYS2/GCC10 with the following 3 configurations :

• gnu++14/OF_USING_STD_FS=0
• gnu++14/OF_USING_STD_FS=1
• c++17

In ofConstants.h, I've added the c++17 detection and removed the filesystem #if
In ofFileUtils.h, I've rewritten the #if section as :

#if HAS_CPP17 // Use std::filesystem
	#include <filesystem>
#else
	#if OF_USING_STD_FS // Use std::experimental::filesystem
		#include <experimental/filesystem>
		namespace std {
			namespace filesystem = experimental::filesystem;
		}
	#else // Use boost::filesystem
		#if !_MSC_VER
			#define BOOST_NO_CXX11_SCOPED_ENUMS
			#define BOOST_NO_SCOPED_ENUMS
		#endif
		#include <boost/filesystem.hpp>
		namespace std {
			namespace filesystem = boost::filesystem;
		}
	#endif // OF_USING_STD_FS
#endif //HAS_CPP17

I'll try to run the tests now after a backup...

[kaofishy]

BTW, boost::filesystem and std::filesystem are not drop-in replacement of each other, last time I tried to get OF_USING_STD_FS to work (it was a while ago) I encountered type definition mismatch and I recall particular difficulty to get std::filesystem::path to work with existing openFrameworks code.

See this post for differences between boost::filesystem and std::filesystem.

[arturoc]

Yes they are not exactly the same but OF_USING_STD_FS not only includes one or the other but also ifdefs certain calls that are different for both. Exisiting code might need to be changed when directly using std::filersystem

There might be some differences from std::filesystem experimental and the finall c++17 implementation. I think i only tested it with experimental when implementing it so there might be some changes that need to be made to get it to work with c++17

[2bbb]

https://github.com/2bbb/openFrameworks/tree/dev/supporting_cpp17

codes in this branch is better way i think.
(this branch includes #6579 what fix different on std and std::expermental)

this changes of code make another namespace of (i can't know this name is good or bad. but it is not current problem.), and include filesystem from std or std::experimental or boost.

i know this will break codes using std::filesystem.
and also, i know oF codes have not made namespace explicitly. (i know there is ofx namespace in detail of codes.)

but i think, this is better way.
because, in any case, we cannot use filesystem uniformly across some envs because some difference be in three filesystems.
and i think, to hide these difference makes someone confusing when use C++17.

if we will not support old envs, then perhaps we can choose other way.
but if we will support old envs partialy support std::filesystem, then we need to use boost::fileystem with partial C++17 envs. and it conflicts about filesystem.

sorry to my not better explanation.
i believe you understand what i want to say.

thanks.

[artificiel]

as a user i'd like to stimulate this issue — the real subject here is not "supporting c++17" but solving the ::filesystem ambiguity.

until recently i was able to compile with c++17 (macOS and linux) but because of a compiler update the ::filesystem thing forces me to specifying down to c++14 and having adjust some things and to pepper #pragmas so the compiler does not flood the output with warnings (while still supporting the features).

"transparent" c++17 usage would be very much appreciated! (and more and more 3rd party libs and example code are relying on c++17).

[ofTheo]

As far as detecting if the compiler supports c++17 and std::filesystem this macro is defined when filesystem is available
__cpp_lib_filesystem and this one is defined when experimental is available __cpp_lib_experimental_filesystem

So we could probably use these across all compilers to get the right level of fallback.

I could work on a PR that handles the fallback and also check to see if the final spec calls are 1:1 replacements of the experimental.

see:
https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros#C.2B.2B17
and:
https://stackoverflow.com/questions/53365538/how-to-determine-whether-to-use-filesystem-or-experimental-filesystem

[arturoc]

@ofTheo if you are going to look into this, take into account that everything is mostly done all the differences between apis are already ifdefd and there's macros: OF_USING_STD_FS to enable one or the other. this was all working around a year ago but probably some final change in the final standard macros have broken the detection. it should be just a matter of changing a coupld of macros in ofFileUtils.h everything else should just work after that unless there's been more changes to the actual filesystem api but i doubt that's the case

[ofTheo]

Thanks @arturoc ! That’s really helpful. Hopefully will be fairly minimal, but will try and test all the different cases.