3 ms·

While (I think) I understand your broader point, when would you pass a string created by a constexp to fopen() or CreateFile?

cshokie 3y ago
Hard-coding a relative file path seems like an obvious example. For example a config file with settings. The file will always have the same name so heap allocations and mutability are not needed.
- eesmith 3y ago
  My config file paths have either been constant (".dotfile") or required run-time information that could not be constexpr'ed. I don't see how constexpr would be useful. Then again, I am primarily a Python and C programmer, so there is likely some underlying reasoning I'm missing.
  - cshokie 3y ago
    const std::string foo = “.dot file”; in C++ cannot change after construction, but is not compile time constant. This means that it has to run some code and allocate some memory at runtime. In contrast constexpr is fully compile time and ends up in the read only portion of the binary. No code code execution or allocations necessary.
maccard 3y ago
They were examples, they're widely used C apis. Anything that passes through to glibc, windows or posix will have this problem.
- eesmith 3y ago
  I lack the intuition to understand why is it useful to constexpr path names. Could you elaborate?
  - maccard 3y ago
    It's not about path names. It's about passing constexpr strings to c functions that expect a null terminated string. You're totally missing the point. That said, here's an example: // imagine this with string_view FILE* openFileInPath(const std::string& path) { if (path.starts_with("some_dir")) { return fopen(path.c_str()); } return nullptr; } That function works just fine to only open a path that has a prefix (logic bug on relative paths aside for brevity while posting) I should be able to pass a constexpr string to that function the same way I can pass a runtime created string.
    - eesmith 3y ago
      Oh, I don't doubt I'm missing the point. That's why I'm asking. My C++ experience is from the 1990s. Otherwise I do Python and C. I think of constexpr functions as something which occur at compile time, and I thought this linked-to piece was about what can take place inside those functions. As I understand it, you want to create a constexpr string so it can be passed to a char*. The issue is this requires heap allocation (for large enough strings, based on the compiler implementation). The C programmer in me wonders why you don't "char[]" allocate the static memory buffer, then pass around a string view, so the constexpr doesn't need heap at all.
      - maccard 3y ago
        > As I understand it, you want to create a constexpr string so it can be passed to a char*. The issue is this requires heap allocation (for large enough strings, based on the compiler implementation). There's a few reasons. Avoiding the heap allocation is one, yep. There just shouldn't be a difference between a compile time string and a runtime string. As a programmer I don't want to have to deal with "which flavor of string am I dealing with". The issue with passing to a c API (I used fopen, but think of any c library - zlib/gzip, openssl, sqlite) is that the string needs to be null terminated, and string view doesn't guarantee null termination. int foo(std::string_view view) { return strlen(view.data()); } std::string str("hello world"); foo(str): std::string_view view = str; foo(view); view.remove_suffix(6); // now view is just "hello" with no null termination foo(view); // this is wrong. The problem isn't _specifically_ constexpr std::string in this case, it's that the tools that you use to generalise working with runtime strings, char buffers, and views aren't fit for purpose.

cshokie 3y ago

Hard-coding a relative file path seems like an obvious example. For example a config file with settings. The file will always have the same name so heap allocations and mutability are not needed.

eesmith 3y ago
My config file paths have either been constant (".dotfile") or required run-time information that could not be constexpr'ed. I don't see how constexpr would be useful. Then again, I am primarily a Python and C programmer, so there is likely some underlying reasoning I'm missing.
- cshokie 3y ago
  const std::string foo = “.dot file”; in C++ cannot change after construction, but is not compile time constant. This means that it has to run some code and allocate some memory at runtime. In contrast constexpr is fully compile time and ends up in the read only portion of the binary. No code code execution or allocations necessary.

maccard 3y ago

They were examples, they're widely used C apis. Anything that passes through to glibc, windows or posix will have this problem.

eesmith 3y ago
I lack the intuition to understand why is it useful to constexpr path names. Could you elaborate?
- maccard 3y ago
  It's not about path names. It's about passing constexpr strings to c functions that expect a null terminated string. You're totally missing the point. That said, here's an example: // imagine this with string_view FILE* openFileInPath(const std::string& path) { if (path.starts_with("some_dir")) { return fopen(path.c_str()); } return nullptr; } That function works just fine to only open a path that has a prefix (logic bug on relative paths aside for brevity while posting) I should be able to pass a constexpr string to that function the same way I can pass a runtime created string.
  - eesmith 3y ago
    Oh, I don't doubt I'm missing the point. That's why I'm asking. My C++ experience is from the 1990s. Otherwise I do Python and C. I think of constexpr functions as something which occur at compile time, and I thought this linked-to piece was about what can take place inside those functions. As I understand it, you want to create a constexpr string so it can be passed to a char*. The issue is this requires heap allocation (for large enough strings, based on the compiler implementation). The C programmer in me wonders why you don't "char[]" allocate the static memory buffer, then pass around a string view, so the constexpr doesn't need heap at all.
    - maccard 3y ago
      > As I understand it, you want to create a constexpr string so it can be passed to a char*. The issue is this requires heap allocation (for large enough strings, based on the compiler implementation). There's a few reasons. Avoiding the heap allocation is one, yep. There just shouldn't be a difference between a compile time string and a runtime string. As a programmer I don't want to have to deal with "which flavor of string am I dealing with". The issue with passing to a c API (I used fopen, but think of any c library - zlib/gzip, openssl, sqlite) is that the string needs to be null terminated, and string view doesn't guarantee null termination. int foo(std::string_view view) { return strlen(view.data()); } std::string str("hello world"); foo(str): std::string_view view = str; foo(view); view.remove_suffix(6); // now view is just "hello" with no null termination foo(view); // this is wrong. The problem isn't _specifically_ constexpr std::string in this case, it's that the tools that you use to generalise working with runtime strings, char buffers, and views aren't fit for purpose.