Boost logo

Boost :

From: Stewart, Robert (stewart_at_[hidden])
Date: 2001-11-08 11:55:44


> From: Jim Patterson [mailto:jimp_at_[hidden]]
>
> I have recently written a template class to manage "C" style handles
> for use in a C++ programs that use "C" libraries. An example of its
> use is:
>
> #include "C_HandleManager.hpp"
>
> #include <iostream>
> #include <cstdlib>
>
> using namespace std;
>
> int
> main( int, char** )
> {
> cout << "starting..." << flush;
> {
> C_HandleManager<void*,void,free> memory( malloc(1000) );
> if ( NULL == memory )
> {
> cerr << "\nUnable to allocate memory!" << endl;
> memory.no_deallocate_reset();
> return 1;
> }
>
> memset( memory, 0, 1000 );
> } // memory is destroyed here (and free is called on the pointer)
>
> cout << "\ndone!" << endl;
> }

While it may be handy to have a generic class to handle the majority of the
work, I'd think it better to have classes for each case as you encounter it.
That class could inherit from C_HandleManager or even contain one, but it
would be distinct.

> The class looks like:
> template<typename T, // Type of the handle
> typename R, // Return type of the dealloc function
> R (*DEALLOC)(T)> // Function to dealloc the handle
> class C_HandleManager;

Sean was asking for something akin to your class being like this:

template <typename Function>
class C_HandleManager;

...
C_HandleManager<free> memory(malloc(1000));

This would, in an ideal world, automatically deduce your T and R from your
DEALLOC (my Function). That, I think could only be done via a "make"
function that returns an object of the class suitably parameterized.

Rob
Susquehanna International Group, LLP
http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the
sender immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of
this message or any attachment by an unintended recipient is strictly
prohibited. Neither this message nor any attachment is intended as or
should be construed as an offer, solicitation or recommendation to buy or
sell any security or other financial instrument. Neither the sender, his or
her employer nor any of their respective affiliates makes any warranties as
to the completeness or accuracy of any of the information contained herein
or that this message or any of its attachments is free of viruses.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk