Refactoring #1622

Feature #1290: === Core: framework ===

Feature #1572: == Python ==

avoid smart pointers in user API

Added by wuttke about 4 years ago. Updated about 3 years ago.

Status:RejectedStart date:01 Nov 2016
Priority:LowDue date:
Assignee:-% Done:


Target version:-


While drafting an introductory Reference chapter, I wonder whether we want to expose a C++ API like

    GISASSimulation(const MultiLayer& p_sample);
    GISASSimulation(const std::shared_ptr<IMultiLayerBuilder> p_sample_builder);

Shouldn't we rather avoid smart pointers in the user API?


#1 Updated by wuttke about 4 years ago

  • Description updated (diff)

#2 Updated by pospelov about 4 years ago

SampleBuilder is, to my knowledge, is the only such usage in public API and it is somewhat special. It can be defined in Python and should stay alive during the simulation run. Smart pointer was the way to achieve it. May be there are other ways to achieve the same. In earlier version of the code (before April) it was

GISASSimulation(SampleBuilder_t p_sample_builder);

so the exact type was hidden with the possibility to redefine underlying typedef (leaving GISASSimulation constructor intact).

#3 Updated by wuttke about 4 years ago

  • Parent task changed from #1290 to #1572

#4 Updated by pospelov about 3 years ago

  • Status changed from Rfc to Rejected

Rejected, see #1823

Also available in: Atom PDF