[
https://issues.apache.org/jira/browse/MESOS-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-3741:
------------------------------------
Description:
stout exposes a number of containers ({{hashmap}}, {{hashset}}, {{list}},
{{multihashmap}}, and {{set}}) which {{publicly}} inherit from their STL
counterparts since MESOS-3217. This code being in stout means these custom
containers live in the global namespace.
Classes inherited publicly from STL containers are not generally safe to use as
the STL containers lack {{virtual}} destructors, so that deleting through a
ptr-to-base will not invoke the base dtr and leak memory. It appears this is
being made worse by e.g. putting the stout containers (which are often named
like their STL counterparts) in the global namespace which makes it easy to
confuse the actual type being used (at least in messy user code containing
{{using namespace std;}} which is not allowed for good reasons like this in
mesos code).
It would seem better to (1) decide what minimal set of containers still needs
to be provided now that C++11 can be used, (2) fix the inheritance for the
stout containers (e.g. inherit {{privately}} or just compose), or at least (3)
use a dedicated namespace for these custom containers.
was:
stout exposes a number of containers ({{hashmap}}, {{hashset}}, {{list}},
{{multihashmap}}, and {{set}}) which {{publicly}} inherit from their STL
counterparts since MESOS-3217. This code being in stout means these custom
containers live in the global namespace.
Classes inherited publicly from STL containers are not generally safe to use as
the STL containers lack {{virtual}} destructors, so that deleting through a
ptr-to-base will not invoke the base dtr and leak memory. It appears this is
being made worse by e.g. putting the stout containers (which are often named
like their STL counterparts) in the global namespace which makes it easy to
confuse the actual type being used (at least in messy user code containing
{{using namespace std;}} which is not allowed for good reasons like this in
mesos code).
It would seem better to (1) decide what minimal set of containers still needs
to be provided now that C++11 can be used, (2) fix the inheritance for the
stout containers (e.g. inherit {{privately}}), or at least (3) use a dedicated
namespace for these custom containers.
> stout containers inherit from STL containers
> --------------------------------------------
>
> Key: MESOS-3741
> URL: https://issues.apache.org/jira/browse/MESOS-3741
> Project: Mesos
> Issue Type: Bug
> Components: stout
> Reporter: Benjamin Bannier
>
> stout exposes a number of containers ({{hashmap}}, {{hashset}}, {{list}},
> {{multihashmap}}, and {{set}}) which {{publicly}} inherit from their STL
> counterparts since MESOS-3217. This code being in stout means these custom
> containers live in the global namespace.
> Classes inherited publicly from STL containers are not generally safe to use
> as the STL containers lack {{virtual}} destructors, so that deleting through
> a ptr-to-base will not invoke the base dtr and leak memory. It appears this
> is being made worse by e.g. putting the stout containers (which are often
> named like their STL counterparts) in the global namespace which makes it
> easy to confuse the actual type being used (at least in messy user code
> containing {{using namespace std;}} which is not allowed for good reasons
> like this in mesos code).
> It would seem better to (1) decide what minimal set of containers still needs
> to be provided now that C++11 can be used, (2) fix the inheritance for the
> stout containers (e.g. inherit {{privately}} or just compose), or at least
> (3) use a dedicated namespace for these custom containers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
