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]

Bi*************@gmail.com wrote:

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]

Skarmander wrote:

Bi*************@gmail.com wrote:

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.

<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>
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

jacob navia wrote:

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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Mark McIntyre]

On Thu, 29 Dec 2005 14:39:01 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----