Fixing "Unsatisfied forward declaration" error from MIDL

Fixing "Unsatisfied forward declaration" error from MIDL

  • Comments 6
Earlier this week I was helping a customer port some code from Visual Studio 2005 to a beta build of Orcas when we noticed an interesting change of behavior in how the new version of midl.exe (from the Windows Vista SDK release) was parsing code.  In case you run into the issue, here's a brief description, along with what we did to work around it:
In pseudo code, what the customer had looked like this:

#include “MyInterfaceDefn.idl”

interface MyInterface;


Which parsed fine with the midl.exe included in Visual Studio 2005.  However, building with Orcas, the customer's code produced the following error:
MIDL2337 : unsatisfied forward declaration and referenced the last line of code in the same scope as "interface MyInterface;". 
It turns out the customer defined MyInterface in MyInterfaceDefn.idl and then put the declaration line right after the definition which, although worked fine in VS 2005, no longer is accepted by the new midl.exe.  The solution turned out to be simple - just put the forward declaration before the definition and everything compiles fine:
interface MyInterface;

#include “MyInterfaceDefn.idl”


The customer's code built an ran without any problems.  Unfortunately, this was just one of those kind of idiosyncratic pieces of code that worked ok under the old idl compiler, but when the Windows tools teams updated midl, no longer went through ok.  Luckily, the solution is trivial once you arrive at it.  Hopefully if you hit the same issue, this blog entry will put you on your merry way!
Ben Anderson
Visual C++ Libraries QA team
Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
  • Hi,

    Is there a list somewhere of these changes?

    Kind Regards,

    Lennie De Villiers

  • Please, please, please guys, talk to your managers and make them see that the C++ front-end is the most valuable piece of software you have.

    Why are ATL libraries neglected while .NET is eating all the resources. Why is taking precedence and opening up everything while OLE DB tooling is closed down in binary form for VS.

    It is not good news, and I can understand people moving away to .NET have had enough. However, it is obvious that C++ native support has been suffering because all the resources have gone to those green (and yellow Java for that matter) pastures.

    It is nonsense to work more on C++ CLI support than native libraries, OS and Win32.

    Please provide us with thin and fast OS and tools.

    Hearing that IDL compiler is upgraded is great news but far more work needs to be done to bring C++ back to support of GCC.

  • Your "solution" is a workaround, and if the affected code is in a third-party header it isn't a terribly practical one. The real solution is to fix MIDL so that it accepts re-declarations, just like any C or C++ compiler would.

  • There's something really important that you didn't mention, which is:

    Either you are trying to get this issue fixed (the post sounds like you would rather blame the tools team than get it fixed), or...

    WHY should the users work around this problem? What is inherently wrong with backwards (as opposed to forwards) declarations?

  • As has been pointed out, this post contains a workaround to a change in behavior between the Windows SDK's midl released with Vista and that released with Visual Studio 2005.  I am currently working with the owners of midl.exe on the Windows team to determine if the change was intentional and why so.  I'll post an update if I get some solid info.

  • Midl giving a forward declaration error is perfectly valid in the above scenario. The main idl file has a forward declaration for "interface MyInterface" which is actaully an unresolved forward declaration. The included idl file "#include “MyInterfaceDefn.idl” actually defines MyInterface as dispinterface. Please note that dispinterface is not the same as interface. So while the dispinterface was defined, the forward reference for the interface was unfulfilled.

Page 1 of 1 (6 items)