connectivecpp / utility-rack Goto Github PK

The shared_buffer.hpp classes (mutable_shared_buffer and const_shared_buffer) are better grouped with the marshall facilities, since that is what they are specifically designed for. The utility directly is for more general purpose functions and classes.

The unit tests can be enhanced by processing command line arguments. This will allow unit testing with variable amounts of generated data.

All casts should be C++ style, and in general, casting should be avoided (i.e. every cast needs to be analyzed as to why it is there). Data into and out of network buffers (e.g. going into or out of a shared_buffer) should be serialized, rather than "cast in place".

There are multiple enhancements and improvements needed in our CMake files:

• CMake find_package commands need to be fully implemented, and improvements made to the current design. In particular, we should have a modern and consistent approach to our dependent libraries (Asio, Catch2, etc).
• Options for debug and release (optimized builds) need to be implemented.
• Options for sanitizers, profilers, etc, need to be implemented.
• A more consistent CMake design should be implemented, specially in the common CMake code.

Currently (Apr 2019) the only Boost dependency in the utility-rack repository is in the wait_queue_test and shared_buffer_demo.cpp. The wait_queue_test can be changed to use a different circular buffer, and the shared_buffer_demo app can be changed to use the utility marshalling facilities.

A good quality circular buffer to test with (in addition to Martin's ring-span-lite) is:

https://github.com/JustasMasiulis/circular_buffer

It is a high quality, STL style, single header container.

While Boost is an excellent, high quality set of libraries, it simplifies utility-rack dependency management not to have it as a dependency.

There is significant common code in the CMake files which needs to be split out and included as appropriate. Some of it spans multiple repositories so it may make sense to have the master versions in a special place in the utility-rack repository.

The demo programs need to be const correct. Methods that do not modify object data need to be const qualified, and literals need to be const or constexpr, as appropriate (with constexpr preferred). Parameters to functions that are not modified or passed by value should be const qualified.

The demo programs are missing includes, they happen to compile because "gift includes" many other headers. Specifically (and this is not inclusive):

EXIT_SUCCESS:
std::string:
u_int64_t: should be std::uint64_t, the header is
std::byte:

Create functions to marshall and unmarshall a variable length integer. The "append" / marshall function will take an integer in native format, and create a 1 or 2 or 3 or 4 (or more) byte integer. The first byte will contain values from 0-127, and the MSB (most significant bit) will designate whether another byte is needed (for larger values). The "extract" / unmarshall function will perform the converse.

One usage of this will be in the MQTT wire protocol (see section 1.5.5 of the MQTT 5.0 spec).

A good place for these functions is in the "extract_append_val.hpp" header in the marshall directory of the utility-rack repo.

Group the example applications by using the following doxygen command at the top of each source file:

@InGroup example_module

This will generate more organized doxygen documentation.