In C++26, std::complex gained a tuple interface (P2819R2), causing
template specialization ambiguity in type_count and type_count_min.
This change explicitly excludes is_complex from tuple-like template
specializations, ensuring complex types are handled only by their
dedicated specializations.
Fixes#1098
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Allow more control over how extras are interpreted. Specifically
allowing some assumptions to be made about arguments to unrecognized
options. With `CLI::ExtrasMode::AssumeMultipleArguments` all positional
arguments following an unrecognized option will be considered extra as
well even if there are open positional arguments. With
`CLI::ExtrasMode::AssumeSingleArgument` a positional argument following
an unrecognized option will also be considered unrecognized and go into
the `remaining()` bin.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
adding a PrefixCommandMode option to the prefix_command to allow
specification of a separator and catch other errors
Addresses #1264
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
fix an issue where an enumeration with a stream output method would
generate strings that could not be converted back to the original
enumeration value.
Fixes Issue #1258
recent changes fixed a few issues with the default_val method. The
method used the to_string, which in cases where a user supplied a
streaming operation to enumerations they could not be converted back to
the enumeration properly resulting in some errors and confusing help
output.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Add some controls to manipulate option string formatting, including
disabling the default values, disabling default flag values, disabling
type names.
Fixes#857
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Based on #1242, I don't think this is required but it does remove that
issue and checking on compiler explore it does simplify the generated
code.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Fix the help spacing and double printing of footers in certain
circumstances
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Extension allowing all possible priority combinations.
Add a field callback_priority to OptionBase.
---------
Co-authored-by: Philip Top <phlptp@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Rework some of the validator locations, add documentation, and fix some
lingering issues with validators.
The extra will will enable additions of some new validators and reduce
compile times for those that are not needed.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
fix an issue with duplicate footers being printed with help_all
Fixes#1183
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
generating a seg fault if no default and no config file provided.
Fixes#1197
This was likely introduced by the combination of fixes for some issues
with the config parsing and some updates to the as<T> method a while
back. This edge case on the handling of the config pointer with as was
not overlooked in the earlier testing.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
The default formatter has hardcoded ratio at which the long options are
aligned. It's currently 1/3 of the column, which makes the default look
awkward:
```
-h, --help Print
--option Something
```
A ->long_option_alignment_ratio(6/30.f) allows output to look like this:
```
-h, --help Print
--option Something
```
The 1/3 ratio is also bad if you want to print "descriptive" long
options on a single line, because then you might want to increase the
column width, but that means you waste more space on short options.
e.g. ->column_width(46)
```
-l, --very-descriptive-long-option Something
```
vs. ->column_width(38)
```
-l, --very-descriptive-long-option
Something
```
vs. ->column_width(38) ->long_option_alignment_ratio(6/38.f)
```
-l, --very-descriptive-long-option Something
```
Any absolute offset `X` can be set as `X/column_width`, so provide a
ratio-based interface.
I would have prefered to give an absolute integer offset, but we still
have to preserve the functionality that does 1/3 if user changed
nothing, which means that ratio-based interface is simpler.
I don't have a good idea for the name, "short_option_ratio" might work
as well.
The setter does not sanity check that the value is in [0;1] range.
---------
Signed-off-by: Radim Krčmář <radim@krcmar.dev>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Address Issue #881, allowing use of string_view in the as<XX> method on
options.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Check the requirements first.
Previously the callbacks were done first, but with custom callbacks this
cause side effects unexpectedly.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
try some things with no standard libraries
Add arm64 and freebsd build and tests
fix a discrepancy in the handling of chars on Arm processors
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
I am starting to use CLI11 in a project and I came across an
inconvenience in code like this
```c++
const std::string description(std::format("description"));
app.add_flag("--flag", description);
```
As far as I can tell. I cannot directly use the description here. The
reason seems to be to distinguish between assignment and description. So
only `const std::string` or `const char*` and so on can be used here.
But a `const std::string &&` can not be used.
With the changes in the PR the code can also be written like this:
```c++
app.add_flag("--flag", std::format("description"));
```
The `add_flag` function can then be used with a const string or an
rvalue reference to a string.
A bit OT: I was a bit confused by this part of the existing comment ` if
a variable string is passed that variable will be assigned the results
from the flag` I think this might be wrong, but I am not sure.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Azure windows 2019 image is being deprecated, shift CI to windows-2022
and windows 2025 images
add tests for coverage and a few missing checks for duplication options.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
add mechanic for fuzzing subcommands, and several fixes for found issues
from longer fuzzer runs
This includes some issues with option group positional name ambiguity, issue with join multioption policy and config files, and a few edge cases for configuration of multiline output interpretation.
Also added complex variables to the options, no issues found from this addition.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Handle RTTI in a consistent way for locale inclusion for integral conversion.
Resolve some missing code coverage lines.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Alexander Galanin <agalanin@nvidia.com>
**Short description**
Application fails with `CLI::ConversionError` in some locales if the
application locale is set.
**Root cause**
CLI11 uses `std::stringstream` to format default value and
`strtol`/`strtod` to parse them back. The first method adds
locale-specific thousand separators but the second method parses the
number only up to the first separator. This causes an exception when the
same value is converted to string representation and then parsed back.
Examples: in _en_US_ locale 1234.56 is "1,234.56" and in de_DE locale
1234.56 is "1.234,56".
**Reproduction**
```c++
#include <string>
#include <CLI/CLI.hpp>
int main(int argc, const char **argv)
{
std::locale::global(std::locale(""));
CLI::App app{"Bug report app"};
long foo;
app.add_option("FOO", foo, "Foo option")
->envname("FOO")
->default_val(1234567);
CLI11_PARSE(app, argc, argv);
return 0;
}
```
Output:
```
$ g++ -Wall -Wextra -I CLI11/include/ cli11-bug-locale-string.cpp -o cli11-bug-locale-string
$ for locale in C en_US de_DE fr_FR de_CH; do echo "locale $locale"; LC_NUMERIC=$locale.UTF-8 ./cli11-bug-locale-string && echo OK; echo; done
locale C
OK
locale en_US
terminate called after throwing an instance of 'CLI::ConversionError'
what(): The value FOO is not an allowed value for given default value("1,234,567") produces an error : Could not convert: FOO = 1,234,567
Aborted (core dumped)
locale de_DE
terminate called after throwing an instance of 'CLI::ConversionError'
what(): The value FOO is not an allowed value for given default value("1.234.567") produces an error : Could not convert: FOO = 1.234.567
Aborted (core dumped)
locale fr_FR
terminate called after throwing an instance of 'CLI::ConversionError'
what(): The value FOO is not an allowed value for given default value("1 234 567") produces an error : Could not convert: FOO = 1 234 567
Aborted (core dumped)
locale de_CH
OK
```
**Fix description**
The fix strips group separators from the input string. This extends a
bit the logic introduced in change #968 for `_` and `'` separators.
There are no unit tests for the change because it requires to have all
mentioned locales to be installed in the system.
---------
Co-authored-by: Philip Top <phlptp@gmail.com>
continue discussion on #1149
Adds subcommand prefix matching as a modifier to CLI.
Adds an example of close matching logic for further exploration.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Additional fuzz failures from longer runs of fuzzer.
Ran the fuzzer for a couple hours. Picked up a few interesting bug particularly in the config out and return.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
add flags on the formatter to disable formatting for the description and
footer to allow things like word art or custom formatting.
One possible solution for #1145
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Adds tests and checks for Extras Error
Builds on #1158
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
CLI11 code prints the command-line arguments in reversed order in the
error message.
Code to reproduce:
```c++
#include <string>
#include <CLI/CLI.hpp>
int main(int argc, const char **argv)
{
CLI::App app{"Bug report app"};
std::string foo;
app.add_option("--foo", foo, "Foo option");
CLI11_PARSE(app, argc, argv);
return 0;
}
```
Reproduction:
```
$ g++ -Wall -Wextra -I CLI11/include/ cli11-bug-order-in-error.cpp -o cli11-bug-order-in-error && ./cli11-bug-order-in-error --foo bar --fizz buzz
The following arguments were not expected: buzz --fizz
Run with --help for more information.
```
Expected result:
```
The following arguments were not expected: --fizz buzz
Run with --help for more information.
```
Fixes#1156
For option groups removes inheritance of the footer and help option, so
those are not printed by default for option groups. It is still possible
to set them again on the option group.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
update ci build images, remove ubuntu 20.04 and update a few others, fix some newer clang-tidy warnings
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
The compiler complains about C2131: expression did not evaluate to a
constant.
https://godbolt.org/z/a198P3bdM
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
One in the fuzz check handling of NaN's and a pathway to generate a
HorribleError.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Fixes#1139
Fix a bug relating to parsing negative floating point values with no
zero before decimal point in a context where an option could be
possible.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Fixes#1135. Adds enable check to certain to_string functions as some
std::array operations were ambiguous.
The addition of the capability to convert tuples to strings created an
ambiguity in the case std::array, which acts like a tuple and a
container. So it worked with the container conversion before, but could
also work with the new tuple conversion. And we didn't have any tests to
catch this.
This PR resolves the ambiguity, and adds some tests to check that array
is handled well.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
The underlying type of uint8_t/int8_t is unsigned char and signed char,
but IOStreams was specified to treat them just like char.
so promoting the casting value to get the expected value.
Signed-off-by: ComixHe <ComixHe1895@outlook.com>
update readme, changelog, and version for 2.5 release
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
Allow trailing spaces on strings for conversions to floating point and
integers.
There was a potential confusing error that could occur if strings with
trailing spaces were converted to integer or floating point values. This
PR allows trailing spaces in the strings that would otherwise be
convertible to the appropriate numerical type.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
