This makes the code more readable and there should be no reason not to
use UTF-8 in string literals any longer.
Also replace wxHAVE_U_ESCAPE (all still supported compilers have it)
with wxMUST_USE_U_ESCAPE, which is only set for MSVS 2015 currently and
will be removed when we drop support for it and can use literal Unicode
characters in the wide strings everywhere.
This fixes a typo resulting in build failure from the recent b9726c02d5
(Disable sporadically failing test in MSVS 2019 CI build, 2025-05-09).
See #25056.
This doesn't work because the CRT always uses CP_ACP for converting and
if the current locale encoding is not UTF-8 (which is not the case for
this test), it doesn't work for arbitrary Unicode strings.
Document this limitation as well as the recommended alternative.
This uses different code path than wxGetEnv(wxString) and while it would
probably be better to somehow avoid this, for now just make the same
changes to this function as were made to the other one in the parent
commit.
This is a much more reasonable conversion to use than the current locale
encoding for the values defined outside of the program and we can still
fall back to the latter if using UTF-8 doesn't work by using
wxConvWhateverWorks.
Also use the same approach for the user name.
This didn't work correctly before, but there doesn't seem to be any good
reason to not allow this, as it allows to naturally extract some leading
prefix from a string and it also already worked for BeforeLast(), so
make it work for BeforeFirst() too.
All supported platforms provide 64-bit integer types since many years,
so remove the legacy wxLongLongWx implementation and rename
wxLongLongNative to just wxLongLong and always compile it in.
Note that wxLongLong itself must still be kept for compatibility as it
has member functions, such as GetValue() or ToString(), that can be used
in the existing code.
The previous ToCDouble() function accepted leading spaces, a starting +
sign, and hex strings. std::from_chars() does not accept spaces or +,
and requires a special flag to convert hex strings, so handle this
manually to preserve the old behaviour of this function.
This is similar to the changes done for ToCULong() in #24022.
Closes#24089.
Replace user-specified empty constructors and destructors with the
compiler-generated versions, which has a number of advantages for code
generation, in addition to being more clear.
Closes#22965.
Closes#24058.
Unlike the traditional C functions, std::from_chars() doesn't skip
leading whitespace and doesn't accept the leading "+" sign, so we need
to skip them explicitly to preserve the behaviour of ToLong() in the
previous wxWidgets versions.
Do use std::from_chars<unsigned long>() in it as otherwise values
greater than LONG_MAX failed to parse.
Handle negative numbers explicitly to still parse them in this function
as well, as needs to be done for compatibility.
Add a test case for the previously failing numbers.
Closes#23957.
Make the wxString(std::string_view) constructor explicit.
Otherwise, when comparing a std::string_view with a const char *, the
cast to wxString will be considered as a candidate for the comparison,
ultimately causing an "ambiguous overload for 'operator=='" error.
For example, this sample only builds if the constructor is explicit:
#include <wx/string.h>
#include <string_view>
int main() {
std::string_view view = "abc";
const char *str = "abc";
return view == str;
}
However, making the constructor explicit will break assignment:
std::string_view view = "abc";
wxString s;
s = view; // Error: no match for "operator="
That we can fix by implementing operator=(std::string_view)
That, however, introduces another ambiguity:
std::string str = "abc";
wxString s;
s = str; // Ambiguous between s = wxString(str)
and s = std::string_view(str)
That we can fix by implementing operator=(std::string)
Finally, note that some rather obscure ambiguities remain, such as:
wxString s;
s = {"abc", 2}; // Ambiguous between s = wxString("abc", 2)
and s = std::string_view("abc", 2)
Avoiding them is not simple (https://cplusplus.github.io/LWG/issue2946)
and doesn't add much value.
Closes#23834.
Newer standard library headers should only be included when the compiler
is targetting that standard, otherwise some compilers (like MSVC) will
warn that you are using a newer C++ include on an older version.
This symbol is similar to the existing wxNO_IMPLICIT_WXSTRING_ENCODING
and can be defined when building the application (as opposed to when
building the library) to disable implicit wxString conversions to
pointer types, i.e. char*, wchat_t* and void*.
This makes the just added wxUSE_CHAR_CONV_IN_WXSTRING library build
option unnecessary, so remove it.
This doesn't really change anything, but allows to simplify the tests,
as we can now check only for wxNO_UNSAFE_WXSTRING_CONV and this covers
both the case of the library compiled without support for the unsafe
conversions at all and the case when the conversions are disabled by
explicitly defining wxNO_UNSAFE_WXSTRING_CONV when building the
application.
wxString is always based on std::[w]string since 2c0c727f49 (Remove wx
own wxStringImpl implementation, 2022-11-16) and all containers use
standard containers by default too now -- and there is a separate
wxUSE_STD_CONTAINERS for this anyhow.
The only remaining use of wxUSE_STL was as the default value for
wxUSE_STD_STRING_CONV_IN_WXSTRING option, but it's not really needed
for this neither, and this option can just be set to 0 by default.
Also add wxUSE_CHAR_CONV_IN_WXSTRING which can now be set to 0 too to
disable all unwanted implicit conversions (even "safe" ones, to wide
strings, in addition to the unsafe ones to narrow strings that could be
already disabled with wxUSE_UNSAFE_WXSTRING_CONV) to allow people who
don't want to have any implicit conversions at all to do it.
Keep --enable-stl configure option for compatibility, but warn if it is
used to tell people that it is not needed any longer.
Such functions modifying errno is undocumented, and may come
as a surprise to the caller. Consequently also a call to
wxString::Format() would modify errno.
We now assert if not enough arguments are given to a vararg function, as
we can actually do it when checking it all at once, unlike before when
we only checked for the matching format specifier for each argument, so
add a test verifying that this works as expected.
Assume they are always 1 now, there is no good reason to ever set them
to 0 any more.
Note that we still keep wxUSE_STD_IOSTREAM for now, but we can drop
wxUSE_STD_DEFAULT as it's not worth having it just for this single
option (previously it was used as the default value for 3 of them).
Some wxString functions using wide strings still took wxMBConv just for
consistency with the same functions taking narrow strings in ANSI build,
but this doesn't really make sense any longer because the same code
can't be compiled with different values of wxChar -- it is always the
same thing as wchar_t now, and so we shouldn't pass unused conversion
objects to these functions any more.
So give deprecation warning when these functions are used (but without
formally deprecating them, as it doesn't cost much to keep them) and
avoid using them in the library code.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
Simplify the code checking for _MSC_VER or __VISUALC__ or using
wxCHECK_VISUALC_VERSION() macro (which is not very useful any longer,
but keep it in case we need it again in the future).
Don't bother checking for various C++11 features that are available in
all C++11 compilers.
Also assume that std::exception_ptr is available in all still supported
MinGW versions and remove checks for it too (see #16634).
Further simplifications remain possible, this is just the first step.
At least under FreeBSD, vsnprintf() doesn't work with Unicode strings in
non-UTF-8 locales (but just returns EILSEQ), so set such locale before
using it.
Vadim Zeitlin
Lauri Nurmi
Ian McInerney
Joan Bruguera Micó
Ian McInerney
Pavel Tyunin
Artur Wieczorek