220 29613 <63b9777b-4657-4047-ba0b-b9815c614bf9@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Jakob Riedle Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Extending the use of shared_from_this() to Constructors (- and to destructors?) Date: Fri, 2 Dec 2016 07:01:13 -0800 (PST) Lines: 144 Approved: news@gmane.org Message-ID: <63b9777b-4657-4047-ba0b-b9815c614bf9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_790_2054613840.1480690873104" X-Trace: blaine.gmane.org 1480690883 15646 195.159.176.226 (2 Dec 2016 15:01:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 15:01:23 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCX2XNFO6MPRBOMZQ3BAKGQE7HZDYYY@isocpp.org Fri Dec 02 16:01:12 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCpKo-0002QC-I9 for gclcip-std-proposals@m.gmane.org; Fri, 02 Dec 2016 16:01:10 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id l192sf418757779oih.2 for ; Fri, 02 Dec 2016 07:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=aHT9k4NopMDn3J7Cdpz+LVv2JWMDS1p/jjz1szlDXv4=; b=wKVI8EJ3kzd881mh2W/BL73DzMGEgtm5YD70+Py1nnScd95VyQpQW21BRT8abIbx4d +Derii/UM10eGk1DnVxm7I/3YMczCBg8paqb9aITRKvw5jQcrhM65/7d9vGLADi9y2ws UQD+EBSGLr401EQ4AlN8vBgC+79YxiTnbXdpYgisPfH0HD6RJ5XzR4dwtSXfCX5MPlI+ +Q0Tf9wBmrir9Dgyng6uEt/Y7YKI4wp5nir/yp6FL+Z6Je5uZIiFGQ+4Dooy9RIN9QMi /b+A903pWxbLYr+fcdoHuDAfIXVuA+UmTNAZtIvb+3nYO6XF4N9a6DRR0zMEL8uOnSN4 SlXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=aHT9k4NopMDn3J7Cdpz+LVv2JWMDS1p/jjz1szlDXv4=; b=zvaBO+Izl+6ifgnxbVbs5qFJv/BuZnTHSsmkuL6uopw6Gas/sa36Xor4dQr9kCkY+K iLeVPSi+5pfIhNQ8/qNry1w8IvjBKWJZlWZTRy0PG14JrmEBIEI9J6qaNyYCsbONU5n+ uA09iM7rUg5qx5ytFxP9L3CzU9TI8xj+IlNRy2rGcR3+kVfj3PNL9GNAGH3rxEuNZvZu 1BeE3inKHSsynr52rjbavHwD60NuHCZ2MqXkPwq9SD9KhEAaToj1fGpnH4HQStbyJTl1 nJibEt6fj2LVd6OJbC6jbLqIwag6T0yY24zo1ZF/wXbv6mcRupZqV+PsQ32Rh1ID1rnl N7ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=aHT9k4NopMDn3J7Cdpz+LVv2JWMDS1p/jjz1szlDXv4=; b=NFcr/f7RcS44BwZp5U6us7ombvDEas6VF3ToYK8kToJQQ2CYwf5TI8uDlonH+iALws cw7d7YpgLmFE2V7c1Y2ZUDIt8DK2FzazmFKrnik/uz51EdT5QITWeI12PJM3FnE5r5Y6 hmlTXDMn5X87EZpSUQ612BJd80UPIXey1ESYkxluwaw3bpI048kdnDvjXpuQWG6sHV1V TyX0EqStp8C3BkWgjEA3V7OWsewR/vJE5AAkLe0BOxmQpFnOU7HFVzSn84lnSmfrZn3T Vxrcko3RlfqHh+A6tJWerj0wbwq/hDSozHXqWFIKlQhoTTNDxDTsl+YLyGTIZ3UWfQ0H 68Tg== X-Gm-Message-State: AKaTC02K2iaWSpMyxzzOg0YxmCFDUrLCs1DZIFtujvY3loaGV4x2C7jt29/cVMHfcU07Rw== X-Received: by 10.157.21.39 with SMTP id u36mr10949613otf.32.1480690874329; Fri, 02 Dec 2016 07:01:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.13.228 with SMTP id 91ls21891762ots.42.gmail; Fri, 02 Dec 2016 07:01:13 -0800 (PST) X-Received: by 10.157.11.248 with SMTP id 111mr2994718oth.4.1480690873658; Fri, 02 Dec 2016 07:01:13 -0800 (PST) X-Original-Sender: jakob.riedle@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:29613 Archived-At: ------=_Part_790_2054613840.1480690873104 Content-Type: multipart/alternative; boundary="----=_Part_791_575760040.1480690873104" ------=_Part_791_575760040.1480690873104 Content-Type: text/plain; charset=UTF-8 Hello Folks, at work it happened to me the second time, that I needed to construct a shared_ptr/weak_ptr to 'this' within the constructor. This stackoverflow question made think about the situation from the viewpoint of realizability. I thus went and implemented my own drop-in replacement for *shared_ptr, weak_ptr *and *enable_shared_from_this.* It is linked here: *Sourceforge: shared_from_this_ctor * *Outcome:* Obviously, *enable_shared_from_this **can *allow the user to construct a shared_ptr while still in its ctor and simply pass it the *reference_count* object that enable_shared_from_this holds to the shared_ptr that the constructed object will be passed to (after construction). (What a sentence...) I have tested my apporach and it just works as expected. This was as far as I'm concerned even acomplished with *no speed or size overhead*. *My questions now are:* - Has this topic been already discussed somewhere else? What outcome? - What do you think? Is such usage still dangerous given a very robust implementation with no overhead? - Is there any use case for it? At least I had it twice now and it looks like, that other people have it as well. ( I know that one could create something using weak_from_raw, but I have not really dug into it yet. ) *Beyond: Extending the approach to destructors:* One could argue: "Why not extend it to dtors as well?" The question is: *Is there any use case for this situation?* Because the functionality is *perfectly demonstrated in my Library as well*. It works, as long as all shared_/weak_ptrs that get constructed during the dtor get destroyed before dtor is over. *No duplicate deletion whatsoever - all clean -> it works! (Sadly, allowing this introduces a little bit of overhead :-) )* I'd love to hear your thoughts! Greetings from Munich, Jakob -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/63b9777b-4657-4047-ba0b-b9815c614bf9%40isocpp.org. ------=_Part_791_575760040.1480690873104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Folks,

at work it happened to me = the second time,
that I needed to construct a shared_ptr/weak_ptr= to 'this'=C2=A0within the constructor.

This sta= ckoverflow question made think about the situation from the viewpoint of re= alizability.

I thus went and implemented my own dr= op-in replacement for shared_ptr, weak_ptr=C2=A0and enable_shared= _from_this.
It is linked here:

Sourceforge:=C2=A0shared_from_this_ctor

Outcome:
Obviously,=C2=A0enable_shared_from_thi= s=C2=A0can=C2=A0allow the user to construct a shared_ptr
while still in its ctor and simply pass it the=C2=A0reference_count=C2=A0object that enable_shared_from_this holds to
the shared_p= tr that the constructed object will be passed to (after construction). (What a sentence...)

I have te= sted my apporach and it just works as expected.
This was as far a= s I'm concerned even acomplished with no speed or size overhead.=

My questions now are:
  • Has this topic been already discus= sed somewhere else? What outcome?
  • What do you think? Is such usage still dange= rous given a very robust implementation with no overhead?
  • Is there any use case for it? At least I had it twice now and it looks like, that other people have it= as well.
( I know that one could create something usin= g weak_from_raw, but I have not really dug into it yet. )

Beyond: Extending the approach to destructors= :
One could argue: "Why not extend it to dtors as well?&= quot;

The question is: Is there any use case fo= r this situation?
Because the functionality is perfectly d= emonstrated in my Library as well.

It works, a= s long as all shared_/weak_ptrs that get constructed during the dtor
<= div>get destroyed before dtor is over.
No duplicate deletion w= hatsoever - all clean -> it works! (Sadly, allowing this introduces a li= ttle bit of overhead :-) )


<= /div>

I'd love to hear your thoughts!

=

Greetings from Munich,
Jakob
=

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/63b9777b-4657-4047-ba0b-b9815c614bf9= %40isocpp.org.
------=_Part_791_575760040.1480690873104-- ------=_Part_790_2054613840.1480690873104-- .