1

Since I started using C++17 every time I have to develop a new library I consider several alternatives for passing file paths to public functions/methods. These are some of my thoughts I normally have regarding this topic:

  • By using std::filesystem::path in the public functions, I would be adding a strong dependency to C++17. Consumers of my library would need to have a C++17 compiler in order to be able to use it. What if I want this library to be used from other programming languages?
  • On the other hand, you make very clear in your API what you are expecting as parameter, and it should be compatible with paths given on different encodings (I have experienced issues in the past when dealing with paths on different locales with std::string or std::wstring. For example, consider paths given in different languages: English, Spanish, Chinese)
  • By using std::string or std::wstring we would relax the strong dependency to C++17 to any C++ version. But I have the feeling I would end up needing to create overloads of functions to support multi-locale paths.
  • Would it be simpler to just use a const char * for passing paths? I guess that with that approach I would end up needing to also consider different kinds of string literals. However, one advantage would be that if I use basic types, I could generate a Flat-C API that could be easily consumed by other programming languages.

Let's assume that the library is a multi-platform (linux, windows, OSX) & multi-architecture (x64, x86, ARM) compatible library. What are your thoughts? Which kind of type do you think would be better for passing file paths?

I know that it is kind of an open-question with many possible interpretations. I just would like to learn from the community in this aspect :).

piponazo
  • 478
  • 2
  • 4
  • 10
  • 1
    `multi-locale paths` ? Paths are just byte-strings. || Sorry, I believe this is not a forum for `What are your thoughts?` questions. Post your question on reddit on r/cpp. – KamilCuk Nov 26 '21 at 13:47
  • 4
    If you have a library that should be usable by other languages than C++ you can't use a C++ API at all, you must rely on `extern "C"` and C-compatible types only for the public API. With that said, you can encapsulate C++ objects using opaque pointers (`void*`). – Some programmer dude Nov 26 '21 at 13:47

1 Answers1

0

Which kind of type do you think would be better for passing file paths?

T&&, as usual. Thanks to to this common modern C++ approach,

adding a strong dependency to C++17

Any dependencies are avoided.

make very clear in your API what you are expecting as parameter, and it should be compatible with paths given on different encodings

No problem: declare the parameter with a meaningful name, e.g. T&& file_path.

different locales with std::string or std::wstring. For example, consider paths given in different languages: English, Spanish, Chinese

With T&&, you can pass anything that compiles, even if it is my_lib::ChineseWString.

multi-platform (linux, windows, OSX) & multi-architecture (x64, x86, ARM)

Yes.

So, the code would look like

template<typename T> auto do_something(T&& file_path) { /* do something */ }

If your library is given an incompatible type, the compiler informs you - anything that doesn't typecheck will produce a compile-time error.

generate a Flat-C API that could be easily consumed by other programming languages

Here's the only problem - you can't pass C++ API to other languages. If you need to, I suggest a question retag.

passing_through
  • 1,778
  • 12
  • 24