220 19457 <25686309.1faxnaUb0v@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Testing for supported features: Per-feature macros? Sentinel compilation? Date: Thu, 30 Jul 2015 13:29:17 -0700 Lines: 88 Approved: news@gmane.org Message-ID: <25686309.1faxnaUb0v@tjmaciei-mobl4> References: <1544148.KS9yEPmrxK@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 1438288179 10561 80.91.229.3 (30 Jul 2015 20:29:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 20:29:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBIES5KWQKGQEICUXQMI@isocpp.org Thu Jul 30 22:29:27 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f198.google.com ([209.85.217.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZKuSA-0003dt-E4 for gclcip-std-proposals@m.gmane.org; Thu, 30 Jul 2015 22:29:22 +0200 Original-Received: by lbbnr7 with SMTP id nr7sf15321390lbb.2 for ; Thu, 30 Jul 2015 13:29:21 -0700 (PDT) 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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=pip+B7zat5BxSn4xru737AsAEIlamFhAPYuilPk91x8=; b=BNr7NSKb7Tv8HnUx8D5RuXxQOxiJLbmh/CxE/wemqzXou9eGL/a32SdadoRMj9U4z9 07ZJLzPkt0kwykAfPjHaZTMG90Yn2VyWvgWfN9AhSnqJVlrL0Erxid75owa/PhD9mWaU sSDv6azFpOF54XNH0NYf7JoQg42/EuxROEq1rt2CMVjUCQyyilDDSnSkaz8aWai2dRL0 aPf09fQwlYL+MY3I9l5kayv5SEA7T4lC9+jMNF1Keo6ODRubgngyuJ4xciZYmQKYDJtq vgAAglhMZlp2v/i3GgfFrvwQIYx+DOAFBRXqjAYOSJOqefK+pwdT70ULqqQwziFYfC2p SG9g= X-Gm-Message-State: ALoCoQkuGxBaifx4V4p/CEG7GtJPWeOVwZ3qhDJ7sZ2ycAYQpK6YXCKsNQKyp58S18rDFlQfcyiO X-Received: by 10.112.215.67 with SMTP id og3mr18211949lbc.8.1438288161759; Thu, 30 Jul 2015 13:29:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.84.135 with SMTP id z7ls39984wiy.40.canary; Thu, 30 Jul 2015 13:29:20 -0700 (PDT) X-Received: by 10.181.13.36 with SMTP id ev4mr9740022wid.65.1438288160179; Thu, 30 Jul 2015 13:29:20 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id cb3si3940158wjc.44.2015.07.30.13.29.20 for ; Thu, 30 Jul 2015 13:29:20 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl4.localnet (jfdmzpr02-ext.jf.intel.com [134.134.137.71]) by gondolin.macieira.info (Postfix) with ESMTPSA id 6296C11B6C3 for ; Thu, 30 Jul 2015 13:29:19 -0700 (PDT) User-Agent: KMail/4.14.9 (Linux/4.1.2-1-desktop; KDE/4.14.9; 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 78.47.120.188 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-Spam-Checked-In-Group: std-proposals@isocpp.org 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:19457 Archived-At: On Thursday 30 July 2015 12:31:41 Matthew Woehlke wrote: > On 2015-07-30 12:02, Thiago Macieira wrote: > > On Thursday 30 July 2015 11:14:21 Matthew Woehlke wrote: > >> Hmm... that said, you might be right in the sense that IIRC there are > >> "PP" directives that are left in place (e.g. #pragma), or even added > >> (e.g. #line). So maybe my previous comment doesn't apply. Disregard, > >> then :-). > > > > The problem with that is that the compiler now sees the invalid code too > > and needs to decide what (not) to do with it. You can't use the > > preprocessor to remove code the compiler shouldn't see. > > I must misunderstand something. If the test is done by the PP, then the > PP will remove the test code. (The PP most certainly can and does do > this sort of thing; see almost any use of '#if[def]'.) Correct, but that wasn't what was suggested. It was: > If the test is *not* done by the PP, then the directives marking the > block would still be present, no? So the compiler can still isolate it > (and needs to do so anyway in order to perform the test). > > Did I miss something? Just the part that the compiler usually does not deal with invalid code. Invalid code is often removed by the preprocessor. This requires moving a portion of the preprocessor's functionality into the compiler itself. > > You cannot do that. Let's forget the fact that MSVC versions are > > incompatible with each other altogether and analyse the more common case > > of Unix shared libraries: > > > > The rule of thumb on shared libraries on Unix systems is that you must run > > with a version equal to or higher than the one you linked to. Breaking > > that > > rule is not supported by anyone. > > Well, yes, but that's essentially the point I was trying to make. What I > mean is, I can conceive of how someone might attempt to do such a thing, > but it's unlikely (maybe "unlikely" is even an understatement) that the > library would try to support it. Anyone who does that has special rules for how to deal with the issue. For example, Qt is both forwards- and backwards-compatible within one minor release. That implies we can't add any new symbols to the build. As a consequence, there can be no new features. The same is true here of a compiler feature: if a compiler begins supporting move semantics, it's not forwards-compatible. No one will try to support this because it doesn't work, period. > >> It *can* happen, but the library headers may well check for that and > >> raise an error. > > > > What headers? The problem is linking and dynamic linking. > > I have at least once written a header that injects compiler information > into its "config.h" such that when you go to use the library, it checks > that the compiler you are using as a consumer is at least "as good as" > (for whatever metric, e.g. version, language version, etc.) what it was > built with, and raises an error otherwise. Indeed, but most people simply write code that implies this. > I know Qt has some similar version checks. (Isn't MOC generated code set > up to refuse to build against older Qt headers than the version of MOC > that generated the code? In fact I want to say it's not even "older" but > "different"...) Right, but you don't deploy MOC-generated code. You're supposed to compile it right now and then, so the Qt headers and the moc tool must match. -- 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/. .