PRIVATE PUBLIC macros

[Bilgehan.Balban]

Hi,

In some C code I see a PRIVATE macro corresponding to the static
keyword and a PUBLIC macro that has no correspondent. Why do people
prefer using such macros rather than using static? Better readability?

Thanks,
Bahadir

 

[Skarmander]

Hi,

In some C code I see a PRIVATE macro corresponding to the static
keyword and a PUBLIC macro that has no correspondent. Why do people
prefer using such macros rather than using static? Better readability?

No. They're C++/O-O programmers who *think* macros like this give better
readability. This is true only if you think C should be like C++, in which
case you shouldn't be using C and stick to C++.

Although macros are no substitute for knowing what you're doing and letting
others know as well, they're commonly used this way.

S.

 

[Flash Gordon]

No. They're C++/O-O programmers who *think* macros like this give better
readability. This is true only if you think C should be like C++, in
which case you shouldn't be using C and stick to C++.

Although macros are no substitute for knowing what you're doing and
letting others know as well, they're commonly used this way.

<OT>
They are also used because sometimes for using non-standard things like
DLLs you have to use non-standard things like __declspec(dllexport)
where on other systems you don't.
</OT>

 

[Richard Heathfield]

Flash Gordon said:

<OT>
[Macros] are also used because sometimes for using non-standard
things like DLLs you have to use non-standard things like
__declspec(dllexport) where on other systems you don't.
</OT>

I don't know of any system where _declspec(dllexport) *must* be used in DLL
code. It's certainly not the case in Windows. I've written loads of - well,
quite a few - Windows DLLs with nary a declwhatever in sight, and they
ported perfectly well to, say, Linux without changing a single line of
source. And no, I wasn't hiding everything behind macros either. You *do
not need* to write convoluted junk in a Windows DLL. (That doesn't mean you
can't, obviously.)

 

[jacob navia]

Richard Heathfield a écrit :

Flash Gordon said:

<OT>
[Macros] are also used because sometimes for using non-standard
things like DLLs you have to use non-standard things like
__declspec(dllexport) where on other systems you don't.
</OT>

I don't know of any system where _declspec(dllexport) *must* be used in DLL
code. It's certainly not the case in Windows. I've written loads of - well,
quite a few - Windows DLLs with nary a declwhatever in sight, and they
ported perfectly well to, say, Linux without changing a single line of
source. And no, I wasn't hiding everything behind macros either. You *do
not need* to write convoluted junk in a Windows DLL. (That doesn't mean you
can't, obviously.)

If you do not use __declspec(dllexport) how does the linker know
which symbols to export?

Obviously it soesn't, so that exports everything.

This works, but is inneficient, and can lead to name conflicts.
It is better to export only those names that you need to export
from a dll.

 

[Richard Heathfield]

jacob navia said:

If you do not use __declspec(dllexport) how does the linker know
which symbols to export?

By the use of a definitions file.

Obviously it soesn't, so that exports everything.

Wrong.

 

[Flash Gordon]

Richard Heathfield a écrit :

Flash Gordon said:

<OT>
[Macros] are also used because sometimes for using non-standard
things like DLLs you have to use non-standard things like
__declspec(dllexport) where on other systems you don't.
</OT>

I don't know of any system where _declspec(dllexport) *must* be used
in DLL code. It's certainly not the case in Windows. I've written
loads of - well, quite a few - Windows DLLs with nary a declwhatever
in sight, and they ported perfectly well to, say, Linux without
changing a single line of source. And no, I wasn't hiding everything
behind macros either. You *do not need* to write convoluted junk in a
Windows DLL. (That doesn't mean you can't, obviously.)

If you do not use __declspec(dllexport) how does the linker know
which symbols to export?

<snip OT stuff I happen to agree with>

This is all rather off topic. I was just wanting to point out that there
are reasons (whether good or bad) people sometimes use macros rather
than using extern, I did not intend to start a debate about the correct
way to export symbols from a DLL.

 

[Mark McIntyre]

If you do not use __declspec(dllexport) how does the linker know
which symbols to export?

*obviously* by some other means which is linker-dependent.
I'm actually surprised you don't know how to do this.

It is better to export only those names that you need to export
from a dll.

Indeed. I suspect that "static" will be helpful here.
Mark McIntyre