PRIVATE PUBLIC macros
 

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

Re: PRIVATE PUBLIC macros
 

Bilgehan.Balban@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.

Re: PRIVATE PUBLIC macros
 

Skarmander wrote:
> Bilgehan.Balban@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.

Re: PRIVATE PUBLIC macros
 

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)

Re: PRIVATE PUBLIC macros [OT]
 

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.

Re: PRIVATE PUBLIC macros [OT]
 

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)

Re: PRIVATE PUBLIC macros [OT]
 

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.

Re: PRIVATE PUBLIC macros [OT]
 

On Thu, 29 Dec 2005 14:39:01 +0100, in comp.lang.c , jacob navia
<jacob@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 =----