Now that there is a subclass of boost::uuids::uuid, that subclass can be
used for GncGUID implementation. This removes the need for the untidy
casts to/from bost::uuids::uuid, and simplifies the logic in many areas.
Although we test libgtest_main, we don't test for libgmock_main. This
shouldn't be necessary since gmock was absorbed by gtest in upstream,
so I'm not planning on working hard to correct this problem robustly.
We'll just check for the source files in the other location where they
might be.
Adding google tests for many of Kvp Frame's member functions. One
function in KvpFrameImpl, for_each_slot, should probably be something
like
template <typename T> void
for_each_slot (T & t, void * data) const
{
std::for_each(......
[&t, data] (... a)
{
t(a, data);
}
}
This way, we could create a functor mock object for testing purposes,
but of course, pointers would still behave correctly.
KvpFrame was implemented using GList. Given the current desire
to distance ourselves from glib and acquaint the project with
C++, the standard library thereof, and boost libraries, KvpFrame
has been replaced by an implementation that uses a std::map<
const char *, KvpValueImpl *>.
There were some cases of the KvpFrame's glist being accessed
directly. A new API to help callers access the KvpFrame's contents
systematically by providing a list of keys has been created, and
call sites of the GList code have been updated.
Another deprecated #define was found and removed (kvp_frame_set_str).
kvp_frame should not be used by C code, but rather the standard
KvpFrame. The deprecated value just adds one more name for this
class that doesn't add any value.
KvpValue is now instantiated as a boost::variant and passed around as an opaque
pointer in C. The C interface is basically unchanged and a c++ interface exists
in kvp-value.hpp
The c++ implementation for KvpValue is called KvpValueImpl and is in kvp-value.cpp.
We don't use structured exception handling at this point, so c++ functions are
marked 'noexcept'.
The logic is within the c++ implementations. C wrapper functions do little besides
ensure that the pointer is not nullptr before calling into c++.
The logic in kvp_value_glist_to_string was moved to the c++ class. It's an
implementation detail, but unfortunately, it was being exposed through a pointer,
so I had to modify the test just a bit to not use it directly.
In order to work around what seems to be a bug in an Apple compiler, it was decided
to create an header file private to kvp-value and kvp_frame that holds the definition
of KvpFrame so that it was visible to both translation units.
This change applies some recommendations from jralls. It better utilizes for loops,
and usage of swap. We also try to make sure the null guid is not freed since it's
reused, and catch a c++ exception to make sure it doens't escape into C code when
parsing a GUID.
Previously, guid_to_string had been marked deprecated with a note about
it not being thread-safe. It was much worse than "not thread safe", it
was only safe in a particular situation, and its safety was being violated
throughout the code. It was clear that users of guid_to_string did not
understand what it was purporting to do because of its varied uses. Most
uses simply treated it like a Garbage-Collected Java String (use and forget).
I actually found at least one instance where the string was being freed. (!!!)
I made the method have a particular easy-to-understand semantic: it returns
a pointer to a string which must be freed by the caller. I then tried to
track down all uses of this function and correct them. Mostly, I just changed
the usage to guid_to_string_buff with a stack-allocated string to avoid the
the malloc/free cycle.
To allocate a GUID, use guid_malloc. To allocate and construct a guid
(which is actually unique), use guid_new (and be sure to free it using
guid_free).
`new` implies some allocation. Since guid_new was actually constructing
a guid in place rather than allocating it, it makes much more sense to
call it guid_replace (or guid_construct). We went with guid_replace.
Since we're maintaining a C api, the implementation is sometimes less than
intuitive from either a C or C++ perspective. I am trying to use as much
boost as possible while making all the guarantees that the C code makes.
One function was declared deprecated because it "wasn't thread safe". This
was straightforward to repair, and is no longer marked deprecated, and there
are now two ways to convert GUID to String: passing your own character
buffer, and having one returned to you that you need to free.
The plan is to change gnc guid to use boost's guid implementation. There were
no tests for guid before, but we need them to ensure that we don't have regressions
when that work begins.
lmat