Boost logo

Geometry :

Subject: [ggl] Re: rtree ?
From: Barend Gehrels (barend)
Date: 2011-11-30 13:57:25

Hi Adam,

On 30-11-2011 4:39, Adam Wulkiewicz wrote:
> 2011/11/29 Barend Gehrels<barend_at_[hidden]>:
>> Great, of course. I did have a quick scan.
>> My first (and major) question is, why BoostBook? QuickBook is the popular
>> and recommended way, and besides that using QuickBook would interoperate
>> much better with Boost.Geometry documentation...
> I just wanted to start from more native interface since I've never
> used any of them. I've switched to QuickBook already. New version is
> available.

OK, cool. I see them indeed.

If you think about the full Doxygen->Quickbook chain, and I still
encourage that, I'll be happy to help you.
>> I have the same question for tests, why not the pattern Boost.Geometry is
>> using?
>> And for samples (there are not yet, no problem, but it would often be
>> helpful) please also conform to Boost.Geometry's current approach (i.e. a
>> sort of unit-samples, which can be very nicely integrated with QuickBook and
>> our conversion tool...)
> Should tests use hardcoded data or may it be randomized?
It should be verifiable, so this is usually hardcoded.

Besides that they should run fast.

> Or should
> there be 2 types od tests, if I want to use this kind of input? First,
> using not changing data for regression tests and the other one, using
> arbitrary data, for local testing only?

Two types is perfect. I'm doing that for Boost.Geometry as well. Most is
hardcoded. But I've also robustness tests with high volumes random data,
which is not in the normal unit test jamfile. So not called
automatically. Also because that would take too long.

Regards, Barend

Geometry list run by mateusz at