220 19425 <3075706.6Qm1PNuV1y@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Testing for supported features: Per-feature macros? Sentinel compilation? Date: Wed, 29 Jul 2015 17:55:26 -0700 Lines: 101 Approved: news@gmane.org Message-ID: <3075706.6Qm1PNuV1y@tjmaciei-mobl4> References: <1669023.4LeYva2qaW@tjmaciei-mobl4> <97f2e8e0-2ccf-4c96-8e23-73138dbd44e3@isocpp.org> 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 1438217774 26582 80.91.229.3 (30 Jul 2015 00:56:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 00:56:14 +0000 (UTC) Cc: ISO C++ Standard - Future Proposals To: denis bider Original-X-From: std-proposals+bncBCB4TK757YBRBJHM4WWQKGQEYAKHUGY@isocpp.org Thu Jul 30 02:56:05 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZKc8j-0001On-By for gclcip-std-proposals@m.gmane.org; Thu, 30 Jul 2015 02:56:05 +0200 Original-Received: by lafd3 with SMTP id d3sf8853616laf.1 for ; Wed, 29 Jul 2015 17:56:05 -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:cc: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=5ZIw32kHqVFyI5uep+1HehPSnFG2w+AnWQx5vDeyNWo=; b=Vrikb0V4KlmFGoCklefCKgmKfOKettJ+wYvqz6r2SONmbh4YAS1UnFlEe6LjIo03lF DdQNjDdi5LVwyvINXCI8CyY/pxwcq4un0HNTqEzCTIYGYZBnHCiFsiEW9tA8o6vb/fW+ 2wDp7f1sxq2eC4gs39UhlZREJJpOMoy3jxbWOs91/nlCoeue8CwZtPZ62OqwgjBJsGUe 2KxP0Gi6Lt4WwyhhEhFYk8lF960kU0A3VEYSNo15HLviJ4vECHUh3WECn5rEmjrmjESl jYJJhf9HH5Kq88dw2eMnKtoCS5TuKPGBMxGNU8m54zfkVH+6jIH+P8sebIqEnfygJRgp Gc X-Gm-Message-State: ALoCoQl+IRzo1BofXxYeV6FuHuJHJySZ0Y1xsoipudi/cB5u3ueSZvE5iWKQkDDzl7GFTq4KS9kZ X-Received: by 10.180.205.202 with SMTP id li10mr150663wic.5.1438217765011; Wed, 29 Jul 2015 17:56:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.96.169 with SMTP id dt9ls236342wib.34.gmail; Wed, 29 Jul 2015 17:56:04 -0700 (PDT) X-Received: by 10.180.72.35 with SMTP id a3mr802612wiv.21.1438217764134; Wed, 29 Jul 2015 17:56:04 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id el10si30265051wib.13.2015.07.29.17.56.03 for ; Wed, 29 Jul 2015 17:56:04 -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 (unknown [134.134.139.76]) by gondolin.macieira.info (Postfix) with ESMTPSA id 75C1011B647; Wed, 29 Jul 2015 17:56:03 -0700 (PDT) User-Agent: KMail/4.14.9 (Linux/4.1.2-1-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <97f2e8e0-2ccf-4c96-8e23-73138dbd44e3@isocpp.org> 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:19425 Archived-At: On Wednesday 29 July 2015 15:02:12 denis bider wrote: > Thiago: > > Save for actually linking the code to see if the library > > contains the functions it claims to have. > > I agree. However, I don't see this as a problem for the library performing > the test for features. > > The library's job is to compile cleanly, and to produce object files that > can be used by the library user for further linkage. I would argue, if the > final program fails to link properly, that's the user's problem, not the > library's. > > Definitions in header files are promises of the user of what's available, > via the compiler, to the library. It's up to the user to fulfill those > promises at the point of linkage. That sidesteps the issue of enabling and disabling features at compilation time. For example, zlib.h might be available as a header (__has_include( is true), but -lz is not being passed to the linker. That means a detection by the compiler may make matters worse. Note also how I talked about a feature that is already being implemented. My point is that those things do not replace a good configure script. > Matthew: > > You do realize that by the time the compiler sees the code, > > the PP has already run? > > I thought actual implementation has already migrated away from this > concept? I thought this is now more so a fiction that's no longer true in > practice. The compilers are required to produce preprocessed output, at least until Modules comes along. I can still pass -E to the compiler and see the output. > For example, for MSVC to implement #pragma warning, it has to be performing > *some* type of meta-processing at the same time as compiling. Even if this > means running the preprocessor first, and inserting another kind of > meta-information that is processed at the same time as compiling. #pragma is not a preprocessor token. That means this kind of compilation detection, if accepted, could be something else, other than a preprocessor directive. For example #probe code #then code #else code #endprobe Note how you could not #define inside the then and else clauses because the preprocessor has already run. I wouldn't choose this method. > Even so - the *preprocessor* could invoke the compiler. This should be easy > if the probe code is independent of what comes before and after. That's how I'd do it: the preprocessor should realise that running the compiler is required and would launch it, getting the status. That gets into a lot of hairy problems of how the preprocessor can run the compiler. One of the ways of offloading code generation is to run the preprocessor in one machine and send the preprocessed output to another to compile. That means the preprocessor and the actual compiler may not exist in both machines... > > In my experience, it's more typical that users are required > > to use a compiler at least as capable as the one used > > to build the library, and the library hard-codes what > > features were enabled when it was built. > > Crypto++ would like to use e.g. move semantics without preventing use with > VS 2005. My understanding is that Boost also desires to use the latest > language features, but still provide compatibility with compilers that lack > them (if I'm not mistaken, including VS 2005?). I don't think you understood my point. I was saying that you can do a check of feature at the time of the compilation of the library and record that in a config.h that gets installed with it, as downgrading the compiler is a rare occurrence. How often do you compile the library with VS 2010 (which supports move semantics) and then compile the application with VS 2005? Answer: never. -- 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/. .