Alexey-
Wednesday, August 20, 2003, 1:18:31 AM, you wrote:
ANV> | virtual int TBP_EXPORT GetDataByID(int ID, void* B, int BSize) = 0;
Making the member functions abstract won't hurt, but I think they will
only help debug TB itself, since instantiation isn't done within the
DLL. Nonetheless, it seems like good practice here.
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.
ANV> Well. I agree with you at this point. My intention is to make most faithful
ANV> translation from Delphi to CPP, and also to keep the things which is may be not
ANV> so necessary, but just make more comfort. By this reason, for example, I leave
ANV> the absolute definitions of enum's members, like:
ANV> ,-----
ANV> | enum midx {
ANV> | midxSubject = 1,
ANV> | midxDate = 2,
ANV> | midxComment = 3,
ANV> | midxInReplyTo = 4,
ANV> | midxMessageID = 5,
ANV> | midxNewsgroups = 6,
ANV> `-----
The only problem here is what happens when ritlabs decides to redo
things and insert, for example, midxMessageNumber in between
midxMessageID and midxNewsgroups. If you have things hardcoded you
will need to renumber everything past entry six. If you just declare
the first then you simply insert a line in your source.
ANV> This is well if there is no Interface definition, because it seems to be pure
ANV> C++. I more intent in this case to use more code on ISO C++. It has nothing with
ANV> vcl or mfc - just standard C++ library. For example, if I use CString - woe to
ANV> me if compiler can't hold it! But if I use std::string - woe to compiler who
ANV> can't compile it!
<grin>
Actually, given
struct xyz : public IUnknown
{
}
the line between struct and class is getting very blurred...
There's another anomaly in my source: I typedef'd PChar as char*
instead of unsigned char* because Codewarrior complained if I didn't
explicitly cast the result. It seemed easier just to say char and hope
there weren't any repercussions down the line.
--
-Mark Wieder
Using The Bat! v1.63 Beta/7 on Windows 2000 5.0 Build 2195 Service Pack 2
________________________________________________
http://www.silverstones.com/thebat/TBUDLInfo.html
