StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17564445
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
30
CommunityOwnedDate
2013-07-10T19:30:24.963
CreationDate
2013-07-10T07:09:14.280
FavoriteCount
0
LastActivityDate
2013-07-11T07:57:24.807
LastEditDate
2013-07-11T07:57:24.807
LastEditorUserId
819272
OwnerUserId
819272
ParentId
17562943
PostTypeId
2
Score
34
ViewCount
0
LastEditorDisplayName
text
Body
There are several approaches, each with their own pros and cons. Below three approaches with a cost-benefit analysis. <h2>ADL through custom non-member <code>begin()</code> / <code>end()</code></h2> The first alternative provides non-member <code>begin()</code> and <code>end()</code> function templates inside a <code>legacy</code> namespace to retrofit the required functionality onto any class or class template that can provide it, but has e.g. the wrong naming conventions. Calling code can then rely on ADL to find these new functions. Example code (based on comments by @Xeo): <pre><code>// LegacyContainerBeginEnd.h namespace legacy { // retro-fitting begin() / end() interface on legacy // Container class template with incompatible names template<class C> auto begin(Container& c) -> decltype(c.legacy_begin()) { return c.legacy_begin(); } // similarly for begin() taking const&, cbegin(), end(), cend(), etc. } // namespace legacy // print.h template<class C> void print(C const& c) { // bring into scope to fall back on for types without their own namespace non-member begin()/end() using std::begin; using std::end; // works for Standard Containers, C-style arrays and legacy Containers std::copy(begin(c), end(c), std::ostream_iterator<decltype(*begin(c))>(std::cout, " ")); std::cout << "\n"; // alternative: also works for Standard Containers, C-style arrays and legacy Containers for (auto elem: c) std::cout << elem << " "; std::cout << "\n"; } </code></pre> Pros: consistent and terse calling convention that works completely generically <ul> <li>works for any Standard Container and user-types that define member <code>.begin()</code> and <code>.end()</code></li> <li>works for C-style arrays</li> <li>can be retrofitted to work (also for range-for loops!) for any class template <code>legacy::Container<T></code> that does not have member <code>.begin()</code> and <code>end()</code> without requiring source code modifications</li> </ul> Cons: requires using-declarations in many places <ul> <li><code>std::begin</code> and <code>std::end</code> are required to have been brought into every explicit calling scope as fall back options for C-style arrays (potential pitfall for template headers and general nuisance)</li> </ul> <h2>ADL through custom non-member <code>adl_begin()</code> and <code>adl_end()</code></h2> A second alternative is to encapsulate the using-declarations of the previous solution into a separate <code>adl</code> namespace by providing non-member function templates <code>adl_begin()</code> and <code>adl_end()</code>, which can then also be found through ADL. Example code (based on comments by @Yakk): <pre><code>// LegacyContainerBeginEnd.h // as before... // ADLBeginEnd.h namespace adl { using std::begin; // <-- here, because otherwise decltype() will not find it template<class C> auto adl_begin(C && c) -> decltype(begin(std::forward<C>(c))) { // using std::begin; // in C++14 this might work because decltype() is no longer needed return begin(std::forward<C>(c)); // try to find non-member, fall back on std:: } // similary for cbegin(), end(), cend(), etc. } // namespace adl using adl::adl_begin; // will be visible in any compilation unit that includes this header // print.h # include "ADLBeginEnd.h" // brings adl_begin() and adl_end() into scope template<class C> void print(C const& c) { // works for Standard Containers, C-style arrays and legacy Containers std::copy(adl_begin(c), adl_end(c), std::ostream_iterator<decltype(*adl_begin(c))>(std::cout, " ")); std::cout << "\n"; // alternative: also works for Standard Containers, C-style arrays and legacy Containers // does not need adl_begin() / adl_end(), but continues to work for (auto elem: c) std::cout << elem << " "; std::cout << "\n"; } </code></pre> Pros: consistent calling convention that works completely generically <ul> <li>the same pros as for @Xeo's suggestion +</li> <li>the repeated using-declarations have been encapsulated (DRY)</li> </ul> Cons: a little verbose <ul> <li><code>adl_begin()</code> / <code>adl_end()</code> is not as terse as <code>begin()</code> / <code>end()</code></li> <li>it is perhaps also not as idiomatic (although it is explicit)</li> <li>pending C++14 return type deduction, will also pollute namespace with <code>std::begin</code> / <code>std::end</code></li> </ul> NOTE: Not sure if this really improves upon the previous approach. <h2>Explicitly qualifying <code>std::begin()</code> or <code>std::end()</code> everywhere</h2> Once the verbosity of <code>begin()</code> / <code>end()</code> has been given up anyway, why not go back to the qualified calls of <code>std::begin()</code> / <code>std::end()</code>? Example code: <pre><code>// LegacyIntContainerBeginEnd.h namespace std { // retro-fitting begin() / end() interface on legacy IntContainer class // with incompatible names template<> auto begin(legacy::IntContainer& c) -> decltype(c.legacy_begin()) { return c.legacy_begin(); } // similary for begin() taking const&, cbegin(), end(), cend(), etc. } // namespace std // LegacyContainer.h namespace legacy { template<class T> class Container { public: // YES, DOCUMENT REALLY WELL THAT THE EXISTING CODE IS BEING MODIFIED auto begin() -> decltype(legacy_begin()) { return legacy_begin(); } auto end() -> decltype(legacy_end()) { return legacy_end(); } // rest of existing interface }; } // namespace legacy // print.h template<class C> void print(C const& c) { // works for Standard Containers, C-style arrays as well as // legacy::IntContainer and legacy::Container<T> std::copy(std::begin(c), std::end(c), std::ostream_iterator<decltype(*std::begin(c))>(std::cout, " ")); std::cout << "\n"; // alternative: also works for Standard Containers, C-style arrays and // legacy::IntContainer and legacy::Container<T> for (auto elem: c) std::cout << elem << " "; std::cout << "\n"; } </code></pre> Pros: consistent calling convention that works almost generically <ul> <li>works for any Standard Container and user-types that define member <code>.begin()</code> and <code>.end()</code></li> <li>works for C-style arrays</li> </ul> Cons: a little verbose and retrofitting is not generic and a maintainence problem <ul> <li><code>std::begin()</code> / <code>std::end()</code> is a little more verbose than <code>begin()</code> / <code>end()</code></li> <li>can only be retrofitted to work (also for range-for loops!) for any class <code>LegacyContainer</code> that does not have member <code>.begin()</code> and <code>end()</code> (and for which there is no source code!) by providing explicit specializations of the non-member function templates <code>begin()</code> and <code>end()</code> in <code>namespace std</code></li> <li>can only be retrofitted onto class templates <code>LegacyContainer<T></code> by directly adding member functions <code>begin()</code> / <code>end()</code> inside the source code of <code>LegacyContainer<T></code> (which for templates is available). The <code>namespace std</code> trick does not work here because function templates cannot be partially specialized. </li> </ul> <h2>What to use?</h2> The ADL approach through non-member <code>begin()</code> / <code>end()</code> in a a container's own namespace is the idiomatic C++11 approach, especially for generic functions that require retrofitting on legacy classes and class templates. It is the same idiom as for user-providing non-member <code>swap()</code> functions. For code that only uses Standard Containers or C-style arrays, <code>std::begin()</code> and <code>std::end()</code> could be called everywhere without introducing using-declarations, at the expense of more verbose calls. This approach can even be retrofitted but it requires fiddling with <code>namespace std</code> (for class types) or in-place source modifcations (for class templates). It can be done, but is not worth the maintainence trouble. In non-generic code, where the container in question is known at coding-time, one could even rely on ADL for Standard Containers only, and explicitly qualify <code>std::begin</code> / <code>std::end</code> for C-style arrays. It loses some calling consistency but saves on using-declarations.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POShould custom containers have free begin/end functions?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USTemplateRex
UserOwnerUserId
1. USTemplateRex
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POShould custom containers have free begin/end functions?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.