Hi,
I did try to keep as much as possible inside C++, adding a special place for
plain C workarounds. And so far
err =
(*iodev)->QueryInterface(iodev, CFUUIDGetUUIDBytes(...),(LPVOID)&dev);
appears to be the only place that misbehaves. More, the stuff even works. I
am more than surprised...
In case if I find any other such place, I am always ready to workaround it.
I think, G++ knows about that and does not joke any more. Is it that very
"magic key"?
Well, it is possible to do in PB C++ and use the code from CW C++. (The C
IMPort/EXPort (impex?) layer takes care of it all).
Best regards
Oleg
> From: email@hidden
> Date: Tue, 26 Mar 2002 10:15:26 -0800
> To: Oleg Svirgstin <email@hidden>, email@hidden
> Subject: Re: [OSX] Did anybody use USBLib with C++?
>
>
> On Friday, March 22, 2002, at 05:10 PM, Oleg Svirgstin wrote:
>
>> Hi,
>>
>> Sorry for putting such a stupid problem to the eyes of the respected
>> qualified public.
>>
>> Last time I wrote:
>>>> I have some problems with accessing calling "QueryInterface".
>>>> Is there an example of working with all these USB structures from C++?
>>
>> "email@hidden" answered:
>>> Are you using Apple C++ (from ProjectBuilder) or Metrowerks C++
>>> from CodeWarrior? Is your C++ app CFM?
>>
>> I am using both, MW C++ for the "Big Application" (which is CFM), and an
>> Apple C/C++ bundle for USB access when launched under the OSX.
>>
>> First I tried wrapping USB access into MW C/C++ and after a lot of
>> efforts
>> changed the approach to separate these OSX-only calls into a mach-0
>> bundle.
>> It looks like a good solution.
>>
>> Generally this approach works, I have got most of pieces of code
>> working for
>> the big app from the bundle (in plain C). Finally it is a mix of C and
>> C++
>> (with some extern "C" tricks), I tested various aspects of this mix - it
>> works, too.
>>
>> The problem arose when I started to assemble those pieces together,
>> wrapping
>> various plain C tasks into classes/objects.
>>
>> The problem (I found a working workaround, but I would love to find a
>> simple
>> correct way to do the things...) is like that (Apple C++):
>>
>> // I try to get IOUSBInterface from a device reference returned from
>> // IOGetMatchingServices. That piece of code worked fine in plain C.
>> //
>> // Omitting details, the C++ method where I have problems looks like
>> this:
>> //
>> // aClass::Method( io_service_t devRef)
>> // {
>> // IOCFPlugInInterface **iodev;
>> // IOUSBDeviceInterface **dev;
>> // ...
>> //
>> // IOCreatePlugInInterfaceForService(devRef,
>> // CFUUIDGetUUIDBytes(...),
>> // &iodev, &score);
>> //
>> // err = (*iodev)->QueryInterface(iodev, CFUUIDGetUUIDBytes(...),
>> // (LPVOID)&dev);//here I can't compile
>> // ...
>> // }
>> //
>>
>> The diagnostic tells "ANSI C++ forbids implicit conversions from
>> "void*" in
>> argument passing". I would be happy to know, where such conversion could
>> happen, since I pass arguments some of which are typed differently from
>> what
>> the plain-C interface wanted. (As far as I can see, I did not enforce
>> any
>> "strict ansi" anywhere - Apple C++ diagnostics and flags are a nice
>> saga of
>> its own.)
>>
>> QueryInterface expects a void *thisPointer where I pass it a
>> "IOCFPlugInInterface **", but it would be rather a conversion "to void*"
>> than "from void*". I tried to cast iodev in various ways to "void*",
>> and it
>> drives me mad when I think there must be an easy variant I just did not
>> find. (Does it want a void**?)
>>
> [....]
>> Now the bundle starts to look like a multi-layered sandwich
>> (C-interface to
>> communicate with the big app, then C++ complex of classes, calling here
>> and
>> there another level of C routines to do some house-keeping...
> [....]
>> Best regards
>> Thanks in advance for any suggestions
>> OIeg
>
> I also encountered the warning about void * with IOKit and Apple (g)++.
> The result I came up with is the same as yours basically - all of my
> files which deal directly with IOKit types and interfaces are .c files.
> If someone knows the magic compiler switch to make this stuff work
> with the C++ compiler I'd also like to know. However since you're
> going from PB to CodeWarrior you might be better off sticking
> with C since there are potential implementation incompatibilities
> between Apple C++ and MSL C++ (e.g. standard library classes)
>
> I don't know if it's possible to avoid the layering you describe but
> it may at least be possible to factor it cleanly. You may want to
> gather the various IOKit types into a common data type (probably
> a C struct) representing a single device or interface, then have
> your module deal with that. When going to the CFM layer you can
> declare an opaque (void *) type to wrap your struct so that no
> one in CFM-land needs to know anything about the IOKit types.
>
> hth,
> Chris
_______________________________________________
usb mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/usb
Do not post admin requests to the list. They will be ignored.
