Object in C++?

[Russ Srole]

Just a curious... if someone creates a dll in c++ with objects, can we access the properties and methods? These are not com objects, more like the internal objects I and you create in PB. If it can be done, anybody have sample code?

TIA

[Fred Harris]

That question really gets at the fundamental reason COM was created Russ. I'll give my opinion which is based of course on my limited knowledge of the subject. When a C++ compiler creates a class (not a COM class) it can set up the internal memory footprint the way it wants to. That is, the memory allocations for the exported members aren't really specified in any way that an external program can know about. An external program using the same compiler will be able to link up and use the exported class objects because it knows how any objects created by itself are structured. I don't believe its even guaranteed that another C++ compiler will see the class in exactly the same way. So the exported C++ class may not even be usable by another C++ compiler - not to even mention PowerBASIC.

That is a large part of why Microsoft created the COM standard. If a C++ user (or PB user) creates a COM class as opposed to an ordinary C++ class then the memory footprint of where the member functions are laid out is something an external program created in any language can determine (because of the 'STANDARD'). If you know the address of a member function and its function signature and calling convention - then you can call it from any language.

Therefore, to answer your question, my opinion is no. If I were to attempt it, I'd use LoadLibrary() to load the Dll, and GetProcAddress() to attempt to obtain the address of some exported class symbol from the Dll (although I don't know what good that would do). Then it would be a hunt to try to determine at what memory address the member function within the class is at. You've got about 2 gigs of numbers to hunt through with no prior knowledge of where the function is at. See, that's the point! If its a COM class, then a standard is involved, and the member functions will be at exactly determinable locations within the interface memory footprint. It may be illuminating to consider that even with COM, the entry point function into the COM Dll is not located within any containing class - it is a simple exported dll function - dllGetClassObject(). It is that function that internally creates a 'standard' class object and returns the addresses of interface tables to interested programs.

[Russ Srole]

Fred,

Thanks for the lesson. I suspected something of this sort. In talking to the other vendor, I had suggested that they create some wrapper functions in good old winapi style and they agreed that not only would it make my life easier, but also other third party developers. Neither one of us wanted to screw around with com as it's more trouble then it's worth. The device I'll be talking to is very specialized and you can count on two hands the number of outside developers, so it isn't really very hard for them to keep us updated.

Russ

[Fred Harris]

That would be the way for them to proceed Russ. Pre - COM C++ objects were portable at the source code level but not at the binary level. A lot of the C++ language is standardized in terms of what will compile and what won't, and in terms of how C++ objects are to behave. However, the standards say nothing about how any C++ language vendor is to internally implement any c++ language construct. Probably the biggest offender is the proprietary name mangling scheme each vendor uses to support function overloading. Therefore, for someone marketing a C++ library add on product, they would have to provide the source code for the library of objects so that each purchaser would be able to link it against whatever compiler product they were using. There are some other somewhat esoteric ways around the problems for C++ users, but I'm not sure they would be of any help to PowerBASIC programmers. They involve using .def files to alias the mangled function names in the dll's export library against a custom import library.

So, a third party C++ developer producing an add on product would be best served by wrapping his internal classes in good old fashioned exported procedural functions if he/she wishes to interest the greatest number of potential buyers. That might seem kind of backwards, but unless COM is used, its the best solution.

[Michael Mattias]

So, a third party C++ developer producing an add on product would be best served by wrapping his internal classes in good old fashioned exported procedural functions if he/she wishes to interest the greatest number of potential buyers

... or into standard Component Object Model format?

A couple months ago while in "early phone discussion" with a potential customer for my EDI API, he asked to review the documentation : of the objects, properties and methods.

So now I'm thinking about offering this product with a COM interface. Sales ain't been all that great with the STDCALL interface, so why not?

MCM

[Fred Harris]

...review the documentation : of the objects, properties and methods.

Yup! As you know with your keen business sense Michael, that would be giving the customer exactly what he/she wants. And for the newer generation of programmers weaned on recent Microsoft products it may be all they know.

If you wrap your procedural libraries in COM classes, I expect the auto-generated type libraries would be readable by Microsoft's high powered Visual Studio products, and your methods/properties, etc, would show up in their 'intellisense' functionality. I expect someone such as yourself from the 'old school', so to speak, may dismiss such things as frivolous, I think they are important to the folks using Microsoft products. Heck, I'd like to see intellisense myself in my editors. So in other words, there may be folks out there who might have a need for your product who simply wouldn't know what to do with a dll and include file, but with a registered COM component that shows up in their type library system, they are ready to go.

[Michael Mattias]

And for the newer generation of programmers weaned on recent Microsoft products it may be all they know.

Amen, my brother!