------=_Part_458_12832560.1391376855539
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 29, 2014 12:23:52 AM UTC+4, Evgeny Panasyuk wrote:
>
> 28 January 2014 =D0=B3., 3:18:25 UTC+4 matve...@gmail.com:
>>
>>
>>> > You can always write your own function that has the semantics you=20
>>> want;=20
>>> > e.g. value_or_default(Container, Index).=20
>>>
>>> I could write my own implementation of (almost?) anything in STL... tha=
t=20
>>> doesn't mean STL shouldn't include things that are widely useful. IMHO=
=20
>>> this qualifies; I've also wished for such a method.=20
>>>
>>
>> Exactly. In my view the code looks better when such basic functions are=
=20
>> implemented as class members. For comparison: was there any reason why t=
he=20
>> =E2=80=9Cat=E2=80=9D function added in C++11 can not be implemented exte=
rnally? I don't=20
>> think =E2=80=9Cat=E2=80=9D is really much more useful.
>>
>
> Non-member functions are more preferable than methods when possible.
> For example, Alexander Stepanov, author of STL, at his Notes on=20
> Programming says ( http://www.stepanovpapers.com/notes.pdf ):
> "While we could make a member function to return length, it is better to=
=20
> make it a global friend function. If we do that, we will be able eventual=
ly=20
> to define the same function to work on built-in arrays and achieve greate=
r=20
> uniformity of design. I made size into a member function in STL in an=20
> attempt to please the standard committee. I knew that begin, end and size=
=20
> should be global functions but was not willing to risk another fight with=
=20
> the committee. In general, there were many compromises of which I am=20
> ashamed. It would have been harder to succeed without making them, but I=
=20
> still get a metallic taste in my mouth when I encounter all the things th=
at=20
> I did wrong while knowing full how to do them right. Success, after all, =
is=20
> much overrated. I will be pointing to the incorrect designs in STL here a=
nd=20
> there: some were done because of political considerations, but many were=
=20
> mistakes caused by my inability to discern general principles.)"
>
> Also refer SO:=20
> http://stackoverflow.com/questions/1638394/when-should-functions-be-membe=
r-functions
>
=20
So many people so many views on which way is more preferable. I want to=20
apologies that I'm not ready to support =E2=80=9Cmember vs non-member=E2=80=
=9D dispute with=20
steadfast arguments about real (non-visual) benefits of member-function.=20
May be, there aren't any. But I want to point out is that the committee=20
insisted on member functions in the very beginning and continues to add=20
member functions now (e.g. the above-mentioned std::map::at), so there must=
=20
be some reason.

Besides it is always possible to have 2 versions: both member and=20
non-member, as with =E2=80=9Cbegin=E2=80=9D and =E2=80=9Cend=E2=80=9D.

And even if we come to a conclusion that a non-member function is the best=
=20
solution, I still want to see it in the standard library. It is handy,=20
widespread and not completely trivial: at least 2 versions are required:
* based on =E2=80=9Cfind=E2=80=9D for std::map and
* based on checking range by hand for std::vector.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_458_12832560.1391376855539
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 29, 2014 12:23:52 AM UTC+4, Evgeny P=
anasyuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>28 January 2014&nbsp;=D0=B3., 3:18:25 UTC+4 <a>matve...@gmail.com</a>:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<br>&gt; You can always write your own function that has the semantics you =
want;
<br>&gt; e.g. value_or_default(Container, Index).
<br>
<br>I could write my own implementation of (almost?) anything in STL... tha=
t=20
<br>doesn't mean STL shouldn't include things that are widely useful. IMHO=
=20
<br>this qualifies; I've also wished for such a method.
<br></blockquote><div><br>Exactly. In my view the code looks better when su=
ch basic functions are implemented as class members. For comparison: was th=
ere any reason why the =E2=80=9Cat=E2=80=9D function added in C++11 can not=
 be implemented externally? I don't think =E2=80=9Cat=E2=80=9D is really mu=
ch more useful.</div></div></blockquote><div><br>Non-member functions are m=
ore preferable than methods when possible.<br>For example, Alexander Stepan=
ov, author of STL, at his Notes on Programming says  ( <a href=3D"http://ww=
w.stepanovpapers.com/notes.pdf" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stepanovpapers.com%2Fnot=
es.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNE787les7WbKSrVXpVHeexxAr7J0Q';ret=
urn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.stepanovpapers.com%2Fnotes.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNE7=
87les7WbKSrVXpVHeexxAr7J0Q';return true;">http://www.stepanovpapers.com/<wb=
r>notes.pdf</a> ):<br>"While we could make a member function to return leng=
th, it is better to make it a global friend function. If we do that, we wil=
l be able eventually to define the same function to work on built-in arrays=
 and achieve greater uniformity of design. I made size into a member functi=
on in STL in an attempt to please the standard committee. I knew that begin=
, end and size should be global functions but was not willing to risk anoth=
er fight with the committee. In general, there were many compromises of whi=
ch I am ashamed. It would have been harder to succeed without making them, =
but I still get a metallic taste in my mouth when I encounter all the thing=
s that I did wrong while knowing full how to do them right. Success, after =
all, is much overrated. I will be pointing to the incorrect designs in STL =
here and there: some were done because of political considerations, but man=
y were mistakes caused by my inability to discern general principles.)"<br>=
<br>Also refer SO: <a href=3D"http://stackoverflow.com/questions/1638394/wh=
en-should-functions-be-member-functions" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2F=
questions%2F1638394%2Fwhen-should-functions-be-member-functions\46sa\75D\46=
sntz\0751\46usg\75AFQjCNFiTBbgqSHw7iPUOMnfQEuWd4wV_g';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.c=
om%2Fquestions%2F1638394%2Fwhen-should-functions-be-member-functions\46sa\7=
5D\46sntz\0751\46usg\75AFQjCNFiTBbgqSHw7iPUOMnfQEuWd4wV_g';return true;">ht=
tp://stackoverflow.com/<wbr>questions/1638394/when-should-<wbr>functions-be=
-member-functions</a><br></div></div></blockquote><div>&nbsp;<br>So many pe=
ople so many views on which way is more preferable. I want to apologies tha=
t I'm not ready to support =E2=80=9Cmember vs non-member=E2=80=9D dispute w=
ith steadfast arguments about real (non-visual) benefits of member-function=
.. May be, there aren't any. But I want to point out is that the committee i=
nsisted on member functions in the very beginning and continues to add memb=
er functions now (e.g. the above-mentioned std::map::at), so there must be =
some reason.<br><br>Besides it is always possible to have 2 versions: both =
member and non-member, as with =E2=80=9Cbegin=E2=80=9D and =E2=80=9Cend=E2=
=80=9D.<br><br>And even if we come to a conclusion that a non-member functi=
on is the best solution, I still want to see it in the standard library. It=
 is handy, widespread and not completely trivial: at least 2 versions are r=
equired:<br>* based on =E2=80=9Cfind=E2=80=9D for std::map and<br>* based o=
n checking range by hand for std::vector.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_458_12832560.1391376855539--

.