Sign in to follow this  
Freelancemfyffe

CHandle Wrapper overloaded operator help

Recommended Posts

say i have the following wrapper class
 
Class CHandle
{
public:
..
..
private:
HANDLE m_h;
};
 
 
how would i make an overloaded operator that will return the address of m_h member so that i can mimic the following api function
 
HANDLE h;
ReadFile(&h);
 
so that mine can be used like so..
 
CHandle h;
ReadFile(&h);

Share this post


Link to post
Share on other sites
ReadFile() doesn't take a HANDLE pointer, it takes uses a HANDLE value. If you want an implicit conversion to HANDLE you can use [tt]operator HANDLE(void) { return m_h; }[/tt].

Also, ATL already contains a CHandle class, which I would recommend using over writing your own. Even if you don't use it yourself you can look at the implementation to see what design decisions they've used.

Share this post


Link to post
Share on other sites

In summary, there are three practical solutions to your problem.

 

(1) provide a conversion operator operator HANDLE(){ return m_h; } and rely on overload resolution to so the right thing.

 

(2) provide a getter, similar to std::string::c_str() and use that explicitly at the call site.

 

(3) provide a member function ReadFile() to wrap the system-provided one and use you member variable privately.

 

There are advantages and disadvatages to each.  For example, option (1) will use overload resolution in unexpected and very difficult to track down places, and over the years you'll learn a non-manifest interface is clever for the junior guy that writes it but really costly for the folks who come along later trying to fix the bugs is causes (and that may be you).  Option (2) is good, but not really much different from using a simple all-public C-style struct, or even better a simple scalar variable.  Why even bother with the class?  Option (3) may grow hairy as you find you need to add Open() and WriteFile() and Rewind() and all kinds of other overloads.

 

Of the three, I would recommend option (3), mostly because I find object-oriented designs to be less costly to maintain (that is, easier testing, fewer bugs overall, and shallower learning curve for those unfamiliar with the code).  I would run from solution (1) screaming because non-explicit code is about the biggest maintenance nightmare there is, outside of old-fashioned spaghetti code (and that seems to have suffered a Darwinian fate).

 

Edit: formatting in the new goram UI is pretty messed up right now/

Edited by Bregma

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this