220 19447 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Testing for supported features: Per-feature macros? Sentinel compilation? Date: Thu, 30 Jul 2015 12:31:41 -0400 Lines: 81 Approved: news@gmane.org Message-ID: References: <97f2e8e0-2ccf-4c96-8e23-73138dbd44e3@isocpp.org> <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 1438273928 31695 80.91.229.3 (30 Jul 2015 16:32:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 16:32:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBB65C5GWQKGQEA7NP3XA@isocpp.org Thu Jul 30 18:31:58 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZKqkP-00047n-Dm for gclcip-std-proposals@m.gmane.org; Thu, 30 Jul 2015 18:31:57 +0200 Original-Received: by lbcut9 with SMTP id ut9sf4648655lbc.3 for ; Thu, 30 Jul 2015 09:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-type:user-agent:in-reply-to: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=yl4VVzwR83qaIH4SgHjHPXq0jii+OYKw+SmdQ3+ppJ4=; b=RrMQk1IoqMuTCidqplIM1mxS6fDW+cK+EVuCvQANVKA1JX25oIJjJQUPhzJ31LMggv XWVcfqWwCU1gXRv3/FU1VjKLzvz6evmjwC/7CTEMKs01oFfjC8jfv+sohJKGX1TnLQ+d cOK5a2A1/LqD4Da8VWLmqJpbX+kYUroSRsJGi6W7XoGDLKe9CosQ5tWg5hYkFxxkzCjr OEfrGEBHEPRwn0rn1+zE1qzrqmgIgBYjAbhLXSpAgK9AHtKVc1HKLK+QA8Soe1ldwGi+ n3ast6sSBCrGURhDC/reT34wcwayeZ283SpE1UHq2wW8wcWB3fihhFP7rqnmho1b2EXg X-Gm-Message-State: ALoCoQn/2mZv7DGc0htPuPYWnTbYy6znDGmLCO/MAcUSGnbVPHzXxzgGa/yqziV/m8tlB3K9n2CN X-Received: by 10.152.182.226 with SMTP id eh2mr17998498lac.0.1438273917084; Thu, 30 Jul 2015 09:31:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.203.166 with SMTP id kr6ls193623lac.32.gmail; Thu, 30 Jul 2015 09:31:55 -0700 (PDT) X-Received: by 10.152.5.197 with SMTP id u5mr45234348lau.94.1438273914995; Thu, 30 Jul 2015 09:31:54 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id dp7si1207048lbc.155.2015.07.30.09.31.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 Jul 2015 09:31:54 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZKqkL-000461-Td for std-proposals@isocpp.org; Thu, 30 Jul 2015 18:31:54 +0200 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jul 2015 18:31:53 +0200 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Jul 2015 18:31:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 72 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <1544148.KS9yEPmrxK@tjmaciei-mobl4> X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mail=gclcip-std-proposals@m.gmane.org; dmarc=fail (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-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:19447 Archived-At: 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]'.) 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? >> On 2015-07-29 20:55, Thiago Macieira wrote: >>> How often do you compile the library with VS 2010 (which supports move >>> semantics) and then compile the application with VS 2005? Answer: never. >> >> You could be using a pre-built library that was built with a newer >> compiler to build an application on a machine that has only an older >> compiler. (Although, pre-built stuff tends to use the oldest compiler >> possible, or be available built with multiple compiler versions.) > > 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. >> 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. 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"...) (Here following points Thiago and I agree upon...) At any rate, it's common to have checks of this nature, whether at compile time, link time, or run time (e.g. using older Qt or libpng library when built against newer headers, just to name two offhand examples I *know* I've run into). The upshot of this all being of course that there isn't as strong a motivation to do feature checks at consumer-build time as library-build time. And we can already do the latter. -- Matthew -- --- 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/. .