[jira] [Commented] (MESOS-3214) Replace boost foreach with range-based for

["Klaus Ma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14659336#comment-14659336 ] 

Klaus Ma commented on MESOS-3214:
---------------------------------

+1 for option 1; it enforce all contributor to use range-based for. Option 2 is safer for production, but "foreach" & "range-based for" maybe mixed in the code without this background.

> Replace boost foreach with range-based for
> ------------------------------------------
>
>                 Key: MESOS-3214
>                 URL: https://issues.apache.org/jira/browse/MESOS-3214
>             Project: Mesos
>          Issue Type: Task
>          Components: stout
>            Reporter: Michael Park
>              Labels: mesosphere
>
> It's desirable to replace the boost {{foreach}} macro with the C++11 range-based {{for}}. This will help avoid some of the pitfalls of boost {{foreach}} such as dealing with types with commas in them, as well as improving compiler diagnostics by avoiding the macro expansion.
> One way to accomplish this is to replace the existing {{foreach (const Elem& elem, container)}} pattern with {{for (const Elem& elem : container)}}. We could support {{foreachkey}} and {{foreachvalue}} semantics via adaptors {{keys}} and {{values}} which would be used like this: {{for (const Key& key : keys(container))}}, {{for (const Value& value : values(container))}}. This leaves {{foreachpair}} which cannot be used with {{for}}. I think it would be desirable to support {{foreachpair}} for cases where the implicit unpacking is useful.
> Another approach is to keep {{foreach}}, {{foreachpair}}, {{foreachkey}} and {{foreachvalue}}, but simply implement them based on range-based {{for}}. For example, {{#define foreach(elem, container) for (elem : container)}}. While the consistency in the names is desirable, but unnecessary indirection of the macro definition is not.
> It's unclear to me which approach we would favor in Mesos, so please share your thoughts and preferences.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)