buffer inside another container? about mlib HOT 8 CLOSED

As you may have noticed, the last lines of m-buffer are:

// NOTE: SET & INIT_SET are deliberately missing. TBC if it the right way.
// NOTE: There is no oplist defined for this container.

In fact, the queue as a synchronization should be a global variable. so I was thinking if it made sense to encapsulate it into another container? But maybe for tuple, it makes sense and I am overthinking :)

from mlib.

I got several threads that share a bunch of structures (to be accessed in a safe way). They are not defined as global variables as I don't like their use (except when it is strictly necessary): I would define a structure (but I would use a tuples as substitute) that is passed by reference to the thread functions. This means that I would require the SET/INIT_SET methods and the possibility to embed buffers inside another containers. Tell me what do you think about such use and if you are going to implement such possibility. Otherwise I can clearly revert on a classic structure.

from mlib.

Ok for implementation.

from mlib.

I worried by the presence of the size parameter in the init method of a buffer. How can it be recursively managed by the init method of the container?

from mlib.

I plan to support only size defined at compilation time (and create a specialized initialize function that takes only the buffer as argument).

from mlib.

The methods INIT & INIT_SET have been done for the buffer, including the BUFFER oplist.
But I still have a constness issue to solve before considering the ticket as closed.

from mlib.

It should work now in 'master'.

from mlib.

Yes, it looks to work. Thank you.

from mlib.