New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

constexpr checks of format strings #546

Closed
vitaut opened this Issue Jul 16, 2017 · 8 comments

Comments

Projects
None yet
3 participants
@vitaut
Contributor

vitaut commented Jul 16, 2017

Add a check_format constexpr function for performing a compile-time format string check and a section explaining why such check cannot be incorporated in the format function itself at the moment. As discussed in #492 and the main problem is the lack of ability to handle the format string in constexpr context when other arguments are not constexpr.

Also Zach Laine suggested to mention the benefits of "compile-time strings":

But the other part of what I want is for people to see how nice the interface would be if you could treat the format string as a constant expression.

@vitaut

This comment has been minimized.

Show comment
Hide comment
@vitaut

vitaut Sep 16, 2017

Contributor

Potentially relevant discussion about constexpr function parameters: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/RdAK-0RyiY0/F3h-qF_jWbIJ

Contributor

vitaut commented Sep 16, 2017

Potentially relevant discussion about constexpr function parameters: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/RdAK-0RyiY0/F3h-qF_jWbIJ

@vitaut

This comment has been minimized.

Show comment
Hide comment
@vitaut

vitaut Sep 30, 2017

Contributor

It is possible to access the format string and argument types at compile time using UDLs:

#include <string>

template <char... Chars>
struct formatter {
  template <typename... Args>
  constexpr std::string operator()(Args...) const;
};

template <typename T, T... Chars>
constexpr auto operator""_format() {
  return formatter<Chars...>();
}

int main() {
  return "{}"_format(42).size();
}
Contributor

vitaut commented Sep 30, 2017

It is possible to access the format string and argument types at compile time using UDLs:

#include <string>

template <char... Chars>
struct formatter {
  template <typename... Args>
  constexpr std::string operator()(Args...) const;
};

template <typename T, T... Chars>
constexpr auto operator""_format() {
  return formatter<Chars...>();
}

int main() {
  return "{}"_format(42).size();
}
@ldionne

This comment has been minimized.

Show comment
Hide comment
@ldionne

ldionne Oct 18, 2017

Not only could you perform the safety checks at compile-time, but you could also generate optimal code by parsing everything at compile-time.

ldionne commented Oct 18, 2017

Not only could you perform the safety checks at compile-time, but you could also generate optimal code by parsing everything at compile-time.

@vitaut

This comment has been minimized.

Show comment
Hide comment
@vitaut

vitaut Oct 21, 2017

Contributor

Parsing of format specs is now constexpr and works with GCC 6.3, AppleClang 7.3 and Visual C++ 2017. Now need to figure out how to report errors at compile time. Can't use static_assert because it requires message to be a string literal.

Contributor

vitaut commented Oct 21, 2017

Parsing of format specs is now constexpr and works with GCC 6.3, AppleClang 7.3 and Visual C++ 2017. Now need to figure out how to report errors at compile time. Can't use static_assert because it requires message to be a string literal.

@Rush

This comment has been minimized.

Show comment
Hide comment
@Rush

Rush Nov 13, 2017

@vitaut tried to compile your std branch with "g++ (SUSE Linux) 7.2.1 20171020 [gcc-7-branch revision 253932]" in order to test constexpr but got a lot of errors. Is your CI catching those?

Rush commented Nov 13, 2017

@vitaut tried to compile your std branch with "g++ (SUSE Linux) 7.2.1 20171020 [gcc-7-branch revision 253932]" in order to test constexpr but got a lot of errors. Is your CI catching those?

@vitaut

This comment has been minimized.

Show comment
Hide comment
@vitaut

vitaut Nov 13, 2017

Contributor

@Rush, the current revision (d0f6d96) is broken at the moment. Please use dfdb1ad instead. I'll fix it shortly.

Contributor

vitaut commented Nov 13, 2017

@Rush, the current revision (d0f6d96) is broken at the moment. Please use dfdb1ad instead. I'll fix it shortly.

@vitaut

This comment has been minimized.

Show comment
Hide comment
@vitaut

vitaut Nov 15, 2017

Contributor

@Rush, the std branch should be fixed now. Let me know if you still see errors on your version of gcc.

Contributor

vitaut commented Nov 15, 2017

@Rush, the std branch should be fixed now. Let me know if you still see errors on your version of gcc.

@vitaut

This comment has been minimized.

Show comment
Hide comment
@vitaut

vitaut Nov 24, 2017

Contributor

As of f03a35a the format string checks are complete. Opened a separate issue for optimal code generation: #613.

Contributor

vitaut commented Nov 24, 2017

As of f03a35a the format string checks are complete. Opened a separate issue for optimal code generation: #613.

@vitaut vitaut closed this Nov 24, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment