5 replies to this topic

[Freelancemfyffe]

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);

[Álvaro]

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.

[Khatharr]

Is this for RAII?

[SiCrane]

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.

[rip-off]

Don't use an operator overload for this. Use an explicit member function instead, similar to std::string::c_str().

[Bregma]

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, 23 December 2012 - 07:41 AM.