Refactoring #1622

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

Feature #1572: == Python ==

avoid smart pointers in user API

Added by wuttke almost 4 years ago. Updated almost 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 almost 4 years ago

  • Description updated (diff)

#2 Updated by pospelov almost 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 over 3 years ago

  • Parent task changed from #1290 to #1572

#4 Updated by pospelov almost 3 years ago

  • Status changed from Rfc to Rejected

Rejected, see #1823

Also available in: Atom PDF