Re: [Boost-users] (Newbie) Embedded programming, memory pools, and allocate_shared()

Subject: Re: [Boost-users] (Newbie) Embedded programming, memory pools, and allocate_shared()
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2017-12-12 14:42:17

On Tue, Dec 12, 2017 at 9:28 AM, Steven Boswell II via Boost-users
<boost-users_at_[hidden]> wrote:
> On Mon, Dec 11, 2017 at 5:05PM, Michael Powell via Boost-users
> <boost-users_at_[hidden]> wrote:
>
>
>>What are you targeting? You mentioned C++/CLI, .NET, etc. Windows Embedded?
>
> I'm not using C++/CLI in this project.
> The only time I mentioned C++/CLI was when trying to answer someone else's
> question.

My mistake. I must be confusing threads.

> The embedded device is something my employer manufactures, but that's
> irrelevant -- my question is about having to refer to lots of
> implementation/detail classes just to do something I consider simple and
> straightforward, i.e. a memory-pool that holds a fixed number of objects of
> a specific type, which is a pretty standard cliche for embedded programming.

I considered Boost.Asio once upon a time for one of my embedded
projects a couple of years ago, but I couldn't get it to work quite
right, so I decided to roll my own messaging framework.

> In further tests, I've found that pending socket operations (e.g. the result
> of async_read_some() and async_write() calls) lead to dynamic memory
> allocation from within Boost::ASIO, and there's presently no way to override
> that, though I'm trying to lay in the groundwork for that right now. (It
> mostly means adding a template-parameter to several classes to identify the
> allocator to use.) So far, it doesn't look like Boost::ASIO has a complete
> solution to allocate all necessary memory from pools, and I don't know how
> much work it'll take to do that, or if such work will be accepted back into
> the project.

Beyond that, I don't know. The cost of doing business the Boost way
includes comprehension of linked modules. That's just the way it is.
You may not need ALL modules, but you may incur SOME of them,
depending on how broad a functional dependence you adopt. You may be
able to defer some of that cost depending if you can link to static or
shared modules.

> -Steven
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>