Boost logo

Boost-Build :

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
>>> recommends.
>> 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
a pointer).

>> 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] *
Boost support, enhancements, training, and commercial distribution

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at