220 15409 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: get count of std::weak_ptr objects tracking a shared resource Date: Wed, 31 Dec 2014 02:36:00 +0200 Lines: 121 Approved: news@gmane.org Message-ID: References: <2966691.aBn0dNKpSk@tjmaciei-mobl4> <2825290.jdXfhZFeBX@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 1419986172 21769 80.91.229.3 (31 Dec 2014 00:36:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 31 Dec 2014 00:36:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRB4MJRWSQKGQEWQGJZUA@isocpp.org Wed Dec 31 01:36:06 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y67Gd-0007ZB-2k for gclcip-std-proposals@m.gmane.org; Wed, 31 Dec 2014 01:36:03 +0100 Original-Received: by mail-pa0-f72.google.com with SMTP id kq14sf125466081pab.11 for ; Tue, 30 Dec 2014 16:36:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to: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=GEMuFCyl8MGM8tGF+kOkGKMX1+ziqIH8Dc2Ciz1hd5c=; b=f0j+OYFO3tyNE/fCKiEAtAvuckfFwU/d5M27wSRvDoABxxviugA6EwVMMhEYAHXSYI N9aJZ6XJgvfojhUN3MKPF3ylP0XnOKGjpXZQpB1JyzqffCo9tkQZAN/ca6bGDcv5HI6g 5kpmbGCOc8v0zgl88jtFqkxAY6raSmSdQyGV4wFZVQwGVBLbPqko6WwHltu683vj0U78 lnuPEE4aliABzPaEGOW2qSLMXDOTfdy+wcaIkioI5LyWXj9uXiejTK9Vv5hPnxSN+ojb NvqqOJHFqdffVDk+rcDLtXpz4BdXYKfb58+zMyaoNGM83JiI4a6bmB23zxLR7v47BSit MrzQ== X-Gm-Message-State: ALoCoQlDGfAZQ+2dNso5TI7UPSTfFCDtSqOwCBi+/sjeNpDrHMX2byrHF57tLftq5KfmorqHpb7W X-Received: by 10.70.13.161 with SMTP id i1mr39442361pdc.3.1419986162082; Tue, 30 Dec 2014 16:36:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.243.234 with SMTP id xb10ls434617obc.19.gmail; Tue, 30 Dec 2014 16:36:01 -0800 (PST) X-Received: by 10.182.29.68 with SMTP id i4mr1386338obh.30.1419986161128; Tue, 30 Dec 2014 16:36:01 -0800 (PST) Original-Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com. [2607:f8b0:4003:c06::236]) by mx.google.com with ESMTPS id 79si15529682oim.124.2014.12.30.16.36.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Dec 2014 16:36:01 -0800 (PST) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4003:c06::236 as permitted sender) client-ip=2607:f8b0:4003:c06::236; Original-Received: by mail-oi0-f54.google.com with SMTP id u20so34145930oif.13 for ; Tue, 30 Dec 2014 16:36:01 -0800 (PST) X-Received: by 10.202.202.206 with SMTP id a197mr31662705oig.5.1419986160863; Tue, 30 Dec 2014 16:36:00 -0800 (PST) Original-Received: by 10.76.154.2 with HTTP; Tue, 30 Dec 2014 16:36:00 -0800 (PST) In-Reply-To: <2825290.jdXfhZFeBX@tjmaciei-mobl4> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4003:c06::236 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:15409 Archived-At: On 31 December 2014 at 02:12, Thiago Macieira wrote: >> > The types being different is a binary-incompatibility change of itself. >> Yes, but it's not an ABI break. > Not by itself. The ABI break happens when someone uses that type in their > function parameters. Now, the change of the type causes the functions to > change mangling, which is a BC break. I can imagine ways to avoid changing such a parameter type change happening without asking for it. See below. >> > Moreover, keeping the name the same by way of an inline namespace >> > introduces linker or runtime errors instead of a source-incompatible >> > error. >> If it's done via inline namespaces, yes. If it's done with non-inline >> namespaces, >> then it's a source-incompatible error. > Indeed, and in my opinion it's better to trigger a source-incompatible error > than to hide a binary- or runtime-incompatible change behind a source- > compatible change. No disagreement on that part. >> >> Library A cannot use the shared_ptr in Library B nor its 'method' because >> >> it's not magically forward-compatible with future changes. >> > Exactly. >> And nobody imposed the type in B on A, so it's not going to break due >> to B having >> such a type. Such an incompatible type is not without a cost, but it >> doesn't necessarily >> lead to ABI breaks or recompiling the world. > I'm not sure what you mean. I mean that using old-shared_ptr in A doesn't break just because B decides to start using a new-shared_ptr, IF the c++ library used continues to provide both old and new. >> > 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. >> I fail to see the reason for the "can't specify"-part. The header can >> condition the type it provides by default based on the C++ standard version >> used. > The point is that libA can't specify that it *wants* the C++11 version, > regardless of whether there's a future version available. I'm assuming it can, because I think there are ways to allow it to do so. >> > 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. >> Yeah, and there are ways to make it so it will just work. > And for std::string in libc++, it looks like it's possible to make it work. > However, I don't see how the counters could change in shared_ptr without > triggering a full rebuild. Well, for quite some time now I've been talking about solutions that add a new shared_ptr rather than changing the counters in it. >> > 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. >> Old users of the old shared_ptr don't need to be updated, and don't need to >> be recompiled. > They do if they exchange shared_ptr with any library that has been updated. > That's the cascade effect. They do if they exchange a shared_ptr with any updated library and the multiple shared_ptrs aren't versioned. >> Now, getting back to the original proposal: >> 1) I don't think its motivation is very strong >> 2) I don't think the atomicity argument is a deal-breaker >> 3) I'm not overly concerned about compatibility breaks >> 4) HOWEVER, concerning (3): I would certainly like to know whether >> libc++, libstdc++ and Dinkumware/Microsoft already have a suitable >> shared_weak count and whether the implementation of the proposal is just a >> matter of exposing >> what Howard outlined. >> Without the survey in (4), I don't think the proposal should go >> forward. The other >> concerns become much more surmountable of (4) doesn't present problems. > That's fine by me. #3 is your opinion and we agree to disagree there. Yeah, and I think our different day jobs cause certain differences in our views on how important (3) is or is not. :) I should point out though that (1) plays a part in this. If this proposal is likely to cause a true ABI break, we must consider whether it's worth it. There are some talks about an incompatible new conceptified library, so perhaps the arrival of such a thing would provide a more reasonable time to make such changes than just adding small more-or-less breaking changes here-and-there. If this proposal were the only thing causing compatibility breaks, I think I would seriously question its motivation. Then again, I question its motivation even now - the reason I'd be mildly for it is if implementations can already easily expose this information, I don't see the harm and can imagine reasonable uses for it. That may end up being a very big if. -- --- 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/. .