On 02/10/2013 10:21 AM, Tim Munro wrote: > I've dealt with the issue by cobbling together an ugly, complicated copy > constructor for the PluginContainer class. > > The resulting code appears to work, but I have no idea what sort of memory > leaks or other future train wrecks I might have introduced while beating > it into submission.
It's a good idea to avoid the need for a custom copy ctor if at all possible. Copy ctors are tricky to get right. If I had time, I'd take a look at this situation and see if there are alternatives. Instead, I'll just pontificate on copy ctors for a bit. Ignore if you've heard it all before.... The first alternative that I usually try for is to remove the need for a copy ctor altogether. This can be achieved at least two ways: don't copy the object, or make everything in the object copy itself. Why is this plugin container being copied in the first place? It sounds like that would be a less than desirable thing to do (potentially expensive in terms of CPU and memory). Is there a way to change the design so that no copy is necessary? You can find every place where a copy occurs by making your copy ctor private. (Unless, of course, this is so botched up that the object is copying itself. Yikes! In that case, leaving it declared but undefined will cause the linker to complain.) Once these copies have been identified, an attempt can be made to remove them. Making everything in the object copy itself can be achieved in many ways. One way is to make everything an object instead of having pointers. Another is to use smart pointers (like shared_ptr) which provide a reference counting mechanism. In the end, though, a copy ctor might indeed be the right thing to do (and yours might be exactly what is needed). In that case make sure that the copy ctor copies *everything* in a way that makes sense. It must create an object that is identical to the original in every way (read through the regular ctors and the member objects to create a checklist of things you need to do in your copy ctor). Also, make sure you declare an operator=(). You can make it private to prevent anyone from using it. You can also leave it undefined so you'll get a linker error in case the class itself uses it. Having a copy ctor and no operator=() is almost always an error. (Actually implementing an operator= is a bit tricky as it must deal properly with self-assignment.) For more, read up on the Rule of Three: https://en.wikipedia.org/wiki/Rule_of_three_%28C%2B%2B_programming%29 (Which in C++11 is now the Rule of Five what with the new move ctor and move assignment.) Another great source is Lippman's C++ Primer 5th ed. (2013) Chapter 13. The crash symptoms you describe sound like a case of a class that has pointer members (directly or indirectly), does a delete in the dtor, but has no copy ctor or op= defined. Then somebody does a copy (or assignment). This is the perfect recipe for a crash. The Rule of Three should never be taken lightly like this. Ted. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
