Re: [boost] [pool] Definition of a static_pool ?

Subject: Re: [boost] [pool] Definition of a static_pool ?
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-28 15:16:17

>> Because I never figured out a way to *place* an array at

>> the known physical address in memory where I want it,
>> such as 0xFFE0, or whatever the address of, say, the
>> ADC result registers may be in the microcontroller.

>> Maybe there is a simpler way to do things like this.
>> But I never got it. Any advice would be welcome.

> What about placement new?
> Or an array_ref (not part of Boost).
> Olaf

Sorry, I was unclear. I meant that I never figured out how to
put std::array at an address of my choice. Unfortunately,
I have written countless custom arrays and custom allocators,
etc. for this, constantly making and re-making the same
mistakes over and over again.

I generally use 3 methods for memory-mapped arrays.
The methods 2 and 3 are related to Etienne's OP.
But since I was wrong about the scope of Boost.Pool
in the first place, it might be able to do it and
I just don't know.

1) In C and C++ if I don't need size(), begin(), end(), etc., I use
something like this

#define adc_results ((volatile uint16_t*) 0xFFE0)

2) If I need size(), begin(), end() and also want to give
the compiler freedom for loop unrolling, I use something
like this

template<typename address_type, const address_type addr, const unsigned N>
class memory_mapped_array
{
  // And basically write most of std::array, but without data,
  // only using the (volatile) address
  ...
};

3) If I really need the comfort of a container, I use something like this
in combination with an STL container.

template<typename address_type, const address_type addr>
class memory_mapped_allocator
{
  // And basically write std::allocator conforming allocator
  // but at a volatile address.
};

I keep writing methods 2 and 3 over and over again, probably
never really getting it right. I thought if Etienne wants to
extend Boost.Pool, others might want memory-mapped pools
and allocators.

But we're getting too far off the OP.

Thanks and best regards, Chris.