220 15397 <2966691.aBn0dNKpSk@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: get count of std::weak_ptr objects tracking a shared resource Date: Tue, 30 Dec 2014 16:15:13 -0200 Lines: 69 Approved: news@gmane.org Message-ID: <2966691.aBn0dNKpSk@tjmaciei-mobl4> References: <38379535.fdbaY7af1L@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1419963553 14272 80.91.229.3 (30 Dec 2014 18:19:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 18:19:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBGGZROSQKGQEOEUUTJA@isocpp.org Tue Dec 30 19:19:09 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f71.google.com ([74.125.82.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y61Np-0001vN-Lu for gclcip-std-proposals@m.gmane.org; Tue, 30 Dec 2014 19:19:05 +0100 Original-Received: by mail-wg0-f71.google.com with SMTP id k14sf1531768wgh.6 for ; Tue, 30 Dec 2014 10:19:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=qLLITipFoRVAOEcSpsqQbT/pqctScFF2/kNeFmpQF3o=; b=bG8DIRgB5mcRvGKiEKwFy0japqHRTP/0ECXuOg2S/Tkn/BHsG6Qa5aate03AlxU0KP Ih9BOMwMPutJIzZ5VpewMBgt+t9+dMrfBQtzT7u4d0ktnjK/0/UJBKxHLVdwsx8gaW0O xRzyWec6s8mB5ORLg0DYsQkdbFSag59xVngd2rbB9oRALgvAYYiUm/GkEJautqNmHwyP SxGw5myLyG75bRauaQx+lxgmXxYa02rfVyJUSodD4X2hWPCwxEwCwPlM62Tjhwxpctk/ wyllvRG06KdTorp3X0UumID9ZZtmgfE8Ju154xSNWHS6TcYU+MP4I7oj7UuqbXpbIUAV gMMw== X-Gm-Message-State: ALoCoQllKULinN1oyZEc2QsiHqGI8k8eYpK6aN62aeDUns6xdBTyO2Zgy/QHv45Cffscd4+3o0Iw X-Received: by 10.152.2.40 with SMTP id 8mr344201lar.7.1419963544808; Tue, 30 Dec 2014 10:19:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.107.135 with SMTP id hc7ls1824566wib.27.canary; Tue, 30 Dec 2014 10:19:03 -0800 (PST) X-Received: by 10.194.78.229 with SMTP id e5mr76709464wjx.11.1419963543669; Tue, 30 Dec 2014 10:19:03 -0800 (PST) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [2a01:4f8:d13:f81:21c:14ff:fe01:12a3]) by mx.google.com with ESMTP id n2si66190901wic.45.2014.12.30.10.19.03 for ; Tue, 30 Dec 2014 10:19:03 -0800 (PST) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 2a01:4f8:d13:f81:21c:14ff:fe01:12a3 as permitted sender) client-ip=2a01:4f8:d13:f81:21c:14ff:fe01:12a3; Original-Received: from tjmaciei-mobl4.localnet (unknown [189.0.120.56]) by gondolin.macieira.info (Postfix) with ESMTPSA id A5E7711BB9F for ; Tue, 30 Dec 2014 10:19:02 -0800 (PST) User-Agent: KMail/4.14.3 (Linux/3.11.10-21-desktop; KDE/4.14.3; x86_64; ; ) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 2a01:4f8:d13:f81:21c:14ff:fe01:12a3 as permitted sender) smtp.mail=thiago@macieira.org 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:15397 Archived-At: On Tuesday 30 December 2014 19:19:10 Ville Voutilainen wrote: > > In this case, just think of the following scenario: > > - library A is built now and uses method 1 of reference-counting > > - library B is built tomorrow and uses method 2 of reference-counting > > - library A passes a shared_ptr object to library B, which holds a copy > > - library B passes its own shared_ptr object to library A, which holds a > > copy How will that work? How will library B know that it should use > > method 2 because the pointer came from library A? And moreover, how will > > library A, which has no clue that method 2 even exists, use that method? > > Library B knows which 'method' to use because the shared_ptr types are > not the same. The types being different is a binary-incompatibility change of itself. Moreover, keeping the name the same by way of an inline namespace introduces linker or runtime errors instead of a source-incompatible error. > Library A cannot use the shared_ptr in Library B nor its 'method' because > it's not magically forward-compatible with future changes. Exactly. So imagine: $ cat libA.h #include void method_in_lib_A(const std::shared_ptr &); Now imagine that lib B calls that method. Previously, it really was "std::shared_ptr". Now, after the standard-required changes, the Standard Library implementation decides to use an inline namespace, so the type becomes "std::__cxx17::shared_ptr". Since the header didn't specify (and can't specify!) the base version, this implies that the new build sees as the new type. As libA wasn't recompiled, this can result in a linker error (unresolved symbol: method_in_lib_A(const std::shared_ptr &)). Or, worse, a runtime error, since we're talking about building another library and the default ELF behaviour is to not resolve at link-time. If we're talking about system libraries, libB getting updated implies updating libA too, which implies updating everything that uses libA. As a cascade effect, since now everything uses the new std::shared_ptr, now everything has to be updated too. > > No, short of breaking the ABI and forcing the *whole* *world* to > > recompile, > > this can't be done. > > I doubt the correctness of that claim. There is practical evidence to > the contrary. See above. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -- --- 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/. .