[QGIS-Developer] QgsFeatureSource::getFeatures - why returning Iterator by value instead of pointer ?

[Sandro Santilli]

On Sun, Oct 17, 2021 at 09:13:10PM +0200, Martin Dobias wrote:
> Hi Sandro
> 
> On Fri, Oct 15, 2021 at 5:32 PM Sandro Santilli <strk at kbt.io> wrote:
> 
> > My question is: why is a QgsFeatureIterator being constructed here,
> > just for returning it as a value ?
> 
> If I remember correctly, that's mainly for convenience in the client code,
> no need to deal with raw pointers that need to be deleted afterwards.
> QgsFeatureIterator also adds implicit sharing, just like many other Qt
> classes do (e.g. QString).
> 
> > Why not returning a pointer
> > instead, to allow subclasses to return whatever derived class they want ?
> 
> Well, in that code snippet we are already in a subclass that returns the
> derived class as wanted, so I am not sure if I understand your concern...

My problem is that I'm debug-printing properties of the
QgsFeatureRequest as passed to QgsFeatureProvider::getFeatures
and while the value passed to it has one kind of SpatialFilter
the value seen by QgsPostgresFeatureIterator (subclass of
QgsAbstractFeatureIterator) has a *different* SpatialFilter:

  XXXX request 0x7fe2f27fa4e0 for target source someData has spatialFilterType 2
  XXX QgsFeatureRequest::setFilterRect called on request 0x7fe2d40129a8 having spatialFilterType == 2
  XXX QgsPostgresFeatureSource::getFeatures called, request 0x7fe2d4012b18 has spatialFilterType 1

I'm printing the *pointer* value to try at following *when* things are
changing but as you see the pointer value keeps changing due to
copies...

Anyway, I'll fire a debugger and break on QgsFeatureRequest::setFilterRect,
which might be the problem here.

--strk;