summaryrefslogtreecommitdiff
path: root/indra/llcommon/stringize.h
AgeCommit message (Collapse)Author
2022-06-05Merge remote-tracking branch 'origin/DRTVWR-543-maint_cmake' into ↵Nicky
DRTVWR-543-maint_cmake
2022-04-06Move CMake files to modernized cmake syntax, step 1.Nicky
Change projects to cmake targetsto get rid of havig to hardcore include directories and link libraries in consumer projects.
2021-11-23SL-16094: Tweak llstring mergeNat Goodspeed
2021-11-23SL-16094: Merge llstring work from SL-16207Nat Goodspeed
2021-11-23SL-16094: Extend stringize() to support variadic arguments.Nat Goodspeed
It's useful to be able to say STRINGIZE(item0 << item1 << item2), and we use that a lot in our code base. But weird syntax aside, there are a couple advantages to being able to write stringize(item0, item1, item2). First, it allows stringize() to be used from within some other variadic function, without having to make that function a macro that accepts an arbitrary insertion-operator expression. There's no such thing as a member macro. Second, particularly for variadic functions, it allows us to optimize the single-argument case stringize(item0). A macro can't do that. When item0 is already a string of the desired char type, instead of streaming it into a std::ostringstream and retrieving it again, we can simply return the input string. When it's a pointer to the desired char type, we can directly construct the result string without the help of std::ostringstream. When it's a string of some other char type, we can engage ll_convert() to perform needed conversions. We generalize and optimize the generic gstringize() function, retaining the role of stringize() and wstringize() as thin wrappers that merely provide the desired char type. Optimizing the single-argument case requires separately defining gstringize() with two or more arguments: the general case. Then gstringize(arg) is delegated to a gstringize_impl class template so we can partially specialize to recognize a std::basic_string<desired_char_type> argument, as well as desired_char_type*. Both these specializations engage ll_convert(), which already handles the trivial case when no conversion is required. Use of ll_convert() in this role supercedes and generalizes the previous wstring_to_utf8str() and utf8str_to_wstring() overloads. Also introduce stream_to(std::ostream&, ...) to support variadic streaming to other destinations, e.g. a file, std::cout, ...
2021-10-27SL-16207: Update llstring.h handling of different string types.Nat Goodspeed
In llpreprocessor.h, consider the case of clang on Windows: #define LL_WCHAR_T_NATIVE there as well as for the Microsoft compiler with /Zc:wchar_t switch. In stdtypes.h, inject a LLWCHAR_IS_WCHAR_T symbol to allow the preprocessor to make decisions about when the types are identical. llstring.h's conversion logic deals with three types of wide strings (LLWString, std::wstring and utf16string) based on three types of wide char (llwchar, wchar_t and U16, respectively). Sometimes they're three distinct types, sometimes wchar_t is identical to llwchar and sometimes wchar_t is identical to U16. Rationalize the three cases using ll_convert_u16_alias() and new ll_convert_wstr_alias() macros. stringize.h was directly calling wstring_to_utf8str() and utf8str_to_wstring(), which was producing errors with VS 2019 clang since there isn't actually a wstring_to_utf8str(std::wstring) overload. Use ll_convert<std::string>() instead, since that redirects to the relevant ll_convert_wide_to_string() function. (And now you see why we've been trying to migrate to the uniform ll_convert<target>() wrapper!) Similarly, call ll_convert<std::wstring>() instead of a two-step conversion from utf8str_to_wstring(), producing LLWString, then a character-by-character copy from LLWString to std::wstring. That isn't even correct: on Windows, we should be encoding from UTF32 to UTF16.
2018-05-17SL-821: Add WSTRINGIZE() and DEWSTRINGIZE() macros for wide strings.Nat Goodspeed
Streamline convenience overload stringize(std::wstring); make convenience overload wstringize(std::string) symmetrically convert from UTF-8 string. Also eliminate STRINGIZE() et al. dependency on Boost.Phoenix: use lambdas instead. Using lambdas instead of template expansion necessitates reordering some code in wrapllerrs.h.
2015-11-10remove execute permission from many files that should not have itOz Linden
2015-01-16Continue gradually replacing Boost.Lambda with Boost.Phoenix.Nat Goodspeed
For some reason, after the upgrade to Boost 1.57, gcc 4.6.3 has trouble with the boost::lambda::_1 usage in stringize.h. This is consistent with other cases we've encountered in which Boost.Lambda appears to be unmaintained and losing its compatibility with other libraries. Fortunately Phoenix provides a functional equivalent, albeit spelled differently.
2014-04-07merge with releaseRichard Linden
2014-01-14Some cleanup of string to wstring conversion and vice versa.Aura Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2009-06-10Added LLAPRSockStream class and associated LLAPRSockStreambuf class forBrad Kittenbrink
DEV-31978 viewer event host socket module. reviewed by palmer+nat+mani.
2009-05-08svn merge -r114679:114681 ↵Nat Goodspeed
svn+ssh://svn.lindenlab.com/svn/linden/branches/event-system/event-system-7 svn+ssh://svn.lindenlab.com/svn/linden/branches/event-system/event-system-8