Replacing a non-copyable, non-movable object - c++

Question

Consider the following code:
// A non-copyable, non-movable aggregate
struct Strange
{
const int & i;
char & c;
};
class Container
{
private:
int my_i;
char my_c;
Strange thing;
public:
// Valid, because both `my_i´ and `my_c´ are non-const
// objects to which both references can be bound.
explicit
Container
( )
noexcept
: thing{ my_i , my_c }
{ }
// How could this be implemented?
auto &
operator=
( const Container & that )
noexcept
{
this->my_i = that->my_i;
this->my_c = that->my_c;
// What to do with `thing´?
return *this;
}
};
Possible solutions
Dynamically allocate the Strange object
class Container
{
private:
int my_i;
char my_c;
Strange * thing;
public:
// Note that it isn't exception safe.
explicit
Container
( )
: thing(new Strange{ my_i , my_c })
{ }
auto &
operator=
( const Container & that )
noexcept
{
this->my_i = that->my_i;
this->my_c = that->my_c;
delete this->thing;
this->thing = new Strange { this->my_i , this->my_c };
return *this;
}
};
Concerns:
Not efficient.
Not safe: allocation may fail and throw.
Dangerous: great care has to be taken not to leak memory.
Using a smart pointer (i.e. std::unique_ptr) would solve only the last point, aside from making the code more readable.
Use placement new
class Container
{
private:
int my_i;
char my_c;
Strange thing;
public:
explicit
Container
( )
noexcept
: thing{ my_i , my_c }
{ }
auto &
operator=
( const Container & that )
noexcept
{
this->my_i = that.my_i;
this->my_c = that.my_c;
// Placement new is exception safe, and so is
// construction of `Strange´.
this->thing.~Strange();
new(&this->thing) Strange { this->my_i , this->my_c };
return *this;
}
};
Concerns:
Will Strange's destructor free the memory taken by thing?
I think that, just as constructors, destructors are not responsible for memory management. Moreover, my code seems to work fine. However, I would like clarification on this.
What about memory alignment?
My guess is that, since it replaces an existing object of the same type, memory would already be aligned. Is this correct?
Would Container's destructor take care of destructing thing?
Questions
Aside from corroborating and/or refuting the concerns I explained above, I would like to know if there are other alternatives. If so, please, give an example implementation.
This question arose when working on a class that ought to offer an interface similar to that of std::unordered_map. Instead of reimplementing it, my class encapsulates such container, and just acts as a proxy for most methods: its iterators envelop those provided by the map, and its pair is an aggregate structure with appropiately named members (which are references to the actual data), represented in the examples provided as Strange. Since iterators are required to return references and pointers to the actual data, my custom iterators contain a pair. The problem was modifying it (when incrementing or assigning the iterator). I acknowledge that this probably isn't a good idea, and that those references will impact performance, but am anyway interested in the matter.
Edit
I have just realized that, instead of returning references and pointers to a member custom pair pointing to the actual data (that of the encapsulated map) from my custom iterator, I could return in-place constructed custom pairs (i.e. Strange objects). Often, we do not see that we are in a cave, and instead of exiting it, continue forward :). Excuse me for the noise, I'll mark the question as "Closed".

Answer 1

(If we're talking about moving objects and using the auto keyword, you should add the c++11 tag to your question).
I'm not sure I really understand your question; the example you gave doesn't seem well thought to me; it would be much better to use pointers in Strange.
For example, this compiles and works absolutely fine, and is functionally equivalent to what you want to do I think.
struct Strange
{
Strange()
: i(nullptr), c(nullptr) {}
Strange( const int *_i, const char *_c )
: i(_i), c(_c) {}
const int *i;
const char *c;
};
class Container
{
int my_i;
char my_c;
Strange thing;
public:
Container()
: thing(&my_i,&my_c)
{ }
Container( int i, char c )
: my_i(i), my_c(c), thing(&my_i,&my_c)
{ }
Container( int i, char c, const Strange& s )
: my_i(i), my_c(c), thing(s) // use default copy-constructor
{ }
Container &
operator=
( const Container & that )
{
my_i = that.my_i;
my_c = that.my_c;
thing = that.thing;
return *this;
}
};
int main()
{
Container a(12,24);
Container b(25,42);
b = a;
}
Note that referencing memory within objects is generally dangerous.
For example, using memcpy on this would be a catastrophy.
(Compiled with clang and g++)