Re: [vos-d] Re: struggling with Windows...
res wrote: On 16.08.2005 22:24, Braden McDaniel wrote: Well that's annoying. So why bother with msvcr71.dll at all? Why not just build with /MT instead and pull in the static library? What does using the DLL runtime buy you? Disk and RAM space savings if you have multiple modules. shrug Those are not so expensive that I'd make my life much more difficult for the improvement. YMMV, of course. One heap - you can free memory allocated in some other module. That's the major selling point. Doing without this is giving up a lot; nonetheless, I find myself considering strategies that would ameliorate its absence. And what exactly *is* annoying? Just put msvcr71.dll alongside your application - done. Distributing someone else's binary is annoying; establishing an authoritative source for it when creating a distribution on an arbitrary system would, I expect, be difficult. I suppose the solution to that is to stick it in revision control. retch But the real problem is for someone whose deliverable is a library rather than an application. If I want that library to be sharable by multiple applications, I can't very well have it depend on a library that Microsoft does not make sharable by multiple applications. Braden ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Re: struggling with Windows...
On Tue, 2005-08-16 at 22:11 -0400, Peter Amstutz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Aug 2005, Braden McDaniel wrote: One heap - you can free memory allocated in some other module. That's the major selling point. Doing without this is giving up a lot; nonetheless, I find myself considering strategies that would ameliorate its absence. Yea, for VOS this is pretty much essential. Besides the fact that most classes in VOS are reference counted (so may be deleted anywhere), That problem is solvable. For example, boost::shared_ptr lets you specify a custom deleter function. we pass objects like std::string around between DLLs quite a bit which of course does its underlying allocation on the heap. But the Microsoft std::string implementation is not COW, so I don't think this is a problem. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
