220 6096 <52245ABD.5000400@gmail.com> article Path: news.gmane.org!not-for-mail From: Artyom Lebedev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Templates usage with *this Date: Mon, 02 Sep 2013 12:30:37 +0300 Lines: 346 Approved: news@gmane.org Message-ID: <52245ABD.5000400@gmail.com> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060100070202020308070903" X-Trace: ger.gmane.org 1378114294 15049 80.91.229.3 (2 Sep 2013 09:31:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2013 09:31:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC4KXOVK3ENRB5VVSGIQKGQEDBKLNTY@isocpp.org Mon Sep 02 11:31:36 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ee0-f69.google.com ([74.125.83.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VGQTw-0007U2-9E for gclcip-std-proposals@m.gmane.org; Mon, 02 Sep 2013 11:31:36 +0200 Original-Received: by mail-ee0-f69.google.com with SMTP id c41sf4541002eek.4 for ; Mon, 02 Sep 2013 02:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=vp11aXWhOMAjGHA+OOxOEDxCaqTLjnuMrQBK4BEK3VA=; b=yp9TdUaWftVIsKJInU+cuTSKuS207ILIk9ysXuGDWhpFMKQOW8QDfcWFtb6N5ZH4Oa p6cRjbKbfp5GtpE19l7Rt6VJEC4uzG8i1OrbJ5OizJqbudx4XLiz7ZLujilVBKzaUxr2 chJ5Ixfq/RaT0vybHTh6BUY53QCg831K3gxU83ZYJlZ2/j/MsqwdR28AJi8GC2iJXpCv DtBHXe/ys/z4tTW2MYzBJpLOxmW2BU1gLe+AxRWERcxe8h4jU+lDnvf17h5SBJplDbiq kqObLE7gSKW18GvGpe7diO7pj/HaaTZ9WX59mpe9N+2mW6o5pKqxzy4D3a8T39b389dz raCQ== X-Received: by 10.112.169.101 with SMTP id ad5mr5574326lbc.1.1378114295357; Mon, 02 Sep 2013 02:31:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.116.65 with SMTP id ju1ls524499lab.67.gmail; Mon, 02 Sep 2013 02:31:33 -0700 (PDT) X-Received: by 10.152.8.51 with SMTP id o19mr633493laa.42.1378114293476; Mon, 02 Sep 2013 02:31:33 -0700 (PDT) Original-Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [2a00:1450:4010:c04::231]) by mx.google.com with ESMTPS id i10si5092182laf.89.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 02:31:33 -0700 (PDT) Received-SPF: pass (google.com: domain of artyom.lebedev@gmail.com designates 2a00:1450:4010:c04::231 as permitted sender) client-ip=2a00:1450:4010:c04::231; Original-Received: by mail-lb0-f177.google.com with SMTP id p5so3686089lbi.36 for ; Mon, 02 Sep 2013 02:31:33 -0700 (PDT) X-Received: by 10.152.36.98 with SMTP id p2mr20796464laj.14.1378114292908; Mon, 02 Sep 2013 02:31:32 -0700 (PDT) Original-Received: from [192.168.1.101] ([81.198.86.69]) by mx.google.com with ESMTPSA id b6sm5885970lae.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 02:31:31 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 In-Reply-To: X-Original-Sender: artyom.lebedev@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of artyom.lebedev@gmail.com designates 2a00:1450:4010:c04::231 as permitted sender) smtp.mail=artyom.lebedev@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) d=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:6096 Archived-At: This is a multi-part message in MIME format. --------------060100070202020308070903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed > If the friend function is an unpalatable interface, the member > overloads to call it will always be only one line each. Yes, I believe there are workarounds (you have demonstrated one). However, as every workaround (in contrast with native feature) they are usually not so nice, and may be cumbersome. What I want, is to introduce a feature which would make all the mentioned examples simple, short, nice and readable/understandable. In real world big projects, one of the most important requirement for the code is readability and therefore maintainability. Often this is the reason, why C++ is dropped away from the options of possible project implementation languages - not each and every average programmer will quickly understand what is done by dozen of nested type-manipulating templates in your example. And searching for a bug in such construction, especially if you do not know it is there, is a real pain (e.g. due to improper types manipulating, reference is passed and stored somewhere instead of a copy, leading to invalid memory access later, when the reference is not valid anymore). So I do not see any reason to discuss workarounds, unless one is really simple and does not introduce any trade-off between functionality and code simplicity/readability. This is your example. I modified it to return reference to stored value (for example if it was some [] operator which usually returns a reference) and as you recommended added member functions to hide friend function. Yes, they are one-liners and do not contain alghorithms but scale of the disaster is still visible: > struct S { > std::string x; > > //replace (decltype(std::declval().x) &) to some more advanced > //construction, so that lvalue and rvalue reference would properly > created. > //I do not even want to do it. > template > friend > typename std::enable_if std::decay::type>::value, > decltype(std::declval().x) &>::type > _get_x(Self &&self) > { return std::forward(self).x; } > > std::string & > Get_x() & > { > return _get_x(*this); > } > > const std::string & > Get_x() const & > { > return _get_x(*this); > } > > volatile std::string & > Get_x() const & > { > return _get_x(*this); > } > > const volatile std::string & > Get_x() const volatile & > { > return _get_x(*this); > } > > std::string && > Get_x() && > { > return _get_x(std::move(*this)); > } > > std::string const && > Get_x() const && > { > return _get_x(std::move(*this)); > } > > std::string volatile && > Get_x() volatile && > { > return _get_x(std::move(*this)); > } > > std::string const volatile && > Get_x() const volatile && > { > return _get_x(std::move(*this)); > } > }; And here is a replacement with the new feature: > struct S { > std::string x; > > template > auto > Get_x() && -> > decltype(std::forward().x)>(std::declval().x)) > { > return > std::forward().x)>(std::declval().x); > } > }; The templates there are still long enough, but the example is less real than I previously mentioned. I also repeat the other my thought - in general, the idea is that now we have full set of qualifiers for "*this", just like for any other argument, but lack possibility to make its type templatized, like any other argument. In my opinion, it would be very logically, and now it looks like unfinished solution. So this is ideological question. On 2013.09.02. 08:55, David Krauss wrote: > > > On Sunday, September 1, 2013 3:23:44 PM UTC+8, Artyom Lebedev wrote: > > Standard disclaimer: accessor functions are evil. C++ has a > perfectly good model for accessing members; do not roll your > own unless you legitimately have a custom object model. > > Probably you a bit misunderstood the idea. It by no means related > to accessor functions. > > > I don't object to accessors unless they're gratuitous. There are use > cases and hence this is the disclaimer is an afterthought. Maurice > mentions variant above. > > But do note that there is never an actual need to repeat the algorithm > in the various overloads, as my example demonstrates. If the friend > function is an unpalatable interface, the member overloads to call it > will always be only one line each. > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/xMlthAq8DWk/unsubscribe. > To unsubscribe from this group and all its topics, send an email 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-proposals/. -- --- 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 email 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-proposals/. --------------060100070202020308070903 Content-Type: text/html; charset=ISO-8859-1
If the friend function is an unpalatable interface, the member overloads to call it will always be only one line each.
Yes, I believe there are workarounds (you have demonstrated one). However, as every workaround (in contrast with native feature) they are usually not so nice, and may be cumbersome. What I want, is to introduce a feature which would make all the mentioned examples simple, short, nice and readable/understandable. In real world big projects, one of the most important requirement for the code is readability and therefore maintainability. Often this is the reason, why C++ is dropped away from the options of possible project implementation languages - not each and every average programmer will quickly understand what is done by dozen of nested type-manipulating templates in your example. And searching for a bug in such construction, especially if you do not know it is there, is a real pain (e.g. due to improper types manipulating, reference is passed and stored somewhere instead of a copy, leading to invalid memory access later, when the reference is not valid anymore). So I do not see any reason to discuss workarounds, unless one is really simple and does not introduce any trade-off between functionality and code simplicity/readability.

This is your example. I modified it to return reference to stored value (for example if it was some [] operator which usually returns a reference) and as you recommended added member functions to hide friend function. Yes, they are one-liners and do not contain alghorithms but scale of the disaster is still visible:

struct S {
    std::string x;

    //replace (decltype(std::declval<Self>().x) &) to some more advanced
    //construction, so that lvalue and rvalue reference would properly created.
    //I do not even want to do it.
    template<typename Self>
    friend
    typename std::enable_if<std::is_base_of<S, typename std::decay<Self>::type>::value,
                            decltype(std::declval<Self>().x) &>::type
    _get_x(Self &&self)
    { return std::forward<Self>(self).x; }

    std::string &
    Get_x() &
    {
        return _get_x(*this);
    }

    const std::string &
    Get_x() const &
    {
        return _get_x(*this);
    }

    volatile std::string &
    Get_x() const &
    {
        return _get_x(*this);
    }

    const volatile std::string &
    Get_x() const volatile &
    {
        return _get_x(*this);
    }

    std::string &&
    Get_x() &&
    {
        return _get_x(std::move(*this));
    }

    std::string const &&
    Get_x() const &&
    {
        return _get_x(std::move(*this));
    }

    std::string volatile &&
    Get_x() volatile &&
    {
        return _get_x(std::move(*this));
    }

    std::string const volatile &&
    Get_x() const volatile &&
    {
        return _get_x(std::move(*this));
    }
};
And here is a replacement with the new feature:
struct S {
    std::string x;

    template <this Self>
    auto
    Get_x() && -> decltype(std::forward<decltype(std::declval<Self>().x)>(std::declval<Self>().x))
    {
        return std::forward<decltype(std::declval<Self>().x)>(std::declval<Self>().x);
    }
};
The templates there are still long enough, but the example is less real than I previously mentioned. I also repeat the other my thought - in general, the idea is that now we have full set of qualifiers for "*this", just like for any other argument, but lack possibility to make its type templatized, like any other argument. In my opinion, it would be very logically, and now it looks like unfinished solution. So this is ideological question.
 
On 2013.09.02. 08:55, David Krauss wrote:


On Sunday, September 1, 2013 3:23:44 PM UTC+8, Artyom Lebedev wrote:
Standard disclaimer: accessor functions are evil. C++ has a perfectly good model for accessing members; do not roll your own unless you legitimately have a custom object model.
Probably you a bit misunderstood the idea. It by no means related to accessor functions.

I don't object to accessors unless they're gratuitous. There are use cases and hence this is the disclaimer is an afterthought. Maurice mentions variant above.

But do note that there is never an actual need to repeat the algorithm in the various overloads, as my example demonstrates. If the friend function is an unpalatable interface, the member overloads to call it will always be only one line each.
--
 
---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/xMlthAq8DWk/unsubscribe.
To unsubscribe from this group and all its topics, send an email 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-proposals/.

--
 
---
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 email 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-proposals/.
--------------060100070202020308070903-- .