Helge Kruse wrote:
But I want to write some dissectors for my personal use. In this
dissectors I want to use my C++ classes and knowledge. The current
implementation cannot be used in a C++ project. The reasons are:
Use of reserved keywords.
The name class is used in as structure member.
Use of global definitions in header files.
The Xplugin_api_decls.h defines a lot of variables. This is valid in
plain C programs, but generates multiple defined globals when linking of
C++ object modules. This can be avoided, if they are declared as extern
in a header file an and defined in one implementation file. Since C++
programs often implement one class per source file, the
Xplugin_api_decls.h is included in multiple source files.
What do you think to change this two points in the Ethereal project?
We should avoid using "class" as a structure member name, or as anything
else that makes various Ethereal APIs unusable in C++.
That means renaming the "class" members of ber_sequence_t and
ber_choice_t (presumably your dissector is for a protocol using
BER-encoded ASN.1). Any votes on what it should be renamed to?
The right way to get rid of the problems with Xplugin_api_decls.h is to
ensure that an Ethereal plugin can be built without using any of the
"plugin API" mechanism - it should be possible to link it against the
libethereal library and have it directly refer to functions in
libethereal without having to go through pointers. The "plugin API"
mechanism was a hack used before libethereal was a DLL that let us, on
Windows, export its functions through standard DLL mechanisms; the only
reason I see to keep it around is to allow older plugins to continue
running, but, as we don't guarantee that the plugin ABI will remain the
same from release to release, we can't guarantee that older plugins will
continue to run in any case.
Is there any good reason whatsoever to continue to keep the "plugin API"
around? It's a pain to maintain it.
