Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QMCPACK antipattern: Throw runtime error if override isn't implemented. #5308

Open
PDoakORNL opened this issue Feb 10, 2025 · 2 comments
Open

Comments

@PDoakORNL
Copy link
Contributor

PDoakORNL commented Feb 10, 2025

SPOSet::makeClone is a glaring example of this but I believe it is present many other places as well.

When you want to insure that all derived classes implement a method make it a pure virtual method i.e.

  /** make a clone of itself
   * every derived class must implement this to have threading working correctly.
   */
  virtual std::unique_ptr<SPOSetT> makeClone() const = 0;

This causes a compile time error as it should, and gives an immediate explanation. Any error that can be stopped at compile time should be.

Don't do this

   /** make a clone of itself
    * every derived class must implement this to have threading working correctly.  
    */
[[noreturn]] virtual std::unique_ptr<SPOSetT> makeClone() const;

A runtime error will someday occur hopefully its detailed enough make finding the mplementation that threw it easy, but potentially it will even be seen by a user and not at development time. This is not really a runtime error though is it.

@ye-luo
Copy link
Contributor

ye-luo commented Feb 10, 2025

I guess that was introduced to minimize a needed implementation for a new SPOSet. It is maybe needed for some functions but definitely not for makeClone.

I'd like to restrict the scope of this issue to SPOSet::makeClone to prevent long standing issues. If more were found, just report separate issues with reference to this one.

@PDoakORNL
Copy link
Contributor Author

I think you are right about long standing issues. We have far too many just lying open that were basically written to never die, this has proven to be bad practice. I think for those issues where its a coding style or design issue important enough it should go into the manual or other documentation. For the design issues where no agreement has ever been reached I think the competing sides should write up their designs, reference their example implementations in the code, prove the design meets the long term goals for the code and we should resolve the disagreements (input handling comes to mind).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants