You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Benjamin Bannier (JIRA)" <ji...@apache.org> on 2015/10/15 09:06:06 UTC
[jira] [Updated] (MESOS-3741) stout containers inherit from STL
containers
[ 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)