* Fix#458: Support std::string_view interop with ChaiScript strings
Register std::string_view as the "string_view" user type with a built-in
implicit conversion from std::string, so a ChaiScript string can be passed
directly to a C++ function taking std::string_view. Adds the reverse
explicit conversion via string(sv) / to_string(sv), plus basic queries
(size, length, empty, data) and comparison operators on string_view.
String-style methods that take size_t (substr, find, ...) are intentionally
not duplicated on string_view: with the implicit conversion in place they
would create dispatch ambiguity for calls like string.substr(int, int).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Address review: expand string_view binding with substr/find/[]
Adds substr, find/rfind/find_first_of/find_last_of/find_first_not_of/
find_last_not_of, starts_with/ends_with, and operator[] to string_view_type,
mirroring string_type's search/substring surface so script authors can
traverse a buffer through string_view without allocating.
Sharing method names with string_type creates an ambiguity in
dispatch_with_conversions when the script call needs arithmetic conversion
(e.g. myString.substr(int, int)): both string::substr and string_view::substr
match-except-for-arithmetic, and the existing const/non-const tiebreaker
doesn't apply. Extend dispatch_with_conversions to prefer the candidate
whose first/receiver parameter type exactly matches the actual receiver,
mirroring the deprioritization already in dispatch(). With this in place,
myString.substr(1, 2) still resolves to string::substr while
mySV.substr(1, 2) resolves to string_view::substr (returning a string_view).
Updates the doc comment on string_view_type and adds a compiled test that
locks in both dispatch directions plus the new search/substring methods.
Requested by @lefticus in PR #697 review.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: leftibot <leftibot@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add a native find() method to unique associative containers (e.g., Map)
that returns the mapped value if the key exists, or an undefined
Boxed_Value if not. This allows checking for key existence without
mutating the container (unlike operator[]) or requiring exception
handling (unlike at()).
Co-authored-by: leftibot <leftibot@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Several STL bootstrap functions unconditionally instantiated copy-dependent
operations (copy constructor, assignment, push_back/push_front by const ref,
insert_at, and resize with fill value), causing compilation failures when
registering containers of move-only types like std::unique_ptr. Guard these
operations with if constexpr(std::is_copy_constructible_v<value_type>) so they
are only compiled when the element type supports copying.
Co-authored-by: leftibot <leftibot@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Jason Turner <jason@emptycrate.com>
I initially tried to use the existing .clang-format file,
but it does not match the code style (at least with clang-format 11)
and the formatting is not consistent across files.
Therefore, I decided to rewrite the .clang-format with some personal
preferences.
Used command
find . -iname "*.hpp" -o -iname "*.cpp" | xargs clang-format -i -style=file
This modifies no logic, it simply adds the keyword `noexcept`
I believe this is 100% correct. It calls methods that are not
guaranteed to be `noexcept`, such as `operator[]` but have
no logically way of throwing.
Since use of (one of) the functions in bootstrap_stl.hpp is in a
sample, chances are there are people using them in real world
application code. Thus the backwards compatible versions.
The std::is_member_function_pointer<> template is broken on this version
of the libc++ standard library for const member functions.
To get ChaiScript to work with this, we had to work around the use of
automatically generated std::function wrappers in many cases. This
actually cleaned up the code in a few places and muddied it up in one.
This still has some exceptions thrown during the loading of modules
since I have no way of knowing where the operating system
`dlopen` and `LoadLibrary` functions will search for me to pre-check
it.
Closes#158
