I have an interface with name ICallbackNew defined a header file,lest call it common.h.
interface ICallbackNew
{
virtual HRESULT MyMethod() = 0;
};
I have included the header file in the idl file where my COM interface method COMMethod is defined.
[
object,
uuid(1479883E-51F8-4990-AFFA-9EC1F82AC2C1),
dual,
helpstring("IcPIMSSyncServiceHandler Interface"),
pointer_default(unique)
]
interface ICOMHandler : IDispatch
{
[id(1), helpstring("method COMMethod")] HRESULT COMMethod(const ICallbackNew* pCBNPtr);
};
When I try to compile my code in VS2013 i get compilation as below
.\handler.idl(52): error MIDL2011: unresolved type declaration : ICallbackNew [ Parameter 'pCBNPtr' of Procedure 'COMMethod' ( Interface 'ICOMHandler ' ) ]
Can someone suggest what is going wrong in this?
You have a philosophical problem. When an object or function uses a callback, it is that object or function that defines the callback, not the client (the object or function that implements the callback). In other words, the callback's contract is a part of the server's contract. As such, it is not only technically necessary for you to declare your callback in your IDL, it is right. It must be a COM interface.
Technically: The MIDL compiler's primary job is to produce a type library (.tlb), a packet of metadata about the interfaces you've defined in the IDL. When given a raw C++ interface, the MIDL compiler doesn't have enough information to describe that interface in the type library. When it gets to that parameter, it treats it as an unknown, unresolvable data type.
Related
I am referring to the code in this link: Interfaces in Golang
Under the "Type assertions" section, the first piece of code has a line like so in the main function: var val interface {} = "Geeks for Geeks"
I did not understand this syntax. Usually, we create an interface type at the package level like
type some_interface interface {
// methods
}
and then create a variable of this interface type var s some_interface for use. What does this line actually do? Is it an "anonymous interface" (like anonymous struct). What is the use of declaring an interface using this method?
Thanks in advance
It is an empty interface, basically any type.
The empty interface
The interface type that specifies zero methods is known as the empty
interface:
interface{}
An empty interface may hold values of any type. (Every type implements
at least zero methods.)
Empty interfaces are used by code that handles values of unknown type.
For example, fmt.Print takes any number of arguments of type
interface{}.
I am curious why, in C++ 11, use of "= default" on a derived virtual method does not select the pure base class implementation.
For example, the following test code produces the message "error: 'virtual void B::tst()' cannot be defaulted" from "g++ -std=c++11".
struct A {
virtual ~A () = default;
virtual void tst () = 0;
};
void A :: tst () {}
struct B : public A {
virtual void tst () = default;
};
We can of course provide a B::tst that invokes the default base implementation, but one is concerned that this might be the higher overhead implementation compared to a hypothetical "= default" based coding.
Sorry to ask questions about what might or might not be within the minds of the c++ standards committee persons, but nevertheless perhaps someone here at stack overflow will have some wisdom concerning the impracticality of using the default keyword in this way that would be interesting to hear.
Thanks!
According to the standard §8.4.2/p1 Explicitly-defaulted functions [dcl.fct.def.default] (Emphasis Mine):
A function definition of the form:
attribute-specifier-seqopt decl-specifier-seqopt declarator
virt-specifier-seqopt = default;
is called an explicitly-defaulted definition. A function that is
explicitly defaulted shall
(1.1) — be a special member function,
(1.2) — have the same declared function type (except for possibly differing ref-qualifiers and except that in
the case of a copy constructor or copy assignment operator, the parameter type may be “reference to
non-const T”, where T is the name of the member function’s class) as if it had been implicitly declared,
and
(1.3) — not have default arguments
Member function tst() is not a special member function. Thus, it cannot be defaulted.
Now specifying a member function of a class (e.g., class A) as pure virtual entails that any class that inherits from that class and you don't wan't it to be abstract as well must override that member function.
The code below contains a reference to Enum::name (notice no type parameter).
public static <T extends Enum<T>> ColumnType<T, String> enumColumn(Class<T> klazz) {
return simpleColumn((row, label) -> valueOf(klazz, row.getString(label)), Enum::name);
}
public static <T, R> ColumnType<T, R> simpleColumn(BiFunction<JsonObject, String, T> readFromJson,
Function<T, R> writeToDb) {
// ...
}
Javac reports a warning during compilation:
[WARNING] found raw type: java.lang.Enum missing type arguments for
generic class java.lang.Enum
Changing the expression to Enum<T>::name causes the warning to go away.
However Idea flags the Enum<T>::name version with a warning that:
Explicit type arguments can be inferred
In turn Eclipse (ECJ) doesn't report any problems with either formulation.
Which of the three approaches is correct?
On one hand raw types are rather nasty. If you try to put some other type argument e.g. Enum<Clause>::name will cause the compilation to fails so it's some extra protection.
On the other hand the above reference is equivalent to e -> e.name() lambda, and this formulation doesn't require type arguments.
Enviorment:
Java 8u91
IDEA 15.0.3 Community
ECJ 4.5.2
There is no such thing as a “raw method reference”. Whilst raw types exist to help the migration of pre-Generics code, there can’t be any pre-Generics usage of method references, hence there is no “compatibility mode” and type inference is the norm. The Java Language Specification §15.13. Method Reference Expressions states:
If a method or constructor is generic, the appropriate type arguments may either be inferred or provided explicitly. Similarly, the type arguments of a generic type mentioned by the method reference expression may be provided explicitly or inferred.
Method reference expressions are always poly expressions
So while you may call the type before the :: a “raw type” when it referes to a generic class without specifying type arguments, the compiler will still infer the generic type signature according to the target function type. That’s why producing a warning about “raw type usage” makes no sense here.
Note that, e.g.
BiFunction<List<String>,Integer,String> f1 = List::get;
Function<Enum<Thread.State>,String> f2 = Enum::name;
can be compiled with javac without any warning (the specification names similar examples where the type should get inferred), whereas
Function<Thread.State,String> f3 = Enum::name;
generates a warning. The specification says about this case:
In the second search, if P1, ..., Pn is not empty and P1 is a subtype of ReferenceType, then the method reference expression is treated as if it were a method invocation expression with argument expressions of types P2, ..., Pn. If ReferenceType is a raw type, and there exists a parameterization of this type, G<...>, that is a supertype of P1, the type to search is the result of capture conversion (§5.1.10) applied to G<...>;…
So in the above example, the compiler should infer Enum<Thread.State> as the parametrization of Enum that is a supertype of Thread.State to search for an appropriate method and come to the same result as for the f2 example. It somehow does work, though it generates the nonsensical raw type warning.
Since apparently, javac only generates this warning when it has to search for an appropriate supertype, there is a simple solution for your case. Just use the exact type to search:
public static <T extends Enum<T>> ColumnType<T, String> enumColumn(Class<T> klazz) {
return simpleColumn((row, label) -> valueOf(klazz, row.getString(label)), T::name);
}
This compiles without any warning.
Lets say I have this class in foobar-shared.lib:
class FooBar {
std::string m_helloWorld;
}
And I have a call in foobar-from.exe using SendCopyData like so:
extern HWND hMainWnd; // foobar-from.exe
{
FooBar fooBar;
HWND hWnd = FindAppWindow(); // foobar-to.exe
COPYDATASTRUCT cds;
cds.dwData = ('f'|('o'<<8)|('o'<<16));
cds.cbData = sizeof(FooBar);
cds.lpData = (LPVOID)fooBar;
SendCopyData(hWnd, (WPARAM)hMainWnd, (LPARAM)&cds);
}
When from a foobar-to.exe, I handle OnCopyData:
BOOL CMainFrame::OnCopyData(CWnd* pWnd, COPYDATASTRUCT* pCopyDataStruct) {
if (pCopyDataStruct->dwData==('f'|('o'<<8)|('o'<<16))) {
FooBar fooBar = *(FooBar *)pCopyDataStruct->lpData;
}
}
This worked fine when FooBar was a struct, but now that it's a class I get this error:
First-chance exception at 0x0064ef81 in foobar-to.exe: 0xC0000005:
Access violation reading location 0x0231dd7c.
I assumed originally that this was because my fooBar instance is on the stack, so I tried moving it to the heap but got a slightly different error (I can post the result here if necessary).
According to MSDN, "The data being passed must not contain pointers or other references to objects not accessible to the application receiving the data." so I suspect that this only possible with struct data. Am I correct?
you are both correct and incorrect.
your problem here is that you don't know the implementation details of std::string. unfortunately, it seems this (standard) class uses a dynamicaly allocated buffer to store its character data. that's why WM_COPYDATA doesn't work with it.
but if your class does not contain a pointer to any external data, as suggested in the documentation, then it would be perfectly valid to copy it using WM_COPYDATA. unfortunately, this greatly limits the possible types for members of your class.
(think WM_COPYDATA is like sending data over a network: you should take care of serializing your class before sending it out in the wild...)
Has anyone managed to do this? I tried making a managed wrapper class for IPropertyStore but am getting AccessViolationExceptions on the methods (i.e. IPropertyStore::GetValue) that take a pointer to PROPVARIANT (rendered as a MarshalAs(UnmanagedType.Struct) out parameter in my managed version) Probably my understanding of COM and interop is inadequate --- I'm not sure if the problems are in my PROPVARIANT struct declaration (which currently just uses StructLayout.Sequential, declares a sequence of bytes, and manually manipulates the bytes to get values of the various types in the union etc.), COM issues with what process owns what, or something else. I've tried various other versions of the PROPVARIANT such as using StructLayout.Explicit for the unions, nothing's worked. Retrieving PROPERTYKEYs with IPropertyStore::GetAt --- which is declared natively as taking a pointer to PROPERTYKEY and as having an out parameter of my own StructLayout.Sequential PROPERTYKEY in my wrapper --- works just fine, by the way.
You should check out http://code.msdn.microsoft.com/WindowsAPICodePack . It has support for consuming the Windows Property System, and a bunch of other windows shell capabilities. I think it's exactly what you are looking for.
Well, here's the version from MS.Internal.Interop (a trove of knowledge):
[StructLayout(LayoutKind.Sequential), FriendAccessAllowed]
internal struct PROPVARIANT
{
internal VARTYPE vt;
internal ushort wReserved1;
internal ushort wReserved2;
internal ushort wReserved3;
internal PropVariantUnion union;
}
[FriendAccessAllowed]
internal enum VARTYPE : short
{
VT_BSTR = 8,
VT_FILETIME = 0x40,
VT_LPSTR = 30,
// etc...
}
[StructLayout(LayoutKind.Explicit), FriendAccessAllowed]
internal struct PropVariantUnion
{
[FieldOffset(0)]
internal BLOB blob;
[FieldOffset(0)]
internal short boolVal;
// etc... see MS.Internal.Interop for full definition
}
These definitions will help you make sure your structures are at least correct. As for your other problems, I don't have an answer.