================
@@ -64,32 +64,14 @@ struct _LIBCPP_TEMPLATE_VIS formatter<const _CharT*,
_CharT> : public __formatte
template <class _FormatContext>
_LIBCPP_HIDE_FROM_ABI typename _FormatContext::iterator format(const _CharT*
__str, _FormatContext& __ctx) const {
_LIBCPP_ASSERT_INTERNAL(__str, "The basic_format_arg constructor should
have prevented an invalid pointer.");
-
- __format_spec::__parsed_specifications<_CharT> __specs =
_Base::__parser_.__get_parsed_std_specifications(__ctx);
-# if _LIBCPP_STD_VER >= 23
- if (_Base::__parser_.__type_ == __format_spec::__type::__debug)
- return
__formatter::__format_escaped_string(basic_string_view<_CharT>{__str},
__ctx.out(), __specs);
-# endif
-
- // When using a center or right alignment and the width option the length
- // of __str must be known to add the padding upfront. This case is handled
- // by the base class by converting the argument to a basic_string_view.
+ // Converting the input to a basic_string_view means the data is looped
over twice;
+ // - once to determine the lenght, and
+ // - once to process the data.
//
- // When using left alignment and the width option the padding is added
- // after outputting __str so the length can be determined while outputting
- // __str. The same holds true for the precision, during outputting __str it
- // can be validated whether the precision threshold has been reached. For
- // now these optimizations aren't implemented. Instead the base class
- // handles these options.
- // TODO FMT Implement these improvements.
- if (__specs.__has_width() || __specs.__has_precision())
- return __formatter::__write_string(basic_string_view<_CharT>{__str},
__ctx.out(), __specs);
-
- // No formatting required, copy the string to the output.
- auto __out_it = __ctx.out();
- while (*__str)
- *__out_it++ = *__str++;
- return __out_it;
+ // This sounds slower than writing the output directly. However internally
+ // the output algorithms have optimizations for "bulk" operations. This
+ // means processing the data twice is faster than processing it once.
----------------
ldionne wrote:
```suggestion
// This sounds slower than writing the output directly. However internally
// the output algorithms have optimizations for "bulk" operations, which
make
// this faster than a single-pass character-by-character output.
```
https://github.com/llvm/llvm-project/pull/101805
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
