Hello, Mark. You wrote in <mid:[EMAIL PROTECTED]>
ANV>> 1. Strictly speaking, the interface is defined as struct. (there is line in the ANV>> header: #define interface struct. So, I would change your code by using word ANV>> "struct" if "interface" is undefined, and also "public:" is not necessary in ANV>> this case. But, repeat, this is only cosmetic. MW> Well, I could have sworn that, strictly speaking, functions were MW> illegal as struct members. However, that syntax seems to pass my MW> compilers without problem, so I have now changed it. Yes, it *is* just MW> cosmetic, but I wouldn't have made it a class if I thought I could MW> have gotten away with a struct. This was no more than a line from VC98\Include\objbase.h (and also from some others standard microsoft headers): #define interface struct Of course, it may be not so good to define structure contains methods. Also I think it can be noticed that interfaces usually declared as pure abstract classes. Of course it is no difference for working code, but it would be more informative for debugging during initial code creation. I mean, that if user will accidentally define a variable of class ITBPDataProvider, he will receive rather more informative message that it is unable to substantiate fully abstract class, then simple "unresolved external" or that function declared but not defined. It will help to beginners to differentiate between logical and technical bugs. So, for this purpose I think it is also useful to change the declaration of ITBPDataProvider to be like: ,----- [ just add " = 0" to make every function abstract ] | #if defined(interface) | interface DECLSPEC_UUID("9DD91B89-A551-4180-8A81-2CCF584CD4BF") ITBPDataProvider | : public IUnknown | #else | struct ITBPDataProvider // (also must be ): public IUnknown | #endif | { | public: | virtual int TBP_EXPORT GetDataByID(int ID, void* B, int BSize) = 0; | virtual int TBP_EXPORT SetDataByID(int ID, void* B, int BSize) = 0; | virtual int TBP_EXPORT GetIntValue(int ID) = 0; | virtual int TBP_EXPORT SetIntValue(int ID, int Value) = 0; | virtual int TBP_EXPORT GetIDType(int ID) = 0; | virtual int TBP_EXPORT ItemCount() = 0; | virtual HRESULT TBP_EXPORT ExecuteMacro(void* AMacro, int MaxLen,ITBPDataProvider* x) = 0; | }; `----- MW> My intention here is 1) to cut down the size of the code and increase MW> execution speed by not instantiating new objects unless absolutely MW> necessary, and 2) to minimize the chances of creating a problem MW> interfacing with Delphi with name mangling and such, since this is a MW> shared library and not a standalone application. Obviously both MW> approaches will work. Well. I agree with you at this point. My intention is to make most faithful translation from Delphi to CPP, and also to keep the things which is may be not so necessary, but just make more comfort. By this reason, for example, I leave the absolute definitions of enum's members, like: ,----- | enum midx { | midxSubject = 1, | midxDate = 2, | midxComment = 3, | midxInReplyTo = 4, | midxMessageID = 5, | midxNewsgroups = 6, `----- and not ,----- | enum midx { | midxSubject = 1, | midxDate, | midxComment, | midxInReplyTo, | midxMessageID, | midxNewsgroups, `----- This is, of course, not necessary, but if I want quickly to found numberic value of midxNewsgroups - I can just found it's definition in the header, what is not so easy in the second case. MW> My idea here was to write as much simple C, not C++, code as possible MW> to minimize the chances of having to modify the code for other MW> compilers (i.e. not using vcl or MFC objects). This is the same MW> reasoning as above in using a struct instead of a class. This is well if there is no Interface definition, because it seems to be pure C++. I more intent in this case to use more code on ISO C++. It has nothing with vcl or mfc - just standard C++ library. For example, if I use CString - woe to me if compiler can't hold it! But if I use std::string - woe to compiler who can't compile it! -- Sincerely, Alexey. Using TB 2.0b2 on WinXP Pro SP1 (2600), spelling by ORFO2002 (CSAPI) ..with Kaspersky Antivirus Plugin (ver 3.5 Gold) & antispam filter BayesIt! 0.3b mailto:[EMAIL PROTECTED] ________________________________________________ http://www.silverstones.com/thebat/TBUDLInfo.html