Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-185

Update "Using Boost" section in DM Developer Guide to prefer standard library by default

    XMLWordPrintable

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      With DM-5880, DM-4035, DM-4036, DM-4014 and DM-5879 usage of Boost within the stack has decreased. This will require modifying the "Using Boost" section in the DM Developer Guide.
      Rather then specifying a list of Boost libraries / functions that are not to be used anymore, I propose to add a new default rule to the effect that "The C++11 standard library should be preferred over Boost equivalents wherever possible." Possibly followed by a list of exceptions.
      This puts the responsibility with the developer (and the reviewer) to check if a standard library equivalent is available whenever a Boost function is used.
      This change will not affect the list of libraries not allowed in the stack (or only allowed after review).

        Attachments

          Issue Links

            Activity

            Hide
            frossie Frossie Economou added a comment -

            No objections from the SQuaRE side, if that really works for our C++ developers, this would be great.

            Show
            frossie Frossie Economou added a comment - No objections from the SQuaRE side, if that really works for our C++ developers, this would be great.
            Hide
            ktl Kian-Tat Lim added a comment -

            I have no objection to the principle.

            The existing text says "unless the feature is already supported by the currently-mandated LSST g++ version", so this is more a change of emphasis than rule.

            Having some examples of previously-commonly-used Boost libraries that are now replaced by std:: equivalents (which is already in the existing text) seems useful; I wouldn't remove that and might add to it, even if such a list is just indicative and not normative.

            Presumably the "safe" list (edited?) remains in addition to the "design review" and "do not use" lists.

            Show
            ktl Kian-Tat Lim added a comment - I have no objection to the principle. The existing text says "unless the feature is already supported by the currently-mandated LSST g++ version", so this is more a change of emphasis than rule. Having some examples of previously-commonly-used Boost libraries that are now replaced by std:: equivalents (which is already in the existing text) seems useful; I wouldn't remove that and might add to it, even if such a list is just indicative and not normative. Presumably the "safe" list (edited?) remains in addition to the "design review" and "do not use" lists.
            Hide
            fritzm Fritz Mueller added a comment -

            Just at note here: std::regex should be on the "do not use" list, until we retire gcc 4.8. And after gcc 4.8, preferring std::regex is not even a slam dunk – it may work for many simple purposes, but it is missing some pretty basic features (e.g. named captures).

            (Some may argue people who use regexps should themselves be on the "do not use" list...)

            Show
            fritzm Fritz Mueller added a comment - Just at note here: std::regex should be on the "do not use" list, until we retire gcc 4.8. And after gcc 4.8, preferring std::regex is not even a slam dunk – it may work for many simple purposes, but it is missing some pretty basic features (e.g. named captures). (Some may argue people who use regexps should themselves be on the "do not use" list...)
            Hide
            tjenness Tim Jenness added a comment - - edited

            Pim Schellart [X] I think you can adopt this (don't forget to attach the implementation ticket).

            Show
            tjenness Tim Jenness added a comment - - edited Pim Schellart [X] I think you can adopt this (don't forget to attach the implementation ticket).
            Hide
            pschella Pim Schellart [X] (Inactive) added a comment -

            No objections, adopted taking into account suggestions.
            Will be implemented in DM-6360.

            Show
            pschella Pim Schellart [X] (Inactive) added a comment - No objections, adopted taking into account suggestions. Will be implemented in DM-6360 .

              People

              Assignee:
              pschella Pim Schellart [X] (Inactive)
              Reporter:
              pschella Pim Schellart [X] (Inactive)
              Watchers:
              Fritz Mueller, Frossie Economou, John Swinbank, Kian-Tat Lim, Pim Schellart [X] (Inactive), Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                  Jenkins

                  No builds found.