Hello Seth Thanks for your attention and questions. Independency designed to be acceptable for use in large scope of the project, including embedded and safety critical software. These two kinds of the projects are painful in maintainance. 1) Independency does not support strings because it requires dynamic memory. In other words it accepts the "primitive" classes only. This is done because in many cases dynamic memory is unsertifiable. The library doesn't use anything that may harm possible certification process for end user. But instead of it user may send the pointer to the string literal.2) Yes, I used not so good term in the docs, but generally it means you can send a message to the code that you actually can reach by the including or providing somehow the reference or pointer to it, but with Independncy it may be done way easier. You can't send this message to the network, or to the another process, or from kernel to the user space, and so on. How do you think what may be better and short term to describe the scope I described above?3) Yes, it is, just another name for prehistorical standard that people still forsed to use due safety requirements. Yes, it definitely repeats some patterns from the typical ANSI C code, but exactly void pointer for argument is similar to the FLTK GUI framework. If it's the critical issue I may try to fix it somehow, but I have a doubt is there any simple solutions that may pass -std=c++98 in gcc, Clang or MSVC's alternative to this flag.4) The library doesn't relate to the state machines, it needs for the data propagation only. The code of example for a first glance looks like a state handling, because the same patterns used there, but the nature is completely another. Here, we divide all of the device functionality to the modules and define the format and the sequence of the data exchange between them. This why the modules have no dependencies between them, they're all depends on data exchange protocol and the message bus library. This why it called Independency. This is just one of many techniques to organize the codebase and reduce dependencies between modules. Have a nice day! Sincerely,Artem Shapovalov. On Sun, May 4, 2025 at 20:11, Seth via Boost<boost@lists.boost.org> wrote: On Wed, Apr 30, 2025, at 10:53 AM, Artem Shapovalov via Boost wrote:
Hello Boost dev community. Hope you are doing well and I'm doing right. I want to make my small contribution with my small library. It's a minimalistic implementation of a message bus that may connect together the pieces of code inside the same binary. Idea is: bring a microservices-like approach and the Publish-Subscribe pattern into a micro-level and allow all of the people not to reinvent the bicycle. Several times, I've re-implemented it because it's useful and had no reference implementation, and this is why I finally decided to make it, and I did. Here, you may check it out, it's generally satisfy some standards of Boost: https://github.com/Artem-Shapovalov/Independency Thanks for your attention. I hope you'll like it and find it useful and worth for Boost Libraries' family. Sincerely,Artem Shapovalov.
Very quickfire notes after scanning the repository: - “not supporting strings” is probably a restriction that extends to more types? What are the type restrictions? - “communication within the same binary” presumably means “intra-process”. If not what does “binary” refer to? - ANSI C++ presumably means ISO C++. Ironically, a lot of the code smells like ANSI C alright (static void hnd taking void* for example…). - the example skirts state machines. what is the relation of this bus design to state machines? How does it differentiate from Boost SMS and Boost SML? Why would one use Boost Independency over those? Regards, Seth
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost