The begin/end non-member functions are currently on the “To Be Discussed” list. They are especially useful for using the std iterator-style APIs with fixed-size arrays. I implemented std::end for fixed-size arrays manually in several places to work around std::end being banned. Is there any harm in allowing it now?
When you say "implemented it manually", are you talking about using something other than https://code.google.com/p/chromium/codesearch#chromium/src/base/macros.h&l=47 ?
When you say "implemented it manually", are you talking about using something other than https://code.google.com/p/chromium/codesearch#chromium/src/base/macros.h&l=47 ?Yes. std::end returns a pointer past the end of an array, not the size of the array. See for example here.
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACvaWvb_Oq6zDGBavmOep3pmyc8U3EUNynVHHo9Ge6_uCB8bvA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaS_5i0es1E9%2BOWiNLO71gX9JmoAA-BKqaETPSxmm2Yb7g%40mail.gmail.com.
Should we just be overriding "std::begin" and "std::end" now instead of implementing it in the global namespace?I was recently pointed at a part of the C++11 spec that says this is OK now, and making std::begin do the right thing seems better than relying on people remembering the "using" trick. Is this actually recommended nowadays?
On Sunday, November 22, 2015, Brett Wilson <bre...@chromium.org> wrote:Should we just be overriding "std::begin" and "std::end" now instead of implementing it in the global namespace?I was recently pointed at a part of the C++11 spec that says this is OK now, and making std::begin do the right thing seems better than relying on people remembering the "using" trick. Is this actually recommended nowadays?I also saw it mentioned that you can override std::begin on cppreference. But it also says that the standard library will use the using trick. So if you just call std::begin, and the. use some iteration defined in the library, you could have different things happen in each one. That left me thinking we should continue using that one weird trick. What do you think?
--BrettOn Sun, Nov 22, 2015 at 10:24 AM, 'Dana Jansens' via cxx <c...@chromium.org> wrote:This looks useful in cases like you linked to. Providing overloads will also allow iteration on things that dont expose a begin/end as member methods. Can you send a CL that updates the styleguide and makes use of begin/end so that we can see it pass the bots?Can you mention the "using std::begin; begin(a); idiom in the notes section for the styleguide?Thanks!
On Thursday, November 12, 2015, Ryan Sleevi <rsl...@chromium.org> wrote:--On Thu, Nov 12, 2015 at 8:41 AM, Ruud van Asseldonk <ru...@google.com> wrote:When you say "implemented it manually", are you talking about using something other than https://code.google.com/p/chromium/codesearch#chromium/src/base/macros.h&l=47 ?Yes. std::end returns a pointer past the end of an array, not the size of the array. See for example here.Right, I meant "implemented using means other than taking start + arraysize to compute end", but the example code answered that ;)
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACvaWvb_Oq6zDGBavmOep3pmyc8U3EUNynVHHo9Ge6_uCB8bvA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaS_5i0es1E9%2BOWiNLO71gX9JmoAA-BKqaETPSxmm2Yb7g%40mail.gmail.com.--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaQr%3D_2z%2BgPajR22cxh6GFQpcyj72cyf1k2Vmo45HvwYCg%40mail.gmail.com.
On Sun, Nov 22, 2015 at 11:42 AM 'Dana Jansens' via cxx <c...@chromium.org> wrote:On Sunday, November 22, 2015, Brett Wilson <bre...@chromium.org> wrote:Should we just be overriding "std::begin" and "std::end" now instead of implementing it in the global namespace?I was recently pointed at a part of the C++11 spec that says this is OK now, and making std::begin do the right thing seems better than relying on people remembering the "using" trick. Is this actually recommended nowadays?I also saw it mentioned that you can override std::begin on cppreference. But it also says that the standard library will use the using trick. So if you just call std::begin, and the. use some iteration defined in the library, you could have different things happen in each one. That left me thinking we should continue using that one weird trick. What do you think?On the flip side, you could argue that defining it in namespace std is more consistent with the behavior of std::default_delete and std::hash.
On Sunday, November 22, 2015, Daniel Cheng <dch...@chromium.org> wrote:On Sun, Nov 22, 2015 at 11:42 AM 'Dana Jansens' via cxx <c...@chromium.org> wrote:On Sunday, November 22, 2015, Brett Wilson <bre...@chromium.org> wrote:Should we just be overriding "std::begin" and "std::end" now instead of implementing it in the global namespace?I was recently pointed at a part of the C++11 spec that says this is OK now, and making std::begin do the right thing seems better than relying on people remembering the "using" trick. Is this actually recommended nowadays?I also saw it mentioned that you can override std::begin on cppreference. But it also says that the standard library will use the using trick. So if you just call std::begin, and the. use some iteration defined in the library, you could have different things happen in each one. That left me thinking we should continue using that one weird trick. What do you think?On the flip side, you could argue that defining it in namespace std is more consistent with the behavior of std::default_delete and std::hash.Ya absolutely. I was actually thinking of recommending that you define your own begin/end in std. But I was worried that it'd be hard to enforce, and so recommend the using trick as a general rule when calling begin/end.If we could be sure all non-standard begin/ends we use were actually in std:: that would make me feel better also.
By "override", do you mean "overload" or "specialize"? What part of the C++11 spec were you pointed at?
http://eel.is/c++draft/namespace.std says "The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited."
That bans overloads of std::begin() unless some other text explicitly allows it, and I'm not finding that text. I think http://en.cppreference.com/w/cpp/iterator/begin#User-defined_overloads is alluding to the fact that users can define begin() overloads in their own namespaces, which allows `using std::begin; begin(arg);` to find both.
Specializations are allowed, but because function templates can't be partially specialized, you can't specialize std::begin for a template type like a container. So you have to fall back to ADL overloads anyway in some cases, meaning you can't get away from the "using std::begin" in generic code, so you may as well use the simple same-namespace overload syntax in all cases.
Jeffrey
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CABiGVV_9hFoXqPQxcgTmiDcgKJ-C1Aky%2BpP6t8aJgvGONhSBCw%40mail.gmail.com.
By "override", do you mean "overload" or "specialize"? What part of the C++11 spec were you pointed at?
http://eel.is/c++draft/namespace.std says "The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited."
That bans overloads of std::begin() unless some other text explicitly allows it, and I'm not finding that text. I think http://en.cppreference.com/w/cpp/iterator/begin#User-defined_overloads is alluding to the fact that users can define begin() overloads in their own namespaces, which allows `using std::begin; begin(arg);` to find both.
Specializations are allowed, but because function templates can't be partially specialized, you can't specialize std::begin for a template type like a container. So you have to fall back to ADL overloads anyway in some cases, meaning you can't get away from the "using std::begin" in generic code, so you may as well use the simple same-namespace overload syntax in all cases.
Jeffrey
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CANh-dX%3Df-Obra3uBK_gcBT38GAttUmwo4yvnYRYKCnjhEk9mYg%40mail.gmail.com.