From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-01-10 19:27:11
> That's something that in general, I would love to see for every Boost
> library: A list of what other libraries it depends on. Ideally, I'd love
> see a dependency graph between all the libraries. That way I can use a
> library without the fear of pulling in tons of other libraries (or having
> to wade through tons of headers).
Be aware that some dependencies may be optional. For example Boost.Test
present extention that uses boost::function based interfaces. But that
doesn't make it dependant on Boost.Function.
> I'm glad to hear that Boost.Test doesn't pull in too many other libraries.
> When I saw the shared_ptr I feared the worst. By the way, why is it using
> shared_ptr? Sure, it's convenient, but wouldn't it be better to minimize
> dependencies completely from other parts of Boost?
In most cases I am trying to either find an alternative solution or
implement one myself. In case of shared_ptr and alternative solution would
be to reimplement one myself which would be silly. shared_ptr is
comparetevly simple and widely portable. Another consideration was the fact
that current shared_ptr was definite choice for TR1 inclusion, which made it
almost part of standart.
> > Boost.Test supply 2 predefined log formats (human readable and XML,
> > you could select by command-line) and unit_test_log_formatter interface
> > you could implement for you own formats. What else do you need?
> One that we would need right off the bat is the ability to output the log
> DebugOutputString() when running in Windows doing development in Visual
Looks interesting. I consider adding it.
> What would be necessary to do that? Write a new unit_test_log?
No. You will need to implement unit_test_log_formatter interface.
unit_test_log has an interface to reset a formatter.
> > Did you really mean that Boost.Test is only PC oriented? Or it's
> > something different? Like: "If you aren't doing embedded development..."
> I meant it from the point of view of game development. If you're not doing
> PC development, you're doing something close to embedded systems
> development (game consoles, handhelds, etc).
That's ok I guess, but for number of people with non-gameing programming
expirience your comment could be ... misleading.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk