jaredpar's WebLog : C++

Type safety issue when assigning CComPtr instances

Jared Parsons — Wed, 04 Nov 2009 13:00:00 GMT

Recently while making a bug fix to our selection tracking code I discovered an unexpected behavior with CComPtr<T> instances. The crux of the fix included creating a new tracking mechanism exposed via COM in the type ISelectionTracking. The old interface, lets call it IOldTracking, was a completely unrelated interface in terms of inheritance hierarchies.

As part of the fix I changed the type of a field (m_spTracking) from CComPtr<IOldTracking> to CComPtr<ISelectionTracking>. I searched for assignments of m_spTracking and converted them to call the new API I added as part of the fix. I didn’t search terribly hard because I was depending on the compiler to catch any places I missed. ISelectionTracking and IOldTracking are incompatible types so any places I missed will show up as compilation errors.

Or so I thought …

I made my fix, ran our core check-in suites without error, checked in and moved onto the next bug. A couple hours later one of our other devs emailed me and informed me my check-in was breaking our larger, slower, suite bed run because m_spTracking was NULL. After some quick debugging I found myself looking at the following chunk of code which was apparently NULL’ing out m_spTracking in the suite.

  CComPtr<IOldTracking> spOldTracking;
  if ( SUCCEEDED(CreateOldSelectionTracking(&spOldTracking)) ) {
    m_spTracking = spOldTracking;
  }

Me and the other dev were quite shocked that this compiled at all. How is it possible to assign between CComPtr<ISelectionTracking> and CComPtr<IOldTracking>??? My first thought was I must have accidentally used a CComQIPtr somewhere (quickly verified that was not the case). After a bit of searching we found the cause was one of the operater= instances available on CComPtr<T>. Here is the definition

template <typename Q>
T* operator=(_In_ const CComPtr<Q>& lp) throw()
{
    if( !IsEqualObject(lp) )
    {
        return static_cast<T*>(AtlComQIPtrAssign((IUnknown**)&p, lp, __uuidof(T)));
    }
    return *this;
}

This templated operator allows for assignments between CComPtr instance no matter what the type is for the left and right side. The effect is that instead of doing compile type C++ type conversion rules, it will instead rely on runtime COM polymorphic assignment rules via IUnknown::QueryInterface. This moves assignment errors from compile time to runtime for unrelated interfaces.

This is further complicated because it only applies to assignment between CComPtr’s (and derived instances). If the right hand side of the assignment is a non-smart pointer, compile time C++ conversions will apply. To demonstrate …

        CComPtr<ISelectionTracking> spTracking;
        CComPtr<IOldTracking> spOld;
        ...
        spTracking = spOld;  // Fails at runtime
        spTracking = (IOldTracking*)spOld;  // Compilation Error

What surprised me though was talking to other developers about this issue. Most agreed with me that this is a bug in CComPtr<T>, or at least very unexpected behavior. A surprising number though did not expect this behavior but still considered it acceptable. The difference comes down whether you view CComPtr<T> as a simple smart pointer responsible for AddRef/Release semantics or as that plus an enabler of QueryInterface style conversions. I personally view CComPtr<T> as a simple smart pointer with know real understanding of QueryInterface style conversions and CComQIPtr<T> as a smart pointer which respects QueryInterface style conversions. As such this behavior is completely unexpected.

The fix in this case was pretty straight forward (use the new API) but I was still worried about how to prevent this type of problem in the future. In particular how to get the failure back to a compile time error. In the end we settled on using a stripped down version of CComPtr we already had in our code base going forward called CComPtrEx. I’ve previously blogged about about the need for this type here. It’s different from CComPtr in the following ways

Does not have the templated version of operator= and instead relies on compile time C++ conversions checks for assignment
Allows for interfaces which have multiple paths to IUnknown (can cause a compile time error in CComPtr).

Also for purposes of rigor, we temporarily commented out the CComPtr<T> operator, recompiled our code base and verified no new errors popped up.

Questions not to hinge a C++ interview on

Jared Parsons — Tue, 21 Apr 2009 15:00:00 GMT

People love to chat about how to conduct a C++ interview on newsgroups. Eventually these topics will shift into a discussion about what questions a candidate must know in order for them to get a hire from a particular interview. Unfortunately these questions tend to be items like the following.

What happens when you delete NULL?
Explain how exceptions affect constructor initialization.
Which constructors are called for the following: SomeType a = SomeType(b);

Sure these questions are valid parts of the language and knowing them is a plus and demonstrates a deal of mastery over the language. But not knowing them should by no means by a deal breaker. The goal of an interview is to spot good developers who will become a contributing member of the team. Good developers are motivated and passionate problem solvers. These questions are testing little more than memorization. It’s easy to memorize rules after the fact. It’s much more difficult to teach problem solving skills.

The problem with questions like the above is that a developer could be both passionate and competent in C++ and never have come across these rules. C++ is an unbelievably huge language and can operate in many different ways where these type of situations simply don’t come up. For instance, I’ve known several very good C++ developers that spent the majority of their time working with COM. COM prefers HRESULTs to Exceptions and hence they never used exceptions in C++. Once we introduced exceptions into the code base, it took about 30 minutes to explain the rules and we were done.

C++ interviews should focus on the qualities that make a good developer: problem solving and passion. Of course a language based interview should certainly focus on the foundations of C/C+. Items like pointers, stack vs. heap and the basics of memory management. But don’t hinge the deal on little items that can be quickly taught. Otherwise you’ll end up turning away good developers.

Redefining Success

Jared Parsons — Fri, 24 Oct 2008 15:00:41 GMT

Spent about an hour debugging a bit of code today. I was attempting to read data from a particular source and kept getting back failure codes. After some debugging I discovered the data didn't actually exist in the source I was reading from.

This put me back to investigating where I wrote the data out. Restarted the scenario and verified that I actually called the data writing API and that it succeeded.

Now what? Well the data clearly wasn't there so I concluded the data writing must be failing in some odd way. I eventually found the data writing code and was horrified to find the following definition.

HRESULT WriteSomeData(...) {
  // We don't support data of this type
  return S_OK;
}

Personally I thought this warranted an error code (perhaps E_NOTIMPL). But given the situation I must conclude the author successfully failed to write the data.

Where does the * go?

Jared Parsons — Thu, 04 Sep 2008 15:00:04 GMT

This is a more amusing than functional debate I enter into from time to time. On a line where you declare a pointer type in C++, where should the * go?

Next to the type (i.e. Type* p1;)
Next to the variable name (i.e. Type *p1;)
Who cares

For the moment lets ignore #3 (after all they don't care). I'm a firm believer in #1. After all * is a part of the type of the variable, not the name and therefore should be closer to the type.

#2 believers disagree with this notion. They believe the * is a part of the individual variable's type and not the actual type. This is technically correct and can be demonstrated with the following code

  Type* p1, p2;

The type of p2 is of course Type and not Type*. Therefore they argue, #2 is the superior way

This is true but I'm also a firm believer in don't declare multiple variables in a single declaration statement while coding in C++ unless the type has a user defined constructor. Namely to avoid situations just like this.

Bit by void*

Jared Parsons — Mon, 16 Jun 2008 15:00:07 GMT

Recently I got bit by void* again because of another C++ quirk I didn't think through. I had a class which wrapped a void* which could be one of many different structs. The structs were POD and didn't have any shared functionality hence I didn't bother creating an inheritance hierarchy. Unfortunately I defined the structs like so

class C1 {
  struct S1 {
    int field1;
    float field2;
  };
  struct S2 {
    char field1;
  };
  ~C1() {
    delete m_pData;
  }
  void* m_pData; // Can be S1,S2,etc ...
}

Unfortunately this appeared to work fine for quite some time. Then after a couple of days of bug fixes I ended up with a memory leak which I quickly tracked down to a leaked COM object. Although C1 was at fault I didn't suspect any changes to this class because after all it was working fine for some time and all I did was add a new field to one of the structs. If the structs were being successfully free'd before a new field shouldn't change anything.

The field I added was of type CComPtr<T> which exposed a greater problem in my code. Even though I properly delete the pointer in C1::~C1() I wasn't running the destructor on the pointed at data and instead I was just freeing the memory. Until I added a field which had a non-trivial destructor this wasn't a problem (still a bug though).

Why did this happen? By deleting a void* and expecting a destructor to run what I'm really doing is asking C++ to behave polymorphicly. C++ as a rule won't behave this way unless it is specifically asked to with inheritance and virtual. In the case of void*, it just won't. The fix is to actually implement an inheritance hierarchy which supports polymorphism.

It's just another rule that I need to remember when coding C++.

Deleting void* is dangerous, period.

Unfortunately C++ has too many of these rules and not enough enforcement.

do {} while(0) what?

Jared Parsons — Wed, 21 May 2008 15:00:00 GMT

A recent check in of mine raised a few eye brows during reviews. I checked in a few macros which ended with/contained a "do{}while(0)" and people were curious as to why.

In my experience there are two main uses for it.

Insert an empty statement with no runtime penalty
Group a set of statements into a single statement followable by a semi-colon

do { Func1(); Func2() } while(0)

Macros are mutating little constructs which jump back and forth depending on the compile time options. Many macros compile to different expressions based on the options and in some cases they compile to nothing. This is where #1 really comes in hand. Imagine you have the following code.

  if(someCondition)
    MY_MACRO();

Compiling MY_MACRO to nothing will cause at the least a compile time warning since you will have essentially if(someCondition);. Instead you can use the do{}while(0) trick.

#if CONST_1
#define MY_MACRO() Func1()
#else
#define MY_MACRO() do{}while(0)

Another us is for stylistic reasons. Some camps don't believe a ; should be used as a empty statement and use do{}while(0) instead. I tend to agree. Mainly because one of my early C professors had the same belief. The habit stuck around.

Update: Changed incorrect use of word expression -> single statement

Saved by PowerShell

Jared Parsons — Wed, 07 May 2008 15:00:13 GMT

Recently I made a very large update to our code base. Our code base lacked a standard way of guarding entry and exit points into the various components. Having said guards is useful for error handling, tracing, reducing redundancy, etc ... The edit standardized our entry points by adding start/end macros to our entry point functions. In addition to other house keeping, the macros also created an HRESULT variable named "hr". Example below.

#define MY_ENTRY_GUARD() HRESULT hr
#define MY_ENTRY_EXIT() return hr

Ran suites, everything passed, checked in. Then I got an email from another dev who spent some time tracking down a bug related to this check-in (sorry Calvin). He discovered one scenario my fix did not take into account.

SomeMethod
{
  MY_ENTRY_GUARD();
  if ( somecondition ) {
    HRESULT hr = E_FAIL; // shadows the first hr
  }
  MY_ENTRY_EXIT(); // returns unmodified hr
}

The double declaration of the variable "hr" is not an error or even a warning in C++. Instead the inner "hr" shadows the outer and hence the rest of the method doesn't update the "hr" which is actually returned. So now I had to find every place in this change where a nested hr was declared. Did I mention this edit was huge? Going through by hand would not only be time consuming, it would also be very error prone.

At first I considered parsing out the C++ and doing basic brace matching to look for shadowing "hr" variables. I ruled that out due to the amount of time I would need to invest in the script to take into account comments, string literals, etc ... Really I didn't need brace matching, I really just needed to know when I entered and left a method. Almost all C++ methods have their opening and closing braces on the first column. Writing a script to detect this is trivial.

Script took about 5 minutes to write and 10 to run in the code base. Saved me countless hours of error prone reviews. Thank you PowerShell.

Find-DoubleHr.ps1:

param ( $argFileName = $(throw "Need a file name") )

function Do-Work() {
    $i = 0
    foreach ( $line in (gc $argFileName) ) {
        new-tuple "Text",$line,"LineNumber",$i
        $i++
    }
}

function Do-Parse() {
    begin {
        $inMethod = $false
        $seenHresult = 0
        $seenMacro = 0
    }
    process {
        $tuple = $_
        if ( $inMethod ) {
            switch -regex ($tuple.Text) {
                "^}" {
                    $inMethod = $false
                    if ( ($seenHresult -ne 0 )-and ($seenMacro -ne 0) ) {
                        "Found a double {0},{1}" -f $seenHResult,$seenMacro
                    }
                    $seenHresult = 0
                    $seenMacro = 0
                    break
                }
                ".*MY_ENTRY_GUARD.*" {
                    write-debug ("Macro: {0} " -f $tuple.Text)
                    $seenMacro = $tuple.LineNumber
                    break
                }
                "HRESULT.*\Whr\W" {
                    write-debug ("HResult: {0}" -f $tuple.Text)
                    $seenHresult = $tuple.LineNumber
                    break
                }
            }
        }
        elseif ( $tuple.Text -match "^{" ) {
            $inMethod = $true
        }
    }
}

"Processing $argFileName"
Do-Work | Do-Parse

C++ Programming Books

Jared Parsons — Thu, 01 May 2008 15:00:40 GMT

I was reading a post on Coding Horror the other day about programming books and how developers don't read enough of them. I readily agree with the first two points in the article that 1) most programming books suck and 2) books are sold by weight not by volume. Reading is an integral part of a developers life. Blogs are a great source of info but books are a necessity as well.

In my experience, the hardest language to find a good book for is C++. Far too many books and far too few which are worth reading. Here are my favorite which 1) don't suck and 2) don't weigh a ton but have a enormous amount of information.

Herb Sutter:

Scott Meyers

Others may disagree but I classify the Scott Meyer books as being good for developers looking to break into the intermediate level. Herb Sutter is great for developers looking to cross from a intermediate to efficient level in C++.

For developers who think they're ready to cross into the expert realm I highly recommend "C++ Template Metaprogramming." It should convince you that being an expert it C++ is near impossible :)

IMHO, the first two Herb Sutter books I listed should be required reading for anyone doing C++ software development.

Gotcha: CComAutoCriticalSection and copy constructors

Jared Parsons — Thu, 24 Apr 2008 15:00:24 GMT

While investigating a crash during a suite run I found the stack walk included the destructor for a CComAutoCriticalSection. This is a fairly reliable class so I immediately suspected my code. I did a couple of quick checks for a double free and didn't find any. Then I looked a little closer at CComAutoCriticalSection and spotted that it doesn't redefine the standard copy and operator= constructor.

This is a red flag for any class that implements RAII. C++ will automatically define a copy/operator= for your clasess which will amount to a memcpy. This means copies of two objects will be managing the same resource. Once the second one is destroyed it will result in a double free and hopefully a crash.

I walked the hierarchy and discovered that none of the base classes redefined these methods either. After that it only took a few minutes to discover the bug. I attempt to pass the object by reference but instead ended up passing it by value.

To ensure I didn't miss any other cases of this, I added the following definition to my code base and moved all instances of CComAutoCriticalSection to point to this version.

class SafeCriticalSection : public CComAutoCriticalSection
{
public:
    SafeCriticalSection() {}
private:
    SafeCriticalSection(const SafeCriticalSection&);
    SafeCriticalSection& operator=(const SafeCriticalSection&);
};

It should be standard practice to define all 3 of the above methods on any class which has RAII semantics. This is not necessary if all of the members are copy safe (CComPtr<> for example).

Thread Local Storage template

Jared Parsons — Mon, 21 Apr 2008 20:52:03 GMT

Thread local storage is another method of synchronization between threads. It is different that most synchronization cases because instead of sharing state between threads it enables developers to have independent, thread specific pieces of data which have a similar or common purpose.

The uses of thread local storage (TLS) vary greatly but is a very powerful and lightweight method for storing data. TLS can easily be envisioned as a giant void* array for every thread. The entry point, TlsAlloc, provides an index into this array and allows the storage of arbitrary data [1].

TLS is particularly useful for storing state information. For example, one of my components lives in a highly multi-threaded environment. Each thread serves essentially the same purpose and has the same states and state transition semantics. Like any good paranoid programmer I wanted to add contracts to check my state transitions and semantics.

Contract.VerifyState(ExpectedState, ???CurrentState)

The question is where to store the state information for a thread? A global state variable won't suffice because there are N threads. A global array of state information also has it's share of problems: synchronization, determining an index, lifetime.

TLS is ideally suited to this scenario. Each thread has an independent but similar concept of state. In my initialization code I allocate an TLS index and now I have a place to store my state.

Contract.VerifyState(ExpectedState, *TlsGetValue(g_stateTlsIndex)

The next question is how to manage the lifetime? TLS provides a void* and the caller must manage the lifetime of the allocated memory. Since this is thread specific the ideal place is to manage the memory in the thread startup proc. However I don't own the creation of the thread, my component is called on a number of threads so this won't work.

The solution is to use the stack. The initial return for TlsGetValue is NULL. If this situation is detected then the current stack frame is set to own the memory for the slot. Further accesses to the value do not own the memory and simply access it. The semantics are straight forward but annoying to constantly rewrite, so naturally write a template :)

    template <typename T>
    class TlsValue
    {
    public:
        TlsValue(DWORD index, const T& defaultValue=T()) :
            m_pValue(NULL),
            m_index(index),
            m_owns(false)
        {
            m_pValue = reinterpret_cast<T*>(::TlsGetValue(m_index));
            if ( !m_pValue )
            {
                m_pValue = new T(defaultValue);
                m_owns = true;
                ::TlsSetValue(m_index, m_pValue);
            }
        }
        ~TlsValue()
        {
            if ( m_owns )
            {
                ::TlsSetValue(m_index, NULL);
                delete m_pValue;
            }
        }

        T* Value() const
        {
            return m_pValue;
        }

    private:
        // Do not auto generate
        TlsValue();
        TlsValue(const TlsValue<T>&);
        TlsValue& operator=(const TlsValue<T>&);

        T* m_pValue;
        DWORD m_index;
        bool m_owns;
    };

In addition to this blog post, I added a working sample to http://code.msdn.microsoft.com/TlsValue. This is my first attempt at posting a sample on http://code.msdn.com so please provide any and all feedback on the data.

[1] This is similar to data marked with the ThreadStatic attribute in managed code without all of the slot messiness and with the added benefit of strong typing.

Gotcha: CComPtrBase assignment

Jared Parsons — Tue, 08 Apr 2008 18:44:16 GMT

Today what started out as a crash due to a pure virtual call turned into finding a gotcha in CComPtrBase<T>. Essentially the code in question boiled down to the following. Can you spot the problem?

void GetAStudent(CComPtrBase<T> &spStudent)
{
    CComPtr<Student> spLocal;
    // Do some operation to get a student
    spLocal = spStudent;
}

The problem isn't apparent until you look at the definition for CComPtrBase<T>::operater =. See the problem? Basically CComPtrBase<T>::operator= isn't explicitly defined. This means that C++ will automatically implement memberwise assignment. The RHS of the operator= will be a "const CComPtrBase<T>&".

CComPtr<T> derives from CComPtrBase<T> therefore it satisfies this and a memberwise assignment will occur. We now have two smart pointers on the same value. However the second smart pointer, CComPtrBase<T>, did not perform an AddRef. So when both objects are destroyed there will be an extra Release and hopefully a crash.

The fix?

Use CComPtr<T> or CComPtrEx<T> instead of CComPtrBase<T>
Less Optimal: call AddRef() on spLocal.

Reference values in C++

Jared Parsons — Thu, 03 Apr 2008 17:24:54 GMT

Reference values are a powerful feature of C++ but I find they have one significant detractor. A developer can not look at an API call and determine if a parameter is being passed by reference or value (VB has the same problem).

IMHO this is one item that C# got 100% correct. In C# developers must say a value is out/ref or a compile error results. Forcing both the API declaration and usage to specify the reference semantics makes code much more understandable. When you look at an API call there is absolutely no question about the byref/byval/out semantics of a parameter.

Internally I've met people who are hesitant to use reference parameters in C++ because of the ambiguity. Not making it declarative in both places meant unexpected behavior could occur in a number of scenarios. I agree with this statement.

But hey we're talking about C++ here. Any C++ problem can be fixed with some macros and a template right? I thought about this over the weekend and came up with a quick sample. Note, I haven't extensively tested this sample yet so there may be bugs. However it gets the base cases right.

The goal of this API is to allow API authors to force developers to be explicit about their ByRef semantics. It will prevent developers from silently passing a value by ref and hence getting unexpected behavior. Failure to do so will result in a compile time error. Also there is a minor bit of indirection overhead for debug mode but in retail this will compile out to normal code.

#ifdef DEBUG

template <typename T>
class ByRefType
{
public:
    explicit ByRefType(T& arg) : m_ref(arg)
    {
    }

    operator T&() const 
    {
        return m_ref;
    }

    ByRefType& operator=(const T& value)
    {
        m_ref = value;
        return *this;
    }

private:
    ByRefType();

    mutable T& m_ref;
};

template <typename T>
ByRefType<T> MakeByRefType(T& expr)
{
    return ByRefType<T>(expr);
}

#define ByRef(expr) MakeByRefType(expr)
#define ByRefParam(type) ByRefType<type> 

#else

#define ByRef(expr) expr
#define ByRefParam(type) type&

#endif

All well and good. Now we can attribute byref paramaters with ByRefParam() and force callers to tag it as a ByRef argument.

void SimpleByRef(ByRefParam(int) i, int newValue)
{
    i = newValue;
}

void Test()
{
    int i1;
    SimpleByRef(ByRef(i1), 5);
    SimpleByRef(i1, 6);     // Compiler Error!!!
}

As said before, this is an initial implementation and I expect updates as I use this in code and find bugs. Please post back with any you find.

API Problems: CComObject::CreateInstance

Jared Parsons — Sat, 29 Mar 2008 02:38:00 GMT

CComObject::CreateInstance is a light weight method for creating instances of COM objects in your code. Unfortunately the design of the API makes it easy to introduce subtle errors into your code. The two problems are it encourages manually ref counting and the object initially has a ref count of 0. This means you must remember to AddRef before calling any other function. Neither of these ideas in themselves are bad but it leads to tedious, repetitive code that is too often done incorrectly.

Below is a typical example I see in code.

void AMethod()
{
    CComObject<Student> *pStudent;
    if ( SUCCEEDED(CComObject<Student>::CreateInstance(&pStudent)) )
    {
        pStudent->AddRef();
        VerifyStudent(pStudent);
        pStudent->Release();
    }
}

As a result of the manual ref counting, this code is not exception safe. If VerifyStudent or any API it calls throws, an instance of Student will be leaked.

The second problem I often see in code is the placement of the VerifyStudent function. Occasionally I see methods like VerifyStudent called before the AddRef. If you see this in your code immediately file a bug. The problem is the ref count is 0 before you call AddRef. It COM it should always be legal to AddRef/Release a COM object passed into your function. In this case while legal it will destroy the instance of Student. What's even worse is this bug can show up years after you code.

Real world example. I created a class to wrap a couple of operations. One of it's members was Student and as such I wrapped it in a CComPtr<> for ease of use. Fired up the program and everything crashed. Turns out an instance of Student was passed to a function that eventually created an instance of my object before AddRef was called (essentially move VerifyStudent up one line). As soon as my new object died CComPtr<> called Release, moved the RefCount to 0 and destroyed the object.

Writing the correct code is repetitive and begs for a wrapper function. Enter CreateWithRef

template <class T>
static 
HRESULT CreateWithRef(T** ppObject)
{
    CComObject<T> *pObject;
    HRESULT hr = CComObject<T>::CreateInstance(&pObject);
    if ( SUCCEEDED(hr) )
    {
        pObject->AddRef();
        *ppObject = pObject;
    }

    return hr; 
}

void AMethod2()
{
    CComPtr<Student> pStudent;
    if ( SUCCEEDED(CreateWithRef(&pStudent)) )
    {
        VerifyStudent(pStudent);
    }
}

As you can see, using this function takes less typing that a normal CreateInstance due to using type inference. It's also exception safer since the resource is managed.

This API still has one flaw. It allows people to pass in a raw pointer and hence violate exception safety. It could be improved by forcing a caller to pass in a class which supports RAII. In this case a good choice is CComPtrBase<>. I tend to prefer this design because it forces the caller to use safer code.

template <class T>
static 
HRESULT CreateWithRef2(CComPtrBase<T>& spPointer)
{
    CComObject<T> *pObject;
    HRESULT hr = CComObject<T>::CreateInstance(&pObject);
    if ( SUCCEEDED(hr) )
    {
        pObject->AddRef();
        spPointer.Attach(pObject);
    }

    return hr; 
}

void AMethod3()
{
    CComPtr<Student> pStudent;
    if ( SUCCEEDED(CreateWithRef2(pStudent)) )
    {
        VerifyStudent(pStudent);
    }
}

Multiple paths to IUnknown

Jared Parsons — Fri, 22 Feb 2008 09:21:00 GMT

ATL has a lot of great tools for COM programming and CComPtr is a good example. It's a smart pointer class which manages the reference count of an underlying COM object.

One of it's limitations though is it will only work properly when the inheritance chain for a class has only one path to IUnknown. If it has more than one path, the following error will be issued when you attempt to assign a value of type T to the CComPtr.

error C2594: 'argument' : ambiguous conversions from 'SomeClass *' to 'IUnknown *'

The reason behind this is the operator= for CComPtr uses AtlComPtrAssign to change the references. The right hand side of the assignment is passed to this function as IUnknown. Since there are multiple paths to IUnknown the C++ compiler cannot implicitly perform the cast and issues the above error.

I most frequently encounter this error in larger code bases with older classes. New functionality is needed so I add a new interface and end up with a lot of C2594 errors.

To work around this I defined a new CComPtr class named CComPtrEx which inherits from CComPtr base. It defines the same operators as CComPtr but uses a Copy Constructor and Swap to perform the = which gets around the multiple paths to IUnknown. The rest of the functions are identical to CComPtr.

template <class T>
class CComPtrEx : public CComPtrBase<T>
{
public:
    CComPtrEx() throw()
    {
    }
    CComPtrEx(int nNull) throw() :
        CComPtrBase<T>(nNull)
    {
    }
    CComPtrEx(T* lp) throw() :
        CComPtrBase<T>(lp)
    {
    }
    CComPtrEx(_In_ const CComPtrEx<T>& lp) throw() :
        CComPtrBase<T>(lp.p)
    {
    }

    T* operator=(_In_opt_ T* lp) throw()
    {
        if(*this!=lp)
        {
            CComPtrEx<T> sp(lp);
            Swap(&p, &sp.p);
        }
        return *this;
    }

    T* operator=(_In_ const CComPtrEx<T>& lp) throw()
    {
        if(*this!=lp)
        {
            CComPtrEx<T> sp(lp);
            Swap(&p, &sp.p);
        }
        return *this;
    }
};

Mixing SEH and C++ Exceptions

Jared Parsons — Sat, 12 Jan 2008 01:18:01 GMT

Recently I had a half day adventure trying to catch a SafeIntException in code I was writing. The particular function involved a bit of math with user controlled values. Writing a bunch of IfFailGo's with several TryAdd style API's was getting tiresome so I decided to just use SafeInt, catch an overflow and return a failure code.

After recompiling the code I got an error because I hadn't enabled C++ exception handling in the project. Fix to support synchronous exceptions (/Ehs), recompile. Now I get a different error because a portion of the code base is using SEH exception handling. No problem, changed the project to support asynchronous exception handling as well (/Eha). And yet again another error, the compiler now said that I could not use variables with a destructor in the same method that had an SEH try block.

This put me in a bit of a corner. The code base is littered with SEH exception handling and much of it is perfectly valid. Luckily the number of places using both SEH and destructors was fairly limited. What I needed was a way to unify the exception handling to allow me to use destructors in the same place as SEH exceptions.

With /Eha there is a built-in way. You can catch all SEH exceptions using the C++ syntax "catch (...)". However this method is limiting because you cannot access the SEH exception code and you get notified after the stack unwind occurs. In SEH an exception filter is run before a stack unwind occurs which makes it infinitely easier to track down your bugs as you can just look down the stack trace and see the line of code that faulted.

After a bit of research I found a solution. I'm chose to blog about it because many of the questions I needed answers for were either 1) undocumented or 2) documented to vaguely. In the end I setup some experiment projects to confirm the behaviors I expected.

The magic function I was looking for was _set_se_translator. It takes a function pointer as an argument and returns the previous value. The documentation states that when a C/SEH exception is raised this function pointer is called once per function that has a C++ try block. It can be used to throw a C++ exception in place of a SEH exception. So you can now translate a SEH exception into a C++ one.

What the documentation didn't explain (and I was very curious about) is how this interweaves with existing SEH __try/__except/__finally blocks. After some experimentation I discovered that it works extremely well. SEH exceptions occur in two phases

Process the exception filters until either EXCEPTION_EXECUTE_HANDLER or EXCEPTION_CONTINUE_EXECUTION is returned
If EXECEPTION_EXECUTE_HANDLER is returned the stack is unwound to the point of the exception handler block and it is then executed.

The value passed to _set_se_translator participates in phase 1 of the process. As the CRT is looking down the stack for a SEH exception filter, if it finds a C++ try block it will also process the last value passed to _set_se_translator and allow it to throw a C++ exception. If an exception is thrown the stack is unwound to that point and then the exception is thrown. This means that if you call into other code which uses traditional SEH handlers they will operate just as they did before you started using _set_se_translator. Most importantly __finally blocks will run and __except blocks above you in the stack still process and can handle SEH exceptions.

The next step was to write an easy to use wrapper for this functionality. I used two classes to implement this approach.

The first class is designed to properly install a translator at a given point in the stack and ensure that it is reset to the previous value when that stack frame is popped off.

extern void SehTranslatorFunction(unsigned int, struct _EXCEPTION_POINTERS*);

class SehGuard
{
public:
    SehGuard()
    {
        m_prev = _set_se_translator(SehTranslatorFunction);
    }

    ~SehGuard()
    {
        _set_se_translator(m_prev);
    }

private:
    _se_translator_function m_prev;
};

The second part is to actually throw an exception inside of SehTranslatorFunction. Also to add an assert so that when an SEH exception is produced I can break at the point of failure (as opposed to in the catch block where the stack will be unwound.

class SehException
{
public:
    SehException(int code) : m_code(code) { }
private:
    unsigned int m_code;
};

void SehTranslatorFunction(unsigned int code, struct _EXCEPTION_POINTERS*)
{
    MyAssertFunction(false,"Caught an SEH exception");
    throw SehException(code);
}

Now whenever I hit a point where I want to guard against SEH exceptions, I just put and instance of SehGuard on the stack and catch SehException instances. No traditional SEH needed.