As not defining operator<<() overload taking wxScopedCharBuffer in the
global scope prevents it from being considered as an overload resolution
candidate (which is, of course, the whole point), it also prevents it
from being used for the classes convertible to it, such as wxCharBuffer,
so we need to define operator<<() overloaded for the latter explicitly
too.
We also need a new wxScopedCharTypeBufferStreamSupport helper in order
to define different operators inside different specializations of
wxScopedCharTypeBuffer<>.
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.
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
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.
For some reason gcc considers "this" pointer to a temporary object
dangling, which seems to be incorrect, as the pointer is reset when the
temporary is destroyed from its dtor, so just suppress this warning to
avoid getting tons of them in the optimized builds using this compiler.
This buffer class can avoid copying strings entirely in UTF-8 build, as
it can write directly to the storage provided by the underlying
std::string, and it also needs to keep the contents in UTF-8, instead of
converting it from the current locale encoding, which was at best
useless, and ensure that it is correct, which is necessary with at least
MSVC, as its CRT can return invalid UTF-8 strings even when using this
encoding.
This finally fixes "PrintfError" unit test under MSW.
Now that we use C++11 there is no need to have our own Shrink()
implementation when we can just use the standard function.
Also mention that it's the same as shrink_to_fit() in Shrink()
documentation.
No real changes, just simplify the code and make it more efficient.
Destroying an iterator with a lifetime greater than that of the
associated string resulted in an invalid memory access due to using the
linked list of string iterators in the iterator dtor.
Fix this by clearing all the associated iterators when the string itself
is destroyed.
This fixes ASAN errors in wxDateTime::ParseDateTime() where "endTime"
const_iterator was destroyed after the destruction of the associated
"timestr" after successfully parsing the date.
Don't declare static Cache variable inside wxString declaration itself
because it is implicitly DLL-exported, due to the use of
__declspec(dllexport) for the entire wxString class, but thread-specific
variables can't be exported, so this resulted in a compilation error.
Avoid this by using a static thread-specific variable inside GetCache(),
which had to be moved out of line.
Add an explicit cast from ptrdiff_t to unsigned int to avoid the
warning which is harmless because the difference here is bound by the
cache size.
See #23297.
This avoids some spurious -Wmaybe_unitialized warning when using
`std::optional<wxString>` with gcc and is also generally better practice
as it ensures that the fields are always initialized correctly.
Closes#23167.
Update some comments and prefer using #if/#else when testing for
wxUSE_UNICODE_UTF8 and wxUSE_UNICODE_WCHAR rather than #if/#elif as
exactly one of them is always defined now. Similarly, test for
wxUSE_UNICODE_WCHAR directly instead of testing !wxUSE_UNICODE_UTF8 and
vice versa.
It could be nice to actually test for just a single one of these symbols
everywhere, but this would require a lot of noisy changes, so for now
keep the code as is.
No real changes, just simplify.
Don't use std::index_sequence, as this has some advantages:
- This way doesn't require using another helper function, which is
burdensome here and would be even more so if we had to do it for all
the other wx vararg functions too.
- We don't need to require C++14 and can keep supporting even g++ 4.8.
The sole drawback is that we cannot pass the index of the argument to
wxArgNormalizer ctor any longer, which means that we can't validate it,
but this is addressed by validating the entire format string at once in
the new Validate() member function, which is also more efficient than
the old way for the format strings with more than one format specifier,
as they only need to be parsed once now, instead of having to do it for
each format specifier separately when GetArgumentType() is called.
This also means that we can't handle char arguments differently
depending on whether they are used with "%c" or "%d" format specifier.
This is a backwards-incompatible change, but should affect very few use
cases, so it seems to be worth breaking it to get the above benefits.
The argument of these functions will have to be converted to
wxFormatString anyhow in Printf(), so take it directly, as this at least
means that only a single conversion will be done, when Format() is
called, instead of converting whatever is passed to it to wxString
before converting this wxString to wxFormatString.
Always use thread_local as we can rely on compiler TLS support working
under Windows 7 and later.
There are some known problems in MinGW thread local variable support,
but they only affect (obsolete) 32-bit builds and will hopefully be
fixed in this compiler soon.
See #22917.
This addresses a FIXME comment in this template, it was written in a
generic form to compile in both Unicode and ANSI builds of the library,
but now it can be written more simply and efficiently (in the "char"
case).
No real changes.
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.
Still use wxTHREAD_SPECIFIC_DECL as it is defined as nothing when
wxUSE_THREADS==0, but get rid of wxTLS_VALUE and friends.
Also enable wxUSE_STRING_POS_CACHE when wxUSE_UNICODE_UTF8 because the
issues described in the (now also removed) comment shouldn't occur with
the compiler implementation of the thread-specific variables.
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.
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.
There is no need to check for the weird case of using a C++11 compiler
with C++98 standard library any longer, this is not supposed to happen
and we don't support macOS < 10.7 since a very long time anyhow.
This adds a yet another conversion function, which is not ideal, but
still better than having to write ToStdString(wxConvUTF8) every time for
losslessly converting wxString to std::string: not only this is too
long, but it's also too easy to forget to specify wxConvUTF8, resulting
in data loss when using non-UTF-8 locale.
