[geos-devel] Question about geos::io::Unload::Release()

[strk at refractions.net]

On Mon, Mar 13, 2006 at 02:20:11PM +0100, Mateusz Å?oskot wrote:
> strk at refractions.net wrote:
> >
> >I'd like to keep doing
> >
> >	A* ptr = A::instance():
> >
> >template should only be known by class A.
> 
> I don't agree.
> Template is not a type.
> It's a template for new type.
> Template is not a memory or objects, etc.
> You can use same tempalate to generate many similar objects:
> use template for singleton to make types A, B, C, etc. behaving as a 
> singleton.

Of course.
I meant that client code should not know about the templated implementation.

> >class A {
> >	Singleton<A> defaultInstance;
> >public:
> >	A* getDefaultInstance() { defaultInstance.instance(); }
> >};
> >
> >The template itself could return by ref, to make it clean.
> 
> Yes, but there are still problems explained in my latest post about 
> breaking Meyers' singleton.
> 
> >The template users (classes that want to provide default instances)
> >will keep returning pointers if this is what client code expects
> >(we can always add a return-ref version for new code written, anyway
> >so far pointers are most used to signal NULLS to class taking
> >it - those NULL will usually trigger use of the default instance).
> 
> I don't agree.
> You MUST NOT expect that singleton will be null, because it's always 
> instantiated! That's how singleton works.

I don't. I'm talking about some classes ctors that has nothing to do
with the singletons we're talkin about. They excepect a pointer, possibly
NULL. When the pointer is NULL they'd use the "default" instance of
that pointer type. Since getDefaultInstance() is going to be a new interface
there should be nothing to protect here.

> I'd also propose to not to double interfaces for references and 
> pointers. In example, this does not to seem resonable:
> 
> struct CoordinateLessThen {
> 	bool operator()(const Coordinate* a, const Coordinate* b) const;
> 	bool operator()(const Coordinate& a, const Coordinate& b) const;
> };
> 
> Why not to keep it simple
> 
> struct CoordinateLessThen {
> 	bool operator()(const Coordinate& a, const Coordinate& b) const;
> };

Because we use set<Coordinate> and set<Coordinate*> both needing an ordering
functor.

> This interface can work well with pointers (by dereferencing) and 
> references.

Feel free to simplify things when you see it fit.

> Simply, I'm trying to say that references are much more recommended 
> where pointers can be used.

I'm all for using refs when possible, but also consider sensible interfaces.
We want simple C++ users to still build. By 'simple' I mean the one only
using Geometry, CoordinateSequence, GeometryFactory and PrecisionModel.
Everything more "internal" (conceptually speaking) can be changed.

--strk;