From 5888869240659918824
X-Google-Thread: 7894ca11fe,b8f03ff37c64f88c
X-Google-Attributes: gid7894ca11fe,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 21 Sep 2009 13:30:05 -0500
Return-Path: <cppmods@ruralroute.cs.rpi.edu>
To: (Usenet)
From: Tony <gottlobfrege@gmail.com>
Newsgroups: comp.std.c++
Subject: Re: No cbegin/cend for std::initializer_list?
Organization: A noiseless patient Spider
Sender: cppmods@cs.rpi.edu
Approved: stephen.clamage@sun.com
Message-ID: <h98cb4$lob$1@news.eternal-september.org>
References: <7.0.0.16.2.20090901101108.063e9c28@aristeia.com>
	<1b8b2c5d-7f06-46c5-b403-50aad13632cf@o36g2000vbl.googlegroups.com>
	<0081c572-9bbe-457e-9f54-b97da4ebfae0@v36g2000yqv.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Original-Date: Mon, 21 Sep 2009 13:15:14 -0400
X-Submission-Address: std-c++@netlab.cs.rpi.edu
Date: Mon, 21 Sep 2009 13:21:42 CST
Lines: 55
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-eBpDXNGHkZp/NvzFLUvCSfat38V16j5oQ7y3WR8n/GegOQd2ubWynT/dUTCg6+FhvIvTTHlQ0UNynXi!YIqTnPdfQ1t10YOi+wFRqnY55yUMrNnz+/wAIr/huXQlBU8Vd1GIkS/bIf71V00rCqVf
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Xref: g2news2.google.com comp.std.c++:1381

Philipp M. wrote:
> On Sep 2, 7:14 am, Nikolay Ivchenkov <ts...@mail.ru> wrote:
>> IMHO, direct use of container's member "cbegin" in generic
>> code is bad idea.
> 
> Could you outline a few situations were usage of the members might
> lead to unexpected problems afterwards?
> I'm curious because I can't see such a situation (as I'm rather
> inexperienced).
> 
> Philipp
> 

I think the reasoning is just that in _general_, free functions are more
_generic_ than member functions, making your generic code, more, well,
_generic_. :-)

ie if you run into a case where you want to run your generic code on
types that do not have the required member functions, you might still be
able to run your code using free functions.

Concrete example:  Windows HWND do not have 'next()' functions, you need
to use GetNextWindow().  So my code that iterates over
	"things that have next() member functions"
can't iterate over HWNDs, but my code that iterates over
	"things that work with free function: next(thing)"
can, if I just write
HWND next(HWND hwnd)
{
    return GetNextWindow(hwnd);
}

So
	"things that work with free function: next(thing)"
is more generic than
	"things that have next() member functions"

Particularly considering:

template <typename T>
T next(T t)
{
    return t.next();
}

can be written to cover all the already-have-a-member-function cases.

Tony

-- 
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]