Re: Microsoft Pragma(lib) decls (was RE: [boost] Customer Friendlier Boost Installation)

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-05-26 14:23:41

At 11:08 2005-05-26, Bennett, Patrick wrote:

> > -----Original Message-----
> > From: boost-bounces_at_[hidden]
>[mailto:boost-bounces_at_[hidden]]
> > On Behalf Of Victor A. Wagner Jr.

[deleted]

> > >in with users having no idea how or why they're being linked against.
> > >Since many developers tend to be rather over-eager in #including
>headers
> > >(bah, just include it all!)
> >
> > sounds like "many developers" need to be re-edcuated.  or, perhaps,
>you
> > need better code walkthroughs.
>
>[Bennett, Patrick] Both.  :)  That doesn't change the fact that having
>object files which contain special decorations (inserted by a
>vendor-specific #pragma operation)

that's twice in 2 days that someone wants to pick on #pragma being "vendor 
specific"
I never suggested either time a literal "#pragma blah" to support this.

>which cause unspecified libraries to
>'automatically' get linked in is a 'bad thing.'
>For one, there's no official way to dump a list of these explicit link
>references for any given object file or lib/dll.

were the mechanism part of the standard, of course there would be an 
"official" way to find them

>The only way to (partially) know what might get linked in ahead of time
>is to go through a dedicated preprocessor step to verify what's being
>linked.  Of course, this just handles the case where the public
>(interface) headers of all libraries referenced contain pragma/lib
>entries.  It doesn't account for the libraries which defined pragma/lib
>entries for other libraries within their implementation headers [so the
>pragma node is only in the linkable file for that static lib or dll's
>import lib].  Thus, there's no way to 'know' up-front, and in an
>easy/fast manner, what libraries will actually be linked in when
>building a dll or exe in the presence of these lib pragma's.  They're
>bad, bad, bad.

you assumed things I didn't suggest.

>Vendors like Microsoft are certainly welcome to support them, but adding
>something like this to the 'standard' would be unacceptable (to me at
>least ;>).  If tool authors want to provide support for Microsoft's
>extension, that's fine too - it should just always be optional.
>
>When it comes to compiling and linking, I don't want the compiler or
>linker including anything more than I explicitly told it to include.
>
>If you disagree, well, hey, I guess we'll just have to agree to
>disagree.

no, I'm gonna convince you, lol.

>Cheers...
>Patrick Bennett

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"