univalue: Avoid std::string copies #25714

In commit "univalue: string_view test" (fa67d7cafccb88b508e4eecdd9d66c2582647851)

Would be exciting to check that it handles non-nul terminated strings, and embedded nuls correctly, too:

diff --git a/src/univalue/test/object.cpp b/src/univalue/test/object.cpp
index 02bcb5b7074..34b1c1cec48 100644
--- a/src/univalue/test/object.cpp
+++ b/src/univalue/test/object.cpp
@@ -162,10 +162,11 @@ void univalue_set()
     BOOST_CHECK_EQUAL(v.getValStr(), "zum");
 
     {
-        std::string_view sv{"abc"};
+        std::string_view sv{"ab\0cd", 4};
         UniValue j{sv};
         BOOST_CHECK(j.isStr());
-        BOOST_CHECK_EQUAL(j.getValStr(), "abc");
+        BOOST_CHECK_EQUAL(j.getValStr(), sv);
+        BOOST_CHECK_EQUAL(j.write(), "\"ab\\u0000c\"");
     }
 
     v.setFloat(-1.01);

Thanks, done

In commit "univalue: Avoid std::string copies" (fa1ce3ab42fd5fd761b934b8db9fbf9f78bde842)

Probably doesn't matter in practice, but it seems like it could be less work for the compiler to call the default string constructor instead of the char* constructor

diff --git a/src/univalue/include/univalue.h b/src/univalue/include/univalue.h
index 54c60cada9a..6ef60b16e29 100644
--- a/src/univalue/include/univalue.h
+++ b/src/univalue/include/univalue.h
@@ -20,7 +20,7 @@ public:
     enum VType { VNULL, VOBJ, VARR, VSTR, VNUM, VBOOL, };
 
     UniValue() { typ = VNULL; }
-    UniValue(UniValue::VType type, std::string str = "") : typ{type}, val{std::move(str)} {}
+    UniValue(UniValue::VType type, std::string str = {}) : typ{type}, val{std::move(str)} {}
     template <typename Ref, typename T = std::remove_cv_t<std::remove_reference_t<Ref>>,
               std::enable_if_t<std::is_floating_point_v<T> ||                      // setFloat
                                    std::is_same_v<bool, T> ||                      // setBool

Thx, done

In commit "univalue: Avoid std::string copies" (fa1ce3ab42fd5fd761b934b8db9fbf9f78bde842)

Not sure if this was intended, but this is breaking the pattern of calling all setXXX arguments val

Yes this is intended. Note that the argument are named inconsistently val, and val_. Happy to change to something other than str, maybe val_in? Though, I think the args should be named the same in the header file as they are in the cpp file.