220 19420 <97f2e8e0-2ccf-4c96-8e23-73138dbd44e3@isocpp.org> article Path: news.gmane.org!not-for-mail From: denis bider Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Testing for supported features: Per-feature macros? Sentinel compilation? Date: Wed, 29 Jul 2015 15:02:12 -0700 (PDT) Lines: 193 Approved: news@gmane.org Message-ID: <97f2e8e0-2ccf-4c96-8e23-73138dbd44e3@isocpp.org> References: <2435938.M1snUpQCpx@tjmaciei-mobl4> <32012d49-da47-4db6-b71c-ffcd09d10a45@isocpp.org> <1669023.4LeYva2qaW@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1030_282930463.1438207332388" X-Trace: ger.gmane.org 1438207340 32747 80.91.229.3 (29 Jul 2015 22:02:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 22:02:20 +0000 (UTC) Cc: erich.keane@verizon.net, thiago@macieira.org To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBZM24WWQKGQESTHQXLQ@isocpp.org Thu Jul 30 00:02:18 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZKZQV-00006U-9B for gclcip-std-proposals@m.gmane.org; Thu, 30 Jul 2015 00:02:15 +0200 Original-Received: by ykek23 with SMTP id k23sf23724802yke.2 for ; Wed, 29 Jul 2015 15:02:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=hrj1dk2F2Q2WxMDqnF3bP+HcKYWa9Go4RWlJ56yInLs=; b=eC2mtRYAQc75D5GeWAT6K6v0lnJ7uL2k1nOAZ+svti0oIKp/UXx2Gc6FbA0a9cE92i OKkImWwi7e6u/JUfudXpf78/42SMTpMa8hKvbfHFxnxLUSAK2BpBgKZNzlMtRRdHlz1D b9etkOadNC8fzy5l9zqdQlnQYNtfmZfh9gyaqjQ/H8i7jhuMqj1uAv9i9/zbpxsqNHox GbNH4Q+FlaMTDrfL31WHoKuxoymd1hmV2CYi2FQyia/C/vyrv5voPo2GNtl3qfNadTz9 DndfA/3cJy80ES2Xw+C5FocwkSOhqe2URzGewcnVjClpEj/ydf3gXokFQldyOBbFDYG1 YfmQ== X-Gm-Message-State: ALoCoQnuD/Bou+F2CavZU8UaSIEMEdFO30NYkX/IEyJbp9ZCXXoVkMGfSwKmjxvGobjjRPVEEU36 X-Received: by 10.129.125.139 with SMTP id y133mr40366214ywc.33.1438207334328; Wed, 29 Jul 2015 15:02:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.10 with SMTP id a10ls434714qge.94.gmail; Wed, 29 Jul 2015 15:02:13 -0700 (PDT) X-Received: by 10.140.86.105 with SMTP id o96mr600367qgd.11.1438207332986; Wed, 29 Jul 2015 15:02:12 -0700 (PDT) In-Reply-To: <1669023.4LeYva2qaW@tjmaciei-mobl4> X-Original-Sender: isocppgroup@denisbider.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:19420 Archived-At: ------=_Part_1030_282930463.1438207332388 Content-Type: multipart/alternative; boundary="----=_Part_1031_1318270355.1438207332389" ------=_Part_1031_1318270355.1438207332389 Content-Type: text/plain; charset=UTF-8 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. If functions are missing - the user could define them (depending on how involved they are). 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. 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. Maybe other compilers do not do this, and adhere strictly to running the preprocessor in a separate run? Even so - the *preprocessor* could invoke the compiler. This should be easy if the probe code is independent of what comes before and after. Making the probe code completely independent is a departure from my original suggestion. However, I have already conceded the need for this, so that any template code that's part of the probe can be properly and fully evaluated. > 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?). On Tuesday, July 28, 2015 at 6:42:40 PM UTC-6, Thiago Macieira wrote: > On Tuesday 28 July 2015 17:35:24 denis bider wrote: > > But if you had probe compilation, you could determine whether the > compiler's > > and the standard library's actual, exact level of support is suitable > for > > your actual, exact purposes. > > > > Just saying... ;) > > Save for actually linking the code to see if the library contains the > functions it claims to have. > > -- > 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/. ------=_Part_1031_1318270355.1438207332389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thiago:

> Save for actually link= ing the code to see if the library
> contains the=C2=A0functio= ns it claims to have.

I agree. However, I don= 't see this as=C2=A0a problem for the library performing the test for f= eatures.

The library's job is to compile clean= ly, and to produce object files that can be used by the library user for fu= rther 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 ful= fill those promises at the point of linkage.

If fu= nctions are missing - the user could define them (depending on how involved= they are).


Matthew:

=
> You do realize that by the time the compiler sees the code,=
> the PP has already run?

I tho= ught actual implementation has already migrated away from this concept? I t= hought this is now more so a fiction that's no longer true in practice.=

For example, for MSVC to implement #pragma warnin= g, it has to be performing some type of meta-processing at the sam= e time as compiling. Even if this means running the preprocessor first, and= inserting another kind of meta-information that is processed at the same t= ime as compiling.

Maybe other compilers do not do = this, and adhere strictly to running the preprocessor in a separate run?

Even so -=C2=A0the preprocessor could invok= e the compiler.=C2=A0This should be easy if the probe code is independent o= f=C2=A0what comes before and after.

Making the pro= be code completely independent=C2=A0is a departure from my original suggest= ion. However,=C2=A0I=C2=A0have already conceded the need for this,=C2=A0so = that any template code=C2=A0that's part of the probe can be properly an= d fully evaluated.


> In my exper= ience, 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 enabl= ed 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 pro= vide compatibility with compilers that lack them (if I'm not mistaken, = including=C2=A0VS 2005?).



On Tuesday, July= 28, 2015 at 6:42:40 PM UTC-6, Thiago Macieira wrote:
On Tuesday 28 July 2015 17:35:24 denis bider wrote:
> But if you had probe compilation, you could determine whether the = compiler's
> and the standard library's actual, exact level of support is s= uitable for
> your actual, exact purposes.
>=20
> Just saying... ;)

Save for actually linking the code to see if the library contains the= =20
functions it claims to have.

--=20
Thiago Macieira - thiago (AT) macieira= ..info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4= 5358

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_1031_1318270355.1438207332389-- ------=_Part_1030_282930463.1438207332388-- .