CPPMixerSplitterexample

CPPMixerSplitterexample

Postby greTol » 31 July 2014, 08:09

Hello,

I have some more specific questions regarding the source files of the "CPPMixerSplitterexample" that is provided by CO-LaN ("http://www.colan.org/Download/CAPEOPENMixerSplitterExamples.1.0.4.exe" , see attachment for orientation regarding the c++ source files):
A) Which files have to be written by myself and which files are automatically generated (e.g. by VisualStudio/ "MIDL tool")?
B) Which files "belong" to the actual unit operation?
C) Which files "belong" to the COM-Part, wrapping the unit operation?
D) Is it possible to use an own compiled unit operation and wrap the binaries with a "COM-Layer" to use it as a CAPE-OPEN compliant PMC?

Thanks in advance for any answers helping me to understand what is actually happening when the code tranforms to a PMC :-)

With best regards,

Gregor Tolksdorf
Attachments
CPPMixerSplitterSourceFiles.png
List of files being the visual studio source of the c++ MixerSplitterexample unit operation
CPPMixerSplitterSourceFiles.png (17.52 KiB) Viewed 45563 times
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: CPPMixerSplitterexample

Postby jasper » 31 July 2014, 09:40

The main CPP, h and def file (CPPMixerSplitterExample.cpp) are largely generated by visual studio as part of making a new project (new C++ project, ATL, default options, finish).

Class bodies, IDL and function headers are generated by the class wizard (new ATL class, simple) and implementing COM interfaces (right click class in the class view, add, implement interface, select the CAPE-OPEN tlb; I would recommend copying the tlb in the project folder for maintainability; this will also add #import with the full tlb path to stdafx.h, from which I would remove the full path as well as duplicate occurances (one will be added for each implemented interface); note that older version of the wizard have a bug that translate VARIANT_BOOL to BOOL, you will have to manually correct that).

Utility classes (BSTR, VARIANT) you can just copy. Or use ATL's versions.

The project TLB and import headers are generated from MIDL. The CAPE-OPEN inport headers are generated from MIDL. Both are part of the compilation step.

For the default COM server, you can remove the option to register the type library (second argument to (Un)RegisterServer); the only type information that should be relevant is that in the CAPE-OPEN type libs, and need not be registered as part of your DLL.

Resource.h and the rc file are generated by Visual studio. The rgs files are created for new COM classes, and you should remove the ones (including the reference from the resource file) for those classes that do not require registration. Change DECLARE_REGISTRY_RESOURCEID(IDR_XXXX) to DECLARE_NO_REGISTRY() for such classes. Typically only PMC primary objects require registration, as they need to be found by CoCreateInstance.

The aps file is a result of compilation, and can be removed if you like.

If you re-use files from this project or the project altogether, make sure to change the GUIDS (IDL file, rgs files; make sure to change the rgs files consistent with the IDL file).

I have stepped away myself from using ATL for CAPE-OPEN objects in favour of my own framework. Contact me if you are interested. Let me know if you have further questions.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: CPPMixerSplitterexample

Postby greTol » 07 August 2014, 15:36

Thank you Jasper.
After working through your answer and trying to reproduce it in VisualStudio2013 I now have new questions:

A) In order to re-use files from this project, GUIDs have to be changed. For the "CPPMixerSplitterUnitOperation Class" this is clear, but is it also necessary for all the 'internal' GUIDs, including "Collection Class","RealParameter Class", "MaterialPort Class" if the corresponding subclasses are not changed?

B) Do you suggest to re-use the "CAPEOPENBaseObject.h" or is it 'outdated' and not 'state of the art'?
To me it seems to be a good idea to have such a base class and derive all the other classes...

C) What are the advantages of your framework compared to ATL?
I'm especially interested to hear why you decided to step away from using ATL.
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: CPPMixerSplitterexample

Postby jasper » 07 August 2014, 15:58

A) in principle is it not necessary to change the GUIDS that do not appear in the registry. So the ones that belong to the classes with DECLARE_NO_REGISTRY. In my new framework I do not even assign GUIDs to such classes

B) the base object is fine. What is performed in example code is optimization that makes the code more difficult to understand, but is something I would definitely do for production code. Particularly, this includes:

- avoid all heap allocations where you can. Could for example be done by using std::vector or equivalent classes that are part of the unit class definition itself and that are resize()d when you need it. Only a resize that requires more space than the memory already in such a vector will lead to a heap allocation. Also pre-allocate VARIANTs containing arrays with a fixed length, and BSTR values that are used repeatedly

- avoid string matching by string comparison. More important for property package implementations material object calculations that get passed compound IDs and property identifier strings all the time. Make hash tables to look them up. For a unit operation, this might apply for example to a collection object. If you have a parameter or port collection that could potentially accommodate more than a few objects, implement the Item() by name function based upon a hash table lookup, using a pre-filled hash table.

C) ATL is perfect for creating COM objects in a generic framework. The requirements for CAPE-OPEN are much narrower and fairly easy to implement without the use of ATL. I stepped away from ATL at first because of clients that do not want to use commercial versions of MSVC, as they use different compilers in-house. There are certain aspects of writing COM objects that are not necessarily straight forward, for example aggregated objects, a proper IDispatch interface, but none of that needs to work in the context of CAPE-OPEN objects. Although the CAPE-OPEN interfaces are derived from the IDispatch interface, a CAPE-OPEN object needs to implement multiple CAPE-OPEN interfaces, the dispatch IDs of which clash. So IDispatch cannot properly work in CAPE-OPEN and nobody is depending on that. Would in any case be a performance killer. After After doing all that I found that the resulting code, due to not so high demands on the versatility of COM functionality, is a lot more straight forward to use than ATL.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: CPPMixerSplitterexample

Postby bcbooo » 10 August 2014, 07:57

Now I am using Visual Studio MFC DLL to develop CAPE-OPEN models, not ATL DLL. MFC DLL is bigger than ATL DLL, but more flexible.
bcbooo
 
Posts: 66
Joined: 22 November 2012, 06:41
Location: China

Re: CPPMixerSplitterexample

Postby jasper » 10 August 2014, 09:23

MFC and ATL are both part of Microsoft Visual Studio (at least professional). MFC is a windowing framework, and is well suited for GUI building. Its footprint is a bit bigger than ATL.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: CPPMixerSplitterexample

Postby greTol » 15 August 2014, 07:23

A) I want to create "standalone" unit operation objects that do not require other software except the PME that includes them. What do I have to deliver to my customer besides the dll? "Just" some installation routine to register the object in the registry?

B) Visual Studio registers the com component in the registry by default during compilation, right? Is there a way to prevent this and to register it later on?

C) Is there a feasible way to create CAPE-OPEN com objects without using Visual Studio?
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: CPPMixerSplitterexample

Postby jasper » 15 August 2014, 07:51

A) in all cases you can tell the linker to include everything to that just your DLL remains. An exception to that would be if you would require mixed .NET / Cpp support (/CLI command line option); in this case the DLL versions of the C++ runtime libraries must be used

B) By default, it does. You can turn this off (Project, properties, Linker, General, Register output)

C) Yes, don't use ATL or MFC. You will have to make your own COM objects, or use some third party toolboxes to do so. There are also other environments (Delphi for example) that make COM objects for you.

Will you attend the AGM in Frankfurt this year?
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: CPPMixerSplitterexample

Postby greTol » 15 August 2014, 13:40

I will arrive Tuesday in the late afternoon and attend the annual general meeting on Wednesday and Thursday.
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: CPPMixerSplitterexample

Postby jasper » 15 August 2014, 13:48

I may prepare a presentation on COM without ATL or MFC in the context of CAPE-OPEN. If not, feel free to ask me directly at the meeting.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain


Return to Unit Operations

Who is online

Users browsing this forum: No registered users and 1 guest

cron