Subject: [ggl] read_wkt and write_wkt
From: Bruno Lalande (bruno.lalande)
Date: 2009-04-28 05:11:08
> 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.
> 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
> 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).
> 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
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.
Geometry list run by mateusz at loskot.net