From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 12:21:31
Markus Schöpflin <markus.schoepflin_at_[hidden]> writes:
>>> On the other hand, if you link to a DLL that uses the dynamic C
>>> runtime (/MT(d)) you should link your application using the
>>> dynamic C runtime as well, at least this is what Microsoft
>> Yes, nearly always. Of course, there are exceptions. A dynamic
>> library can be (and often is) organized to manage all of its own
>> resources, so it is isolated from the issues that occur when you
>> use different runtimes on both sides of the boundary. For example,
>> if you pass all resources via boost::shared_ptr<> ;-)
> I don't get it. Do you mean, if you use shared_ptr<>, you don't have a
> problem with the DLL boundary. I would doubt this.
Doubt no more: it's true. boost::shared_ptr is magical!
(It creates a deleter along with the count when you initialize it from
>> I understand that eventually we need to deal with platform-specific
>> needs, so I am certainly willing to consider this. However, I only
>> want to go this direction as a last resort. An important design
>> goal of Boost.Build is to be able to write "high-level" build
>> specifications which mostly insulate the user from
>> platform-/compiler-specific issues. If we can capture the "usual
>> intention" of the user in asking for a static or dynamic runtime
>> such that it chooses the right compiler option on Windows and does
>> something else everywhere else, that's better.
> Ok, then let's make two ortogonal features of this. (See my answer to
> Vladimir for details.)
I'm not certain that's what we want, but maybe it is. It might work if
Vladimir's "link everything static" feature is a composite which
includes the "static runtime" property... which of course would be
overridden by any explicit specification of runtime link preference.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk