Header-only library providing unicode aware string support for C++

LINK : warning LNK4044: unrecognized option '/Wl,--no-undefined'; ignored

In cmake the compiler ID is the most robust way to identify the compiler used. E.g. <$<CXX_COMPILER_ID:MSVC>:/wd4715>

MSVC warnings: 'argument': conversion from 'CsString::CsStringIterator<E,A>::size_type' to 'int'

'walk' takes an int as first argument. E.g. here: template <typename E, typename A> CsStringIterator<E,A> &CsStringIterator<E,A>::operator+=(size_type n) { m_iter += E::walk(n, m_iter); return *this; }

in

walk(int len, std::vector<storage_unit>::const_iterator iter)

Over here: https://en.cppreference.com/w/cpp/string/basic_string_view they say:

std::string_view good("a string literal"); // OK: "good" points to a static array std::string_view bad("a temporary string"s); // "bad" holds a dangling pointer The first example is not working with CsStringView.

This seems implicitly to violate the boundaries of the data structure you're iterating over, which would lead to invalid inputs causing crashes. For example, seeking 3 characters forward in a 3-code unit / 1 code point string would exceed the string length & read undefined memory.

There seems to be an error in the documentation of the constData() method: it should have return type "const typename E::storage_unit *" and not "void".

From https://www.copperspice.com/docs/cs_string/class_csstring_1_1csbasicstring.html#ac353b4a5bfcdfde79571314d373fbd04

template<typename E, typename A = std::allocator> void CsString::CsBasicString< E, A >::constData() const

Returns a pointer to the null terminated data stored in this CsBasicString. The pointer is valid until the string is modified.

Hi I know you by my teacher I am happy to know you are there

Could you please open a Discussion Section as a quick and safe solution for learning your projects ?

See you there

CsString has some inconsistent use of int and size_t. E.g. here: int walk(int len, std::vector<storage_unit>::const_iterator iter)

What is the idea behind using the namespace CsString? Does the statement using namespace CsString; not lead to name conflicts with the class?

CsChar is not exported on Windows. class CsChar { ... }; in file cs_char.h

Does the statement below create a temp. CsString? CsString::CsStringView text{ "hello" }; If yes then any further use of 'text' will cause problems.

Cmake Visual Studio C++ does not have the option -wl

The header files are not included in the project, but this is helpful for IDEs that support header files in the project (e.g. CLion, Visual Studio).

Best regards Thomas Krenn

Not sure where else to put this information, feel free to just close it if its in the wrong place.

Here's what's installed

12:10:13 [email protected]:~/src/cs_string (git:master:bf347f4) ruby-2.4.1 $ g++ --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin16.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Here's the build output

$ make check /Applications/Xcode.app/Contents/Developer/usr/bin/make check-am /Applications/Xcode.app/Contents/Developer/usr/bin/make bin/test g++ -DPACKAGE_NAME="cs_string" -DPACKAGE_TARNAME="cs_string" -DPACKAGE_VERSION="1.0.0" -DPACKAGE_STRING="cs_string\ 1.0.0" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE_URL="" -DPACKAGE="cs_string" -DVERSION="1.0.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DSIZEOF_SIZE_T=8 -DQT_SHARED -I./src -DCS_STRING_ALLOW_UNSAFE -g -O2 -std=c++11 -MT test/bin_test-main.o -MD -MP -MF test/.deps/bin_test-main.Tpo -c -o test/bin_test-main.o test -f 'test/main.cpp' || echo './'test/main.cpp test/main.cpp:100:28: error: character too large for enclosing character literal type CsString::CsChar c127 = '¿'; ^ test/main.cpp:104:28: error: character too large for enclosing character literal type CsString::CsChar c256 = '↴'; ^ test/main.cpp:110:26: error: character too large for enclosing character literal type CsString::CsChar cX = '𝅘𝅥𝅮'; ^ 3 errors generated. make[2]: *** [test/bin_test-main.o] Error 1 make[1]: *** [check-am] Error 2 make: *** [check] Error 2

Remarks

Given the structure of test_o2, it might be worthwhile separating these cases (CsString::CsChar c127 = '¿';) from the CsString::CsChar u127 = UCHAR('¿');. That is, collect the known bogosity into its own test.