Skip to content
This repository was archived by the owner on Aug 5, 2022. It is now read-only.
This repository was archived by the owner on Aug 5, 2022. It is now read-only.

Improve exception safety with smart pointers #311

Open

Description

@elfring

Would you like to wrap any pointer data members with the template class "std::unique_ptr"?

Update candidates:

Activity

  1. krocard commented on Nov 15, 2015

    @krocard
    Contributor

    I agree with you.

    Nevertheless we do not plan on updating the code to C++11 in one big bang. Rather each time some code is modified, it is updated in the same time.

    I will mark this enhancement as trivial. Maybe a newcomer will pick it up.

  2. divserge commented on Jan 10, 2017

    @divserge

    Hello everyone
    Is this enchantment still viable? I'd be glad to resolve this one.

  3. dawagner commented on Jan 11, 2017

    @dawagner
    Contributor

    Hi, @divserge. Is it still relevant and you are welcome to tackle it; thanks!

  4. DanielLowry commented on Jun 25, 2017

    @DanielLowry

    I took a quick look at this, starting at CParameterMgr and working upwards changing the necessary parameters/member variables. However, I hit an issue when hitting ConfigurableElementAggregator.cpp whereby it defines the following function pointer typedef (in .h):

    typedef bool (CConfigurableElement::*MatchesAggregationCriterion)() const;

    The issue being that in if the parameter for the doAggregate function is changed from a const * CConfigurableElement to a const std::unique_ptr then the function pointer dereferencing here:

    if(!(pConfigurableElement->*_pfnMatchesAggregationCriterion)())

    fails to work (as far as I can tell, because the ->* operator has not been defined properly for smart pointers...yet).

    The only other option I can see (though someone with better C++ will probably have something better) is to use shared pointers instead - then for this doAggregate issue in particular, presumably a raw pointer could also be created to the object (which in turn could then be used as in the code right now).

    Not ideal, but haven't got any other ideas off the top of my head.

    Any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions