macro
asmcad
# define WXDLLIMPEXP_CL
class WXDLLIMPEXP_CL classname {
....
..
why they do this? what does it mean? does anybody write code like
this?
thanks.
Victor Bazarov
It is quite possible that for some compiler (obviously not yours)
the WXDLLIMEXP_CL macro will actually be defined. For your compiler
it is not needed, so it's defined as nothing. Don't let it bother
you. wxWidgets is an old and respectable library.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
asmcad
anyway thanks.
Sam
Some technically flawed operating systems may require usage of some
non-standard keywords in order to define certain attributes of classes that
must be specified in order to get the wanted results.
Your library's configuration script will install the appropriate definition
of this macro, when your library is installed on that particular operating
system.
Jeff Schwab
What the heck has this got to do with the operating system? The OS
doesn't know anything about C++ class definitions. Only compilers, and
conceivably other links in the tool chain, do. The _CL suffix may
indicate the MS compiler (cl.exe), but another compiler on the same OS
should be immune from whatever problem this solves.
"Fernando A. Gómez F."
In Visual C++, you usually do something like this:
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif
so you can use it with your class
class MYDLL_API CMyClass { ... };
When you're compiling from the DLL, MYDLL_EXPORTS is defined and thus
class __declspec(dllexport) CMyClass { ... }
telling the compiler that the class must be exported from the DLL. When
the header is compiled from another entity (say, the main application),
it expands to __declspec(dllimport) telling the compiler that the class'
implementation is found in another DLL.
Since this is an extension of the Visual C++ compiler, I'd say that
wxWidget simply defines WXDLLIMPEXP_CL without a value so that it won't
crash in other compilers, like gcc.
Regards.
--
Fernando Gómez
www.fermasmas.com
Sam
> Sam wrote:
>> asmcad writes:
>>
>>> i'm using wxWidget and i saw same strange macro:
>>>
>>> # define WXDLLIMPEXP_CL
>>>
>>> class WXDLLIMPEXP_CL classname {
>>> ....
>>> ..
>>>
>>> why they do this? what does it mean? does anybody write code like
>>> this?
>>
>> Some technically flawed operating systems may require usage of some
>> non-standard keywords in order to define certain attributes of classes
>> that must be specified in order to get the wanted results.
>>
>> Your library's configuration script will install the appropriate
>> definition of this macro, when your library is installed on that
>> particular operating system.
>
> What the heck has this got to do with the operating system? The OS
> doesn't know anything about C++ class definitions.
But the C++ compiler does have to know a lot about the operating system.
After all, it runs on it.
> Only compilers, and
> conceivably other links in the tool chain, do.
That's right. And, guess what is tasked with compiling the above code?
> The _CL suffix may
> indicate the MS compiler (cl.exe),
Actually, the big honking clue (which you completely missed) is the "DLL"
and "IMP" and "EXP" parts.
> but another compiler on the same OS
> should be immune from whatever problem this solves.
No, I'm pretty sure that any compiler would have to deal with the
vulgarities of MS-Windows' binary APIs.
asmcad
(i'm using gcc)
you can see a lots of samples on here :
http://codeblocks.sourcearchive.com/documentation/8.02-0ubuntu2/odcombo_8h-source.html
but it seems stupid!
because
it going like this when i check
class WXSMTH classname ; //ok
#define WXSMTH WXSOMETHNELSE // say ok
#define WXSOMETHNELSE // what the heck is this!
what is the purpose?
Victor Bazarov
The purpose is to keep the source code the same (the files that define
the classes) and make changes by either the command-line definition of
macros or by installing some additional headers that customize the
processing of the other headers.
If you're new to macros or conditional compilation, please get a good
book or join a decent project, and learn. Don't go around complaining
about something just because it's new to you.
* * *
A statement
#define BLAH
in itself is very meaningful because after the preprocessor sees it,
the macro is *defined* and can be used in some special way in other
places while compiling the same translation unit. Now, what you
are seeing is slightly different, but still very useful.
If I write in some header <mydefinitions.h>
#ifdef _UNIX
#define SOMETHING short
#else
#define SOMETHING
#endif
and later I write in some C++ implementation file
#include <mydefinitions.h>
SOMETHING int myvariable;
Then when I compile that file on Unix, I would get
short int myvariable;
but, when I compile that file on, say, Windows, I would get
int myvariable;
(I am not going into *why* that might be useful, it's just the
example I chose to give). Now, imagine that instead of the ifdef
in the hedear <mydefinitions.h> I have a custom header that when
installed on Unix contains
#define SOMETHING short
During the installation I rename the file 'mydefinitions.h'.
And on Windows I install another custom header (and rename it to
'mydefinitions.h'), which has
#define SOMETHING
Now, I don't need to change the C++ source at all and it does
not need any conditional directives either. The difference
between the OSes is resolved during installation. Or it could
be resolved in the compiler command line where I tell it to get
the relevant headers from the OS-specific directory, and in
those directories there are files 'mydefinitions.h' with their
respective contents, but different. There are many variations
of the possible solution to whatever is needed.
Now, if you need to find out what the macro can resolve to on
other systems than yours, look in the same file after installing
your library for all other compilers. Or contact the library
publisher's Technical Support.
asmcad
1 - i was already knew about macros or conditional compiling that you
wrote about!
2 - i m not complaining ; just trying to figure out what the fuck is
going on t hat code.
try to understand "deeply" before complain about somebody or
something!!! So ->
my exapmle isn't about built - in types (int, double, char..)
it's about "class".
SOMETHING int myvariable;
int myvariable;
after precompilation it's
short int myvariable; //it's ok
*********
class WXSMTH classname ; //ok
#define WXSMTH WXSOMETHNELSE // say ok
after compalation
class WXSOMETHNELSE classname -> is it compatible with c++ standart?
but the type is when "class" what would it be "WXSOMETHNELSE "? now
tel me if you know about something!! if you don't, just shut the fuck
up!
Bo Persson
>
> *********
>
> class WXSMTH classname ; //ok
> #define WXSMTH WXSOMETHNELSE // say ok
>
> after compalation
>
> class WXSOMETHNELSE classname -> is it compatible with c++
> standart?
>
> but the type is when "class" what would it be "WXSOMETHNELSE "? now
> tel me if you know about something!!
There is nothing in the C++ standard that can go where the macro is.
So it is defined to nothing!
For some compilers there just might be a language extension, like a
directive to the compiler, that could go into that place. Or there
could be some other reason, like windows.h containing empty macros
that, once upon a time, were used for 16 bit code. In order not to
break the old code, the macro namess are still there, but defined to
nothing.
Bo Persson
asmcad
ok.thank you Bo Persson.
James Kanze
> asmcad writes:
> > i'm using wxWidget and i saw same strange macro:
> > # define WXDLLIMPEXP_CL
> > class WXDLLIMPEXP_CL classname {
> > ....
> > ..
> > why they do this? what does it mean? does anybody write code
> > like this?
> Some technically flawed operating systems may require usage of
> some non-standard keywords in order to define certain
> attributes of classes that must be specified in order to get
> the wanted results.
Such OS's must be pretty rare, because I've not encountered
them. I've relatively little experience outside the Windows and
Unix worlds, but it's certainly not the case for Windows,
Solaris, AIX, HP-UX or Linux.
Different OS's do handle public declarations differently, and
Windows gives you a much finer granularity in managing what's
visible in a dynamically loaded object. (This is one place
where Windows is actually superior to Unix.) Which means that
you must somehow tell the program which builds the dynamic
object which symbols are exported, and which aren't. I believe
that some Windows compilers have an extension which allows doing
this in source code; I can imagine that in something like a GUI
library, such an extension might be very pratical, but I've
never really needed (or used) it for the DLL's I've written for
Windows; they typically only export a few symbols, so it's
easier to just tell the linker directly. (Actually, since you
have to give the linker the mangled name, I use a small script
to extract the mangled name from the object files. It's rather
easy to adapt the script to export individual functions, entire
classes, or only the public parts, or an entire namespace. In
my case, I usually export an entire namespace, but only from one
of the object files---a fassade---in the DLL. Or I export
nothing at all---the constructor of a static object registers
everything necessary with the global registry.)
> Your library's configuration script will install the
> appropriate definition of this macro, when your library is
> installed on that particular operating system.
It's trickier than that, I think. If you do use the compiler
extensions, you need to define the macro differently when
compiling the code going into the dynamic object, than when
compiling it in code which uses the dynamic object. (This is
the main reason why I avoid such extensions.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> Jeff Schwab writes:
> > but another compiler on the same OS should be immune from
> > whatever problem this solves.
> No, I'm pretty sure that any compiler would have to deal with
> the vulgarities of MS-Windows' binary APIs.
Windows uses COFF, which was originally designed by AT&T for
Unix, and is still used on some Unix systems (AIX, I think).
The question is one of which symbols are made available in the
final dynamic object for use from outside. The default on all
Unix linkers I know is all of them; the default for the VC++
linker is none. Neither are really a good idea---all of them
leads to namespace polution and name hijacking, and none is only
useful in a few limited cases (constructors of static objects in
the dynamic object register with some global registry). Most
linkers have additional options to modify the default. For
historical reasons, these are often not used under Unix
(resulting in everything being exported). Not specifying in
some way what symbols are exported isn't generally that useful
with VC++, however (since by default it exports nothing), so you
have the choice: specify the symbols in the command line which
invokes the linker, specify a .def file which specifies the
symbols (my usual solution) or use a VC++ compiler extension to
specify them in the source file. For large, complex dynamic
objects (like a GUI library), the latter is probably the
simplest solution, and it is the solution used almost
exclusively by Microsoft, so you tend to see it a lot. (On the
other hand, I wonder about the wisdom of using a dynamically
linked object for the GUI library.)
James Kanze
> -so it's just about not break the old code.
> ok.thank you Bo Persson.
You missed his point. It's to support different versions for
different systems, using the same source code.
Given the actual names in the original example, I would guess
that the library in question is delivered as a dynamically
loaded object (.so under Unix, .dll under Windows), and that the
macros expand to something which corresponds to a compiler
extension under Windows, and to nothing under Unix. Something
like the macros you'll see around the __attribute__ declarations
for code which is to be compiled by both g++ and other
compilers. (E.g.
#define NORETURN __attribute__((noreturn))
for g++, and
#define NORETURN
for other compilers.)