Project

General

Profile

Task #652

Change selection method implementation to use C++

Added by Teemu Murtola almost 9 years ago. Updated over 2 years ago.

Status:
Blocked, need info
Priority:
Normal
Assignee:
-
Category:
selections
Target version:
Difficulty:
Close

Description

This would make it easier to publish the API for creating new selection methods in the C++ framework, and it would also make it more robust and easier to use and to maintain.

The current implementation should map quite straightforwardly to C++. gmx_ana_selmethod_t should be made into a base class or an interface with virtual methods for each function pointer currently used, and all places where it is used should be adapted accordingly. Implementations of individual keywords in sm_*.cpp should be changed to be subclasses of it. The main difficulty is in handling options (that currently use an array of gmx_ana_selparam_t structures). It should be possible to use the options implementation in src/gromacs/options/, but it will need a non-trivial extension.


Subtasks

Task #653: Extend options module for use in the selection engineClosedTeemu Murtola

Related issues

Related to GROMACS - Task #655: Improve selection error reporting / switch to exceptionsClosed01/09/2011
Blocked by GROMACS - Task #651: Increase coverage of selection unit testsClosed01/09/2011
Blocked by GROMACS - Task #880: Exception handling in selection parsingClosed02/05/2012

Associated revisions

Revision 28c1cfd7 (diff)
Added by Teemu Murtola about 7 years ago

Enable C++ use in selection methods.

The method that frees the internal data structure for a selection method
now also has the responsibility of freeing the data structure itself.
This makes it possible to allocate the data structure using operator new
in the initialization function, and then correctly free it.

Prerequisite for using C++ types in selection methods before #652 is
implemented.

Change-Id: I99e5a907cbdc4975d20becb0fb1d33e0026c135c

History

#1 Updated by Teemu Murtola almost 7 years ago

  • Target version set to future

#2 Updated by Teemu Murtola over 6 years ago

  • Status changed from New to Accepted

#3 Updated by Teemu Murtola over 6 years ago

  • Status changed from Accepted to In Progress

#4 Updated by Teemu Murtola over 6 years ago

  • Status changed from In Progress to Blocked, need info

Waiting for #653.

#5 Updated by Mark Abraham over 6 years ago

  • Target version changed from future to 5.0

#6 Updated by Teemu Murtola over 6 years ago

Is it realistic/necessary to plan to do this for 5.0? This is a large effort, with very little user-visible effects. Even the API doesn't change, unless we expose a way to add custom selection keywords (which this task would enable). Unless some extra refactoring is also done (haven't created any Redmine task for that yet), it may also make the C/C++ mixture in the selection code even messier...

#7 Updated by Mark Abraham over 6 years ago

  • Target version changed from 5.0 to future

Sorry, I was assuming it was part of plans in the area. Do feel free to re-target if it seems appropriate. :-)

#8 Updated by Teemu Murtola over 5 years ago

  • Project changed from Next-generation analysis tools to GROMACS
  • Category set to selections

Also available in: Atom PDF