[geos-devel] SegmentString modeling

[Mateusz Łoskot]

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

http://en.wikipedia.org/wiki/Policy-based_design

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;
public:
     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 
Principle:

http://www.objectmentor.com/resources/articles/lsp.pdf


> 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++ :-)

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net