Boost logo

Geometry :

Subject: [ggl] read_wkt and write_wkt
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-04-28 10:23:46

>> The read_wkt function currently returns true/false if it is successfully or
>> not, while inside lexical_cast<> is used which might throw an exception. I
>> would like to change this by returning void and always throw an exception if
>> it is not successful. Is this OK for everyone?
>> This exception is already defined as struct read_wkt_exception : public
>> geometry_exception, we need to move that geometry_exception to core. Is that
>> OK ?
> Both points sound fine to me.
OK, I'll change it then.
>> Boost defines an "exception/exception.hpp" which is not used by boost
>> libraries. At least not by e.g. spirit. So I derive from std::exception,
>> like most boost libraries do, is that OK?
> Boost folks usually like to avoid intra-dependencies, so I guess they
> don't have the intention to use Boost.Exception too much inside Boost.
> I propose to leave it like that for now. The second reason is that we
> don't know this library much for now. We can always integrate it in
> the future if we know it better and we realize it can bring us
> something.
OK, makes sense. Indeed it is written somewhere that boost libraries
should not use other boost libraries. I think in general this is an old
guideline, or applicable to specific libraries. We're using many things
of Boost which are specific for library programmers (remove_const) or
very handy (ranges).

>> About 2)
>> The "make_" prefix is normally reserved for object generators. This is one
>> but actually it is, more strictly, generating an manipulator (which is an
>> object). Is the "make_" prefix appropriate here? I thought I asked this
>> earlier but cannot find that mail so probably I didn't. Alternatively it
>> would be:
>> 1) cout << wkt_manip<G>(geometry) << endl
>> 2) cout << wkt(geometry) << end // because this will be most widely used
> I'd say that the make_prefix is used:
> - when the function generates an object whose constructor would
> otherwise need one or several template parameters
> - when the object is known by the user and usually explicitly
> manipulated by him (e.g. std::pair).
> Am I right to say that the wkt<> class is rather a "helper" class
> whose only purpose is to pass a geometry to a stream, and will never
> be used explicitly by the user for any other purpose? If it's the case
> then we should forget the make_ prefix and stick to wkt(geometry).
OK, makes also sense. I already did the veshape like this. So changing
the wkt is a small job, it is slightly more work to update the samples.
But it looks better indeed.
>> About 3)
>> The last one is prone to errors if geometry is not a geometry or not a tag.
>> It is not living in namespace ggl to enable the library to stream custom
>> geometries which are living outside the namespace ggl. So it is not in any
>> namespace. Bruno recently mailed me that this behaviour will never be
>> accepted by Boost so we have to re-add the namespace there, or remove it at
>> all.
> I really don't know what's allowed and what's not in this regard. We
> really should have a discussion on the Boost list about "is it allowed
> to enable operator<< for any class satisfying a given concept" and if
> yes, what are the rules to follow.
OK, the problem is actually also that it tries to stream everything not
streamable and then complains that it is not satisfying the concept.
I'll have a look again, didn't touch this part for months.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...

Geometry list run by mateusz at