[geos-devel] SegmentString modeling

Mateusz Łoskot mateusz at loskot.net
Sat Feb 18 10:32:06 EST 2006

strk at refractions.net wrote:
> On Fri, Feb 17, 2006 at 06:55:02PM +0100, Mateusz Å?oskot wrote:
>>strk at refractions.net wrote:
>>>Need some help from C++ gurus. One of the new JTS classes expects to 
>>>modify the Coordinates associated with a SegmentString.
>>I wonder why SegmentString::pts is declared as
>>const CoordinateSequence* pts;
>>As I see, in JTS sources SegmentString::pts is not declared as const.
>>I'm not a Java guru but IMHO const in Java has similar meaning
>>as in C++.
> I've been the 'const' pusher in GEOS. I tried adding
> const-correctness here and there to help maintainance
> and reduce unneeded copies.

I mostly agree but in this case const does not make better 
const-correctness. Second, it causes problems as now while porting new 
class which requires mutable access to SegmentString::pts which is 
defined as const.

OK, I see one case when current solution makes const-correctness required:

void foo(const CoordinateSequence &a)
     // foo promises to not to modify 'a' object so
     // it requires SegmentString to hold 'a' as const pointer - as
     // it currently is defined

     // IMPORTANT!
     // if SegmentString holds 'a' by non-const pointer then foo
     // will fail because it cannot cast from const to non-const

     SegmentString b(&a);

This sentence market as IMPORTANT! is very important :-) in case you 
decide to move SegmentString::pts from const to non-const declaration - 
what I also suggested in my previous replies.
So, if there is some similar function defined as foo above then problems 
may occur.
I hope my explanation is clear. If my english it very poor then please 
let me know I'll try to make it clearer ;-)

Yesterday, I consulted the problem with my friend and he suggested to 
move this case to more "modern C++" design solution based on policies.
Policy-based design of classes was introduced by Andrei Alexandrescu


and comes extremely handy in such cases, especially when you may expect 
some design changes (just as this one about moving from const -> 
non-const problem) in future.

Here is simple example how to handle const and non-const versions of the 
same type using policies:

struct use_const
     typedef const A * pointer_type;

struct dont_use_const
     typedef A * pointer_type;

template <class ConstCorrectness>
class B
     typedef typename ConstCorrectness::pointer_type pointer_type;
     pointer_type a;
     B(pointer_type p) : a(p) {}
     pointer_type get() { return a; }

Now, you can define const version:

B<use_const> b(&a);

and non-const version:

B<dont_use_const> b(&a);

Both versions are interchangable and follows the Liskov Substitution 


> I could take the const out of SegmentString but I guess
> JTS code itself is not enough to tell what the intended
> behaviour is.

That's usually the big problem when porting from Java or C# to C++ :-)

Mateusz Łoskot

More information about the geos-devel mailing list