1

In all examples of boost interprocess, I only see it being initialized in main().

#include <boost/interprocess/managed_shared_memory.hpp>
#include <iostream>

using namespace boost::interprocess;

int main()
{
  shared_memory_object::remove("Boost");
  managed_shared_memory managed_shm(open_or_create, "Boost", 1024);
  int *i = managed_shm.construct<int>("Integer")(99);
  std::cout << *i << '\n';
  std::pair<int*, std::size_t> p = managed_shm.find<int>("Integer");
  if (p.first)
    std::cout << *p.first << '\n';
}

Rather than specifically a boost question, this is more of a C++ question where I know i can create an object and initialize managed_shm using the initialization list, but I want to know if there is a way to declare it like managed_shared_memory * managed_shm; and later initialize it like managed_shm = new managed_shm(open_or_create, "Boost", 1024);?

I have seen the managed_shared_memory header, and they didn't seem to provide any option to do so.

Community
  • 1
  • 1
Nav
  • 19,885
  • 27
  • 92
  • 135

1 Answers1

2

Yeah sure. Just write it like that.

#include <boost/interprocess/managed_shared_memory.hpp>
#include <iostream>

namespace bip = boost::interprocess;

struct MyWorker : boost::noncopyable {
    MyWorker() 
        : _shm(new bip::managed_shared_memory(bip::open_or_create, "089f8a0f-956a-441d-9b9e-e0696c43185f", 10ul<<20)) 
    {}

    ~MyWorker() {
        delete _shm;
    }
  private:
    bip::managed_shared_memory* _shm;
};

int main() {
    MyWorker instance;
}

Live On Coliru using managed_mapped_file instead of shared memory (which isn't supported on Coliru)

Of course, prefer smart pointers.

Or indeed, ask yourself why you need dynamic allocation (I cannot think of a valid reason for this)

I you use some kind of API that (mistakenly!) requires a pointer, just take the address:

bip::managed_shared_memory shm(bip::open_or_create, "SHM_NAME", 10ul<<20);

// calling a badly design API takes a pointer:
misguided_api_foo(&shm);
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Thanks. One reason I did not want it in an initialization list is because in case it throws, I wont be able to handle the exception. Other reason is to be able to declare it as I mentioned in my question. – Nav Apr 24 '15 at 20:51
  • @Nav reason 1: [function-level try blocks](http://coliru.stacked-crooked.com/a/2bd29f62e6095222) reason 2: see my answer :/. Better options: [extract a function](http://coliru.stacked-crooked.com/a/55f21ee69e15fee2) or just [use `optional`](http://coliru.stacked-crooked.com/a/f5fdb50b1af68d50) – sehe Apr 24 '15 at 21:08
  • Summarizing: don't use `new` and `delete`. You can almost always avoid it (and the class of bugs that come with it) – sehe Apr 24 '15 at 21:10
  • Thank you. While I agree with your comment on `new` and `delete`, I'm working on an application that was tested to work three times slower when the reference counted boost pointer containers were used instead of a simple array. Some of us have to take necessary risks with memory management just for the sake of efficiency. – Nav Apr 25 '15 at 04:48
  • That makes nearly zero sense. Between raw pointers and manual memory management on the one hand and reference counted smart pointers on the other hand there is a lot of difference. You can't compare these. Besides none of that explains why you would be dynamically allocating segment managers. The point is that you can do 《the same job》safer. The fact that doing 《something else》is slower is not relevant. All of us using c++ are taking the extra risks required. Because otherwise why use c++? – sehe Apr 25 '15 at 07:29