stop using strings for file path manipulation

[ofTheo]

This is sort of a global issue and is being partly addressed by @elliotwoods 's PR for ofDataPath #1523

We should refrain from doing string manipulation on paths and use poco path for everything but actually passing the path to the loader/saver/manipulator .

[bilderbuchi]

How does that look in the PG? this could possibly reduce the various headaches with paths and double // etc in the PG, right?

[ofZach]

this would be a big help for the PG and avoid some headaches. in particular, copyFromTo has been problematic, but overall, I think using a smarter object and avoiding string manipulation everywhere will be a big win.

[arturoc]

some days ago i changed ofFile and ofDirectory so their comparison operators return the correct value even for different paths if they are actually pointing to the same thing:

ofFile f1("img.png");
ofFile f2("../data/img.png");
f1==f2;

will return true. Poco comparison operators actually don't work for something like that

[elliotwoods]

@arturoc - unless we resolve absolute paths for equality

[arturoc]

yes that's what i did for ofFile and ofDirectory, we should add similar constructors, methods and operators for ofFilePath though, since ofFile actually opens the file

[elliotwoods]

now we have std::filesystem::path (even though it's actually boost right now), can remove this? or do we want to make it so that our functions start accepting path as an argument?

[arturoc]

string autoconverts to path so changing every path argument to std::filesystem::path would be a good idea. the only reason i see to wrap it with something else is that we use the data folder to store assets so we could have some class that did the ofToDataPath thing internally and wrapped filesystem::path.

[bakercp]

I think this is just about finished. @arturoc any reason to keep this issue open?

[dimitre]

We finally have of::filesystem::path for almost everything related to file opening, paths etc. Maybe this can be closed, or maybe soon with some ongoing PRs.