[boost] Re: boost.test covered in testing frameworks rundown

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
to
> 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,
which
> > 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
to
> DebugOutputString() when running in Windows doing development in Visual
> Studio.

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
actually
> > 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.

Gennadiy