- Resource management - 2 Updates
Paavo Helde <myfirstname@osa.pri.ee>: Oct 24 02:37PM -0500 "Norman J. Goldstein" <normvcr@telus.net> wrote in news:n0giu2$eoe$1 > and then use > IntFD fd = open( "filename", O_WRONLY ); > It would be nice to have a uniform way to manage the scope of resources. > I suspect that families of resources might have uniform ways > of being managed, but, generally, each resource should have its > own management struct, such as IntFD. IMO, this is a hack abusing std::unique_ptr as a way to implement RAII while saving a couple of code lines. This can be used to such effect when encapsulating pointers, but it will make two concepts (RAII and pointers) closely intertwined which creates unnecessary strong coupling. I would much prefer the approach you used in IntFD instead: for each resource type there should be a dedicated class which owns the resource and releases it in the destructor. This makes the design more flexible and avoids unneccesarily tight couplings. One can create the objects of this class on stack, on heap, owned by unique pointers or shared pointers as needed, etc. Cheers Paavo |
Luca Risolia <luca.risolia@linux-projects.org>: Oct 24 11:03PM +0200 Il 24/10/2015 20:33, Norman J. Goldstein ha scritto: > I suspect that families of resources might have uniform ways > of being managed, but, generally, each resource should have its > own management struct, such as IntFD. I don't think there can be one uniform way to handle all possible situations. I tend to avoid to implement wrappers like IntFD whenever possible. I often use "final action objects" (e.g. made with BOOST_SCOPE_EXIT) to cleanup resources when there is no ideal resource handle. For member data in some cases I use scoped pointers (e.g. unique_ptr<>'s) with custom deleters. |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment