std::filesystem::path support

[MeGaL0DoN]

I kept the original constructors accepting std::string, but created a new class "mINIFilePath" with an explicit std::filesystem::path constructor. It is needed so any existing code is not broken, in case there is some type which implicitly converts to std::string but not to std::filesystem::path. So, for example, mINI::INIFile file { "hello.txt" } will still call the std::string version,
but, mINI::INIFile file { mINI::mINIFilePath("hello.txt") } will call the std::filesystem::path version. This is important because std::filesystem::path can be created with any encoding, allowing the library to be used to read/write files containing unicode characters.

[metayeti]

The idea is fine but I think it needs some changes still.

1. Instead of a wrapper, wouldn't it be more on point to just allow mINI::INIFile(std::filesystem::path&) or such? Keep any paths internally with filesystem::path but just expose a string API for backwards compatibility. Basically a simpler implementation.
2. There needs to be some sort of testcase added for this.

If you want I can figure this out myself but it will take me some time as I'm busy with other stuff at the moment.

[metayeti]

Actually doesn't the filesystem API by default allow strings anyway?

[bilal614]

Hi. I started using mINI recently in a repo of mine, really appreciated how easy mINI was to integrate and use on my project. Please feel free to ignore the review comment if it seemed totally out of the blue and unsolicited :) .

[bilal614]

Was wondering if the fromString static method could be an overloaded constructor taking a string path instead? It may make the calling convention less verbose for example. For instance mINIFilePath(filename) instead of mINIFilePath::fromString(filename)

[metayeti]

Yeah I'm gonna need to simplify this. I don't think there's a need for a wrapper.

[MeGaL0DoN]

Yeah I'm gonna need to simplify this. I don't think there's a need for a wrapper.

Wrapper is needed if you want it to be 100% backwards compatible with all existing code. For example, if someone added conversion operator to std::string to some class:

struct test
{
    int val;

    operator std::string() const
    {
        return std::to_string(val);
    }
};

Then they won't be able to pass it to the function accepting std::filesystem::path. And you can't have function accepting both, std::string and std::filesystem::path directly either, because you will get compiler error when trying to pass a string directly, since string can be implicitly convert to filesysyem::path, and it won't know which overload to use. Try it yourself.

[MeGaL0DoN]

Was wondering if the fromString static method could be an overloaded constructor taking a string path instead? It may make the calling convention less verbose for example. For instance mINIFilePath(filename) instead of mINIFilePath::fromString(filename)

You can't have 1 constructor accepting std::string and the other std::Filesystem::path, since string by itself is implicitly convertible to std::filesystem::path, so it won't know which overload to use, and it will result in a compile error.

[metayeti]

Thanks for insights, I'll experiment with it when I have some time on my hands.