Reputation: 4915
Have read this thread in stackoverflow: Strange class declaration
, but still confused with below code in foo.h
:
class Foo CHECKLEAKDCL {
I am sure that Foo should be the class name, since there are constructor and deconstructor which can imply this.
I cannot see any macro definition related with CHECKLEAKDCL in this .h file.
also I am confused with the answer for Strange class declaration , which saying that:
Q_CORE_EXPORT isn't an identifier. It's a platform-dependent macro, and it's used to signal a class that's intended to be used across library boundaries.
Can anyone give some more explanation of this?
UPDATE:
found this line in a .h file, which is included in foo.h
:
#define CHECKLEAKDCL : private CheckLeak
so the class declarition should be :
class Foo : private CheckLeak {
So Foo is extending CheckLeak, right?
Upvotes: 1
Views: 179
Reputation: 27365
We cannot tell exactly what it is, as we have even less information than you do.
Normally, I have seen such macros resolve to export macro, for the library.
That is, the value of it should be defined as dllexport
, dllimport
or extern
(depending on platform). When that is the case though, the macro appears before the class name.
Considering the macro appears after the class name, it can only resolve to a base class, or list of base classes, or an empty macro.
If you have the documentation, search for a base class that tracks or reports it's address to a memory tracker on construction and destruction.
Then, the code base should be compiled using a macrodefinition similar to this:
#define CHECKLEAKDCL() : private MemoryTrackingBaseClass
(where MemoryTrackingBaseClass
is the class I mentioned above - according to your edit, CheckLeak
).
If you want to simply compile, try using:
#define CHECKLEAKDCL()
Edit (addressing your update)
So Foo is extending CheckLeak, right?
Only when you want to check your application for leaks, using whatever CheckLeak
implements.
In a production environment (after you use the definition inheriting from CheckLeak
), you should probably define CHECKLEAKDCL
as an empty macro (for speed).
Upvotes: 1
Reputation: 791421
As you've discovered, CHECKLEAKDCL
is a macro that expands to the three tokens : private CheckLeak
. Presumably CheckLeak
is a class that adds some leak checking diagnostic behaviour to classes which inherit from it.
In general, this sort of obfuscation is not very helpful. Depending on the properties of CheckLeak
, this macro might have unintended side effects, such as turning what appears to be a standard layout class into a non-standard layout class.
It would also be hard to add CHECKLEAKDCL
to a class that wanted to inherit from another class for any other reason. (Are you supposed to class Foo CHECKLEAKDCL, public OtherBase
?)
Personally, if given the chance to improve this project I'd favour replacing this macro with its actual expansion in this case.
Upvotes: 0
Reputation: 35398
If you compile for windows (using Visual Studio), highly possible it will be evaluated to one of the Microsoft specific linkage identifiers, dllexport
or dllimport
:
https://msdn.microsoft.com/en-us/library/81h27t8c.aspx
It is used when you create a class which will be exported from a DLL or used from a DLL in an application, and dependig of this it's either evaluated to dllexport
(DLL exporting the class) or dllimport
(Application importing the class).
If you compile with GCC possibly it will evaluate to one of the gcc _-attribute__
s. Such as __attribute__ ((visibility ("default")))
(https://gcc.gnu.org/wiki/Visibility)
These extensions to the core C++ are provided by compilers to make certain tasks more easily achievable (https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html)
EDIT
After you updated the answer ... well, obviously you have a private inheritance from a class. But please note, this is a terrible macro you have there because
#define CHECKLEAKDCL : private CheckLeak
adds an :
in your class declaration so you cannot use that symbol anymore to inherit from base classes.
I'd recommend that you get rid of that macro altogether, if you cannot, do not use it, it will confuse your code.
Upvotes: 2