Re: [QGIS-Developer] QgsFeatureSource::getFeatures - why returning Iterator by value instead of pointer ?
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 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: 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; ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QgsFeatureSource::getFeatures - why returning Iterator by value instead of pointer ?
Hi Sandro On Fri, Oct 15, 2021 at 5:32 PM Sandro Santilli 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... Regards Martin ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] QgsFeatureSource::getFeatures - why returning Iterator by value instead of pointer ?
I'm still trying to understand why a QgsFeatureRequest that's being built with a DistanceWithin filter ends up loosing that at some point and reached the point in which: QgsFeatureIterator QgsPostgresFeatureSource::getFeatures( const QgsFeatureRequest ) Is returning: return QgsFeatureIterator( new QgsPostgresFeatureIterator( this, false, request ) ); My question is: why is a QgsFeatureIterator being constructed here, just for returning it as a value ? Why not returning a pointer instead, to allow subclasses to return whatever derived class they want ? --strk; Libre GIS consultant/developer https://strk.kbt.io/services.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
