dynamically-sized text object with a copy constructor, a trivial assignment operator, and a trivial destructor

Question

I\'ve been shown that a std::string cannot be inserted into a boost::lockfree::queue.

boost::lockfree::queue is too valuable to ab

Answer 1

A dynamically-size type with a trivial copy ctor/dtor is not possible. There are two solutions to your problem, use a fixed sized type, or store pointers in the queue:

boost::lockfree::queue<std::string*> queue(some_size);
// push on via new
queue.push(new std::string("blah"));
// pop and delete
std::string* ptr;
if(queue.pop(ptr))
{
   delete ptr;
}

Answer 2

Does a dynamically-sized text object with a copy constructor, a trivial assignment operator, and a trivial destructor exist?

Dynamically sized, no. For something to have a trivial destructor, it requires that the destructor of the object is implicit (or defaulted), and any non-static member objects also have implicit (or defaulted) destructors. Since anything that is dynamically allocated will require a delete [] somewhere along the line in a destructor, you cannot have this constraint satisfied.

To expand upon the above, consider a (very cut down) example of what happens in std::string:

namespace std
{
    // Ignoring templates and std::basic_string for simplicity
    class string 
    {
    private:
        char* internal_;
        // Other fields

    public:
        string(const char* str)
          : internal_(new char[strlen(str) + 1])
        { }

    };
}

Consider what would happen if we left the destructor as default: it would destroy the stack-allocated char * (that is, the pointer itself, not what it points to). This would cause a memory leak, as we now have allocated space that has no references and hence can never be freed. So we need to declare a destructor:

~string()
{
    delete[] internal_;
}

However, by doing this, the destructor becomes user-defined and is therefore non-trivial.

This will be a problem with anything that is dynamically allocated. Note that we cannot fix this by using something like a shared_ptr or a vector<char> as a member variable; even though they may be stack allocated in our class, underneath, they are simply taking care of the memory management for us: somewhere along the line with these, there is a new [] and corresponding delete [], hence they will have non-trivial destructors.

To satisfy this, you'll need to use a stack allocated char array. That means no dynamic allocation, and therefore a fixed size.