GitLab

* Fix serialize variant with C++17

* fix order of parameters

* added support for std::optional if using C++

* oops, bug fix + check if item already holds a type

* oops, another bug fix

* remove warnings about unused parameters
Co-authored-by: pf <pf@me>

* [SERIALIZATION] addes support for std::variant

* [SERIALIZATION] bug fix + added tests

* support immutable types

* put an immutable type in std::variant
Co-authored-by: pf <pf@me>

* [SERIALIZATION]	- vectorstream can now be used with vector<int8_t> and vector<uint8_t>

* [SERIALIZATION]	- update proxy_serialize and proxy_deserialize to work with vector<int8_t> and vector<uint8_t>

* [SERIALIZATION]	- updated vectorstream tests

* [SERIALIZATION]	- updated serialize tests. check you can go to and from any of vector<char>, vector<int8_t> and vector<uint8_t>

* [SERIALIZATION]	- updated matrix tests. check you can go to and from any of vector<char>, vector<int8_t> and vector<uint8_t>

* [SERIALIZATION]	- updated dnn tests. check you can go to and from any of vector<char>, vector<int8_t> and vector<uint8_t>

* [SERIALIZATION] improved and possibly safer

* [SERIALIZATION] use placement new. best of all worlds i think. we have least object overhead. but code looks a tad uglier. oh well, user doesn't have to care

* [SERIALIZATION] i hope this is easier on the eyes.
Co-authored-by: pf <pf@pf-ubuntu-dev>

* [SERIALIZATION] fixed bug when (de)serializing vector<complex<float>>. DLIB_DEFINE... macro uses __out and __in variables names for ostream and istream objects respectively to avoid member variable name conflicts.

* Refactoring objects in DLIB_DEFINE_DEFAULT_SERIALIZATION to avoid name conflicts with user types

* Refactoring objects in DLIB_DEFINE_DEFAULT_SERIALIZATION to avoid name conflicts with user types

* removed tabs

* removed more tabs
Co-authored-by: pf <pf@pf-ubuntu-dev>

* [DLIB]  STL containers

* [DLIB]  STL containers

* [DLIB] applied code corrections suggested by code review

* [DLIB] applied code corrections suggested by code review

* [DLIB] applied code corrections suggested by code review

Extended proxy_(de)serialize objects to work with stringstream, ostringstream, istringstream and vector<char> (#2181)

* [DLIB] extended proxy objects to work with strinstream, istringstream, ostringstream and vector<char>

* [DLIB]  - use std::istream and std::ostream instead of std::istringstream, std::ostringstream and std::stringstream.
		- put back the filename member variable for better error messages

* [DLIB]  - review requirement
Co-authored-by: pf <pf@pf-ubuntu-dev>

* [DLIB] macro for generating default serialisation functions

* [DLIB]  refactoring

* [DLIB]  refactoring

Co-authored-by: Hartwig <git@skywind.eu>

Set istream flags to 0 in old_deserialize_floating_point.  This was flagged by [[nodiscard]] warning in MS compiler.

* Replace shared_ptr/weak_ptr with stdlib counterparts

* Fix ptr usage through tests compilation

* Bring back dlib smart ptrs as legacy

* Include scoped_ptr directly

* Add explanation about smart_ptr deprecation

byte.  This makes their serialization format the same as the format for std::string.  I had
to revert the previous mod for this because it didn't work in visual studio.  This change
fixes that.  The code should still be able to read all previously serialized data correctly.
Moreover, any char arrays that aren't null terminated will still be read and written in
their entirety.

serialized using the same format as std::string.  Previously, the
trailing 0 was also saved so if you deserialized them into a std::string
you ended up with a trailing 0 in the std::string which isn't what you
want.

opening files in binary mode.  Oops.  This is now fixed.

serialized.

Previously, we used an ASCII based format.  It now uses a much more efficient
binary format.  The deserialization routines have been made backwards
compatible with the previous format.  So dlib can still deserialize older data
but older software won't be able to read the new format.

or std::vector<unsigned char> were serialized.

times faster.  The behavior should be exactly the same.  The change is basically just
a switch to using the streambuf directly.

integer instead of the usual dlib variable width encoding.

as well as the normal version.

Google protocol buffer objects.

characters to take advantage of the fact that you can just write
the contents of memory out in this case.

doesn't store it's data in a contiguous block.  However, that isn't quite the case.
See this discussion:
http://stackoverflow.com/questions/1986966/does-s0-point-to-contiguous-characters-in-a-stdstring

Anyway, I changed deserialize() for std::string to be more efficient and read
directly into the string rather than into a contiguous buffer and then do a copy.

--HG--
extra : convert_revision : svn%3Afdd8eb12-d10e-0410-9acb-85c331704f74/trunk%404235