3

I have a simple .IDL file (iface.idl) which describes an IUnknown based interface:

import "unknwn.idl"; 
[
    uuid(80DFDD28-F033-431e-B027-CDD2078FC78A)
]
interface ISunPathCalc : IUnknown {
    HRESULT Square([in, out] long * pVal);
    HRESULT Cube([in, out] long * pVal);
};

When trying to compile it with midl /header iface.h iface.idl I'm getting 3 files: iface.h, iface_i.c and iface_p.c. The iface.h file contains a C++ declaration of ISunpathCalc interface:

#if defined(__cplusplus) && !defined(CINTERFACE)

    MIDL_INTERFACE("80DFDD28-F033-431e-B027-CDD2078FC78A")
    ISunPathCalc : public IUnknown
    {
    public:
        virtual HRESULT STDMETHODCALLTYPE Square( 
            /* [out][in] */ long *pVal) = 0;

        virtual HRESULT STDMETHODCALLTYPE Cube( 
            /* [out][in] */ long *pVal) = 0;

    };

#else   /* C style interface */

The remaining larger part of this file contains needless C stuff.

Q: Is there way to tell MIDL to generate only C++ part of header? Is it possible to switch off generation of iface_i.c and iface_p.c files and to force MIDL to generate a C++ definition instead?

UPD1:

I tried to add [local] attribute as specified here:

[
    local,
    uuid(80DFDD28-F033-431e-B027-CDD2078FC78A)
]

but without any success.

ezpresso
  • 7,896
  • 13
  • 62
  • 94
  • [local] just tells MIDL that you won't be using the interface across process boundaries, so it leaves out the marshaling code, but still does the headers. I don't think there is an option for doing only C++ headers. Given that the C-style interfaces get skipped over by the preprocessor, why do you care that they get generated in the first place? – BrendanMcK Jun 06 '11 at 21:55
  • Well. I like my room to be clean, as well as my code:) Speaking seriously, after the code of the interface is generated from IDL, I move it to a MinGW targeted project. However, some of the macro in C part raise an error messages. – ezpresso Jun 06 '11 at 22:44
  • This is very strange. Obviously since you say you don't need the C part that C part must not be compiled so if you get errors in there it means that guard `#define`s are not processes as expected and I'd guess this is the real problem you need to solve. – sharptooth Jun 07 '11 at 05:27

1 Answers1

3

Unfortunately there's no way of suppressing the C header generation.

Larry Osterman
  • 16,086
  • 32
  • 60
  • 1
    There's a workaround, `midl.exe /header nul /iid nul /proxy nul /dlldata nul file.idl`, it will only generate `file.tlb`. – acelent Nov 10 '12 at 18:40
  • 1
    That suppresses ALL header generation, the question was how to suppress the C language generation (as opposed to the C++ language generation) – Larry Osterman Nov 11 '12 at 18:14
  • You're right, I misread the question, probably in a diagonal. – acelent Nov 11 '12 at 23:18