I want to replace boost::filesystem::path with juce::File. The problem is that the File constructors are not fond of partial paths. For example, calling fopen() with a partial path from the “current directory.” I get that annoying jassertfalse in File::parseAbsolutePath() when I try to construct File objects with partial paths that work when passed to boost::filesystem::path constructors. I don’t mind changing code around but how can I get this to work?
What’s a sane way to do this?
I deliberately avoided partial paths because they’re such a pain - if you allow them, then whenever you need to actually use one, you’d need to also supply an absolute path for it to be relative to.
You might want to look at the RelativePath class in the introjucer though - it’s not part of the main library because it’s quite specialised for the introjucer’s needs, but may be interesting.
Not sure I follow. If I call fopen, there’s no additional absolute path parameter, there’s just a string. It would be nice to be able to compose partial paths the same way as full paths using the File interface, in a platform independent way. For example, to append directory components and have the platform specific separator automatically added. Or to be able to extract just the directory portion from a partial path.
A partial path is only useful you know what it’s relative to… In the case of fopen, it treats the path as being implicitly relative to the CWD, but that’s not always an assumption that you’d want to make - you may want paths that are relative to something else.
In this use-case, the relative paths are always used with calls to the operating system or standard library so the assumption is the CWD.
RelativePath looks pretty handy, but it’s not ISC licensed. Mind if I steal it?
Also it uses FileHelpers, which is also not ISC licensed.
Sure - it’s only a trivial class, and you’d probably need to rewrite it anyway, as it’s fairly introjucer-specific.
Come to think of it, all of my problems could be solved if we had something like:
This would either construct with an absolute path, or if path was a partial path it would retrieve the current working directory, build a full path using that and return a File constructed with the absolute path. Does this function already exist and I’m just not seeing it?
[quote=“TheVinn”]Come to think of it, all of my problems could be solved if we had something like:
This would either construct with an absolute path, or if path was a partial path it would retrieve the current working directory, build a full path using that and return a File constructed with the absolute path. Does this function already exist and I’m just not seeing it?[/quote]
No… that function may indeed be a good idea, but doesn’t exist. Whenever I’ve needed to do that, I’ve always just written File::getCurrentWorkingDirectory().getChildFile (“partial or full path”), which would do exactly the same job.
The documentation for getChildFile() claims that it requires a relative path. What happens if an absolute path is passed? It sort of doesn’t make sense.
The documentation for getChildFile() claims that it requires a relative path. What happens if an absolute path is passed? It sort of doesn’t make sense.[/quote]
If it gets a full path, it just uses that. (I didn’t know the comments didn’t explain that - if so, I’ll clarify that…)
You should change the parameter name to “relativeOrAbsolutePath”
Yes, I might do that. The docs are actually pretty good though, they do explain this.
The examples explain it but the Javadoc brief doesn’t. It reads:
Ah, I was looking at the code itself - the full description does explain it, but not the brief. Thanks, I’ll improve that!
