Re: Plugin Sample in C++ - IMPORTANT! SERIOUS ERROR!

[Mark Wieder]

Alexey-

Thanks. Good points.

(Mark sheepishly says)
No, I didn't test under VC++, I just trusted the code you posted
earlier and extrapolated from there. I'll look at changing the header
and repost it. This is the first time I've worked at including the
macro API and I have to say I find it pretty ugly.

One thing I'd like to see is a COM-type query function that would
enumerate the macro strings rather than making me catenate them at
design time. And Stefan's lack of comments makes TBP_ExecMacro a bit
of a joke as example code.

Also, tpxTotalPages and tpxTracking both evaluate to 248 and
tpxCurrentPage and tpxQuoteStyle both evaluate to 249. This can't
possibly be right, can it?

ANV This is main and critically serious error. Please, refer to
ANV other variants of API (which I
ANV referred on the top of the letter) and work more... I warn you about it because
ANV giving the wrong headers from the beginning can prefer many from writing such
ANV plugins.

Again, a very good point.

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.

Well, I could have sworn that, strictly speaking, functions were
illegal as struct members. However, that syntax seems to pass my
compilers without problem, so I have now changed it. Yes, it *is* just
cosmetic, but I wouldn't have made it a class if I thought I could
have gotten away with a struct.

ANV 2. If you write on CPP, why are you using malloc and free? Let use new and
ANV delete instead! CPP is not C, and although malloc and free still works, they are
ANV deprecated in CPP. Of course, this is also just cosmetic, and somebody who will
ANV use it will change it, but anywhere...

The main reason that malloc and free are deprecated is that their
usage can result in sloppy code that causes memory leaks. I've tried
to be very careful to free anything that was allocated and the one
case in which a memory block is not explicitly freed is notated in the
source (as it is in your source as well). Note that new without a
corresponding delete will cause the same memory leak as malloc without
a corresponding free.

My intention here is 1) to cut down the size of the code and increase
execution speed by not instantiating new objects unless absolutely
necessary, and 2) to minimize the chances of creating a problem
interfacing with Delphi with name mangling and such, since this is a
shared library and not a standalone application. Obviously both
approaches will work.

My idea here was to write as much simple C, not C++, code as possible
to minimize the chances of having to modify the code for other
compilers (i.e. not using vcl or MFC objects). This is the same
reasoning as above in using a struct instead of a class.

-- 
-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

Re: Plugin Sample in C++ - IMPORTANT! SERIOUS ERROR!

[Mark Wieder]

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