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

Reply via email to