• Advertisement
Sign in to follow this  

CHandle Wrapper overloaded operator help

This topic is 1943 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
You don't want to do that. If you want to be able to call your code the way you describe, provide a function ReadFile that uses CHandle. But that's still not a good idea.

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 operator HANDLE(void) { return m_h; }.

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
Sign in to follow this  

  • Advertisement