1. 27 May, 2018 1 commit
  2. 26 May, 2018 1 commit
  3. 08 Feb, 2018 1 commit
  4. 02 Feb, 2018 1 commit
  5. 28 Jan, 2016 1 commit
  6. 02 Jun, 2015 1 commit
  7. 27 Jan, 2015 1 commit
    • Thomas Rodgers's avatar
      Clean up of metadata_t · 1c72bf4e
      Thomas Rodgers authored
      * There is no clear reason why the map should hold const std::strings
      * This class is never derived, there doesn't seem to be a compelling
        reason to ever do so, so no need to make virtual members
      * In general const member data is an anti-pattern, the *only* reason
        is to prevent assignability, and the accepted idiom for that is to
        to declare the assigment operator private. This change does so, and
        also prevents copy construction.
      1c72bf4e
  8. 22 Jan, 2015 1 commit
  9. 24 Jul, 2014 1 commit
    • Ewen McNeill's avatar
      Remove "const" from std::map key · 217e0ae9
      Ewen McNeill authored
      Updated:
          src/metdata.hpp: Remove explicit "const" from key of std::map<>
             because the key is implicitly const already (see
             http://en.cppreference.com/w/cpp/container/map and
             http://www.cplusplus.com/reference/map/map/).
      
      On some platforms (such as z/OS UNIX System Services) explicitly
      declaring the map key as "const" causes template expansion errors
      as it tries to create separate allocators for "const const std::string"
      and "const std::string" only to find that they clash.  (Presumably
      some compilers collapse these into one earlier.)
      
      There are no template expansion errors if the map key is left to be
      implicitly const.
      217e0ae9
  10. 03 May, 2014 1 commit
  11. 02 May, 2014 1 commit
  12. 01 May, 2014 1 commit