[gmx-developers] Some thoughts about new trajectory analisys api

[David van der Spoel]

On 2013-02-05 20:59, Roland Schulz wrote:
>
>
>
> On Tue, Feb 5, 2013 at 2:33 PM, Teemu Murtola <teemu.murtola at iki.fi
> <mailto:teemu.murtola at iki.fi>> wrote:
>
>
>
>             Actually that suggestion is very non-std like. It combines
>             access to the
>             complete range of coordinates ,with the algorithm (copy),
>             and thus is
>             less flexible because these two things can't be combined
>             differently.
>             So it might be better to provide: "iterator xBegin()" and
>             "iterator
>             xEnd()". That would allow to copy using:
>             "std::copy(sel.xBegin(),sel.__xEnd(),out)".
>
>     I think the best way is to provide a method like ConstArrayRef<rvec>
>     positionArray() const, which automatically gives those iterators as
>     well. Haven't tried this, but this should compile.
>
> That is indeed better. And much simpler. I didn't realize that the
> positions are stored in gmx_ana_pos_t::x  and that it is contiguous. I
> had assumed that the storage is a structs of positions (x,v,f,x,v,f,
> ..... ) and thus thought it would be more difficult.
>
>     But using std::copy() on a container of rvecs doesn't work, because
>     rvec is not copyable or assignable. This part still needs work, but
>     is a more general problem than just in the analysis framework.
>
> You're right. One of the reasons why we need to decide ASAP on a rvec
> replacement/extension.
>
>
>             But I'm not sure we discussed how much we want to make use
>             of iterators.
>             Our modified version changes that mpp uses iterators and we
>             think it got
>             better/more flexible by doing that. I think Teemu tried to
>             avoid them.
>
>
>     You are probably referring to http://redmine.gromacs.org/issues/856.
>
> Actually I had forgotten about that. I was commenting on the fact that
> you haven't implemented many custom iterators.
>
>     Overall, iterators are nice (and several classes in the code provide
>     iterator access or take iterators as parameters), but for that
>     particular case would have been tricky to implement (and would still
>     not have strictly fulfilled the strict requirements for an
>     iterator). Also, I'm using iterators extensively for loopring over
>     containers.
>
>
>         Iterators are not mentioned at all on
>         http://www.gromacs.org/index.__php?title=Developer_Zone/__Programming_Guide/Allowed_C%__2B%2B_Features
>         <http://www.gromacs.org/index.php?title=Developer_Zone/Programming_Guide/Allowed_C%2B%2B_Features>
>
>
>     It does mention that "do use STL". ;) And STL uses iterators
>     extensively. I see no reason to limit using iterators defined in
>     STL, nor implementing simple iterators for our custom classes. But
>     creating very complex iterators may not classify as "simple C++".
>
>
> I agree.

Looking at http://www.cplusplus.com/reference/stl/

To be on the safe side we can/should probably limit ourselves to C++98?

But is this the same as the example I mentioned using

std::vector<MyClass>::iterator ?


>
> Roland
>
>
>
> --
> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov <http://cmb.ornl.gov>
> 865-241-1537 <tel:865-241-1537>, ORNL PO BOX 2008 MS6309
>
>


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se