macro

[asmcad]

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?

thanks.

 

[asmcad]

i m still curious about it because they use lots of like that macro.
anyway thanks.

 

[Fernando A. Gómez F.]

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.

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.

 

[asmcad]

i think it's not about the compiler or operating system (??) note:
(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 seem 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?

 

[asmcad]

i think it's not about the compiler or operating system (??) note:
(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?

 

[asmcad]

Victor Bazarav

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 **** is
going on t hat code.

please 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". So ;

SOMETHING int myvariable;
int myvariable;

after precompilation it's

short int myvariable;

*********


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 ****
up!

 

[asmcad]

Victor Bazarav

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

-so it's just about not break the old code.

ok.thank you Bo Persson.

 

[asmcad]

-so it's just about not break the old code.

ok.thank you Bo Persson.

 

[James Kanze]

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]

Jeff Schwab writes:

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