From dev-return-2670-archive-asf-public=cust-asf.ponee.io@orc.apache.org Wed Oct 31 19:08:04 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id D9FB5180668 for ; Wed, 31 Oct 2018 19:08:03 +0100 (CET) Received: (qmail 81342 invoked by uid 500); 31 Oct 2018 18:08:03 -0000 Mailing-List: contact dev-help@orc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@orc.apache.org Delivered-To: mailing list dev@orc.apache.org Received: (qmail 81301 invoked by uid 99); 31 Oct 2018 18:08:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Oct 2018 18:08:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id E004D1A4B59 for ; Wed, 31 Oct 2018 18:08:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.889 X-Spam-Level: * X-Spam-Status: No, score=1.889 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id Hu4AyhRlUf7L for ; Wed, 31 Oct 2018 18:08:00 +0000 (UTC) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2595F5F4A0 for ; Wed, 31 Oct 2018 18:08:00 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id r10-v6so17543011wrv.6 for ; Wed, 31 Oct 2018 11:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iGlWLLBKNnrzS3oZqcLdD12/V/cRmxd7FqQZtUAce6U=; b=iKM6pJj3WVtxgc4jKcuQ1gR2b0gxFugjEnwlD5tA8YXheXIpvIeMt073b/8KJTWfnQ fFbyqgblsLrMQptNJB2GYaXnoAmNb3swoIxFCOpaU9Yz4/7DjmjAEA0e0goMZzJ1PjsY q/azLWMOt1v4w4oImcG70PFzHb5ntQVoG5/Jaxgt3FKagyAj5tMAJTdlE1PgT4PKod4/ BQk5HbUh5J71rynscrsxobcWsC6CnhZcnbPk3fpJIPYatjJyCekjGxPTkF5HFVEDRmfr zDTYd7nTebh5hIlonkUOe0kdN4Wro4s9Sj+MJdxmiyyFDdryKITE4yNX+Sn8e+/Z+DhF I2uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iGlWLLBKNnrzS3oZqcLdD12/V/cRmxd7FqQZtUAce6U=; b=bfVm1WRO08/7vBtciqMf+j8dsqFZTBiN5pr8nb7Tl/KZA0Hj0aRWtPhzWiGGBJ1KRq GXf728rOEOhFTw6CoYZhtD2JVLGZv2plTB2zEwgxDnYD5H61vJz8/vR+K7Tn+s6PsyxV WHg6ncTNI7fun7IpA/hidhLcqWv8MjCnkEOjP0c/+0OoPGGeo/0J4LQkAS83qg5jnqqo iIbcnJZCxQyUsgFAVZSqkjbVzyMjJyZSxY93bNX/UpPm4c/VfmqblTN65MxgX9DFcDKp GDLGFqqSS9kqqi2NtwfGMWFHxavj6z8RkD0VR+peOTEvf5MPVqBkN5Ik7ZSXUtHA84/o i6Eg== X-Gm-Message-State: AGRZ1gJzJjB69qERmmIGqg8ARaKZFPTlFgqzw7KCJTo1i9WTutw9/Jfm ED28PA9N/7zROfL5XgND05K/uXSQRTTekR0pyFA7R8Gs X-Google-Smtp-Source: AJdET5f3DEBJLnTr5TbFEacDCa/cd1K83JnpobDVTNPZTerTiZXRd6PQ9rFmuchWgpQSF75nnL0f35x9kkiEy1BgsWQ= X-Received: by 2002:a5d:63cf:: with SMTP id c15-v6mr3835708wrw.221.1541009272763; Wed, 31 Oct 2018 11:07:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Owen O'Malley" Date: Wed, 31 Oct 2018 11:07:41 -0700 Message-ID: Subject: Re: Usage of ORC_UNIQUE_PTR To: dev@orc.apache.org Content-Type: multipart/alternative; boundary="0000000000004c77d105798a2e39" --0000000000004c77d105798a2e39 Content-Type: text/plain; charset="UTF-8" Ok, we should have done a better job at documenting these. For most of the features like ORC_UNIQUE_PTR and ORC_NOEXCEPT, we take two different approaches depending on the context: In external header files, we always use the ORC_*, because the users have to be able to include our header files into their projects without getting dangerous #defines. In our internal code, we have #defines in c++/src/Adaptor.hh.in that map the "normal" form into the ORC_* form. So if the C++ compiler doesn't have "noexcept" we have a define that looks like #define noexcept ORC_NOEXCEPT. Thus, in our internal code we can just write "noexcept" and the compilers that have it, will use it. The compilers that don't will have the token dropped. Now, ORC_UNIQUE_PTR is also a historic case, where we needed it for CentOS 5 (and probably some of the other older OS), before we dropped support for it. Looking through the logs from my runs from ORC-418, we don't need ORC_CXX_HAS_UNIQUE_PTR on linux: centos6-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > centos7-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > debian8-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > debian9-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > ubuntu12-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > ubuntu14-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > ubuntu16-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > ubuntu18-test.log:-- Performing Test ORC_CXX_HAS_UNIQUE_PTR - Success > We also don't need it on MacOS. I don't know if we need it for Windows. .. Owen On Tue, Oct 30, 2018 at 7:15 PM Gang Wu wrote: > Hi Fang, > > ORC_UNIQUE_PTR was intended to support platforms which does not support > c++11. You can also find that std::unique_ptr is translated into > std::auto_ptr as well. Current and future versions of ORC will not support > those obsolete platforms; therefore I think it is ok to use std::unique_ptr > everywhere. > > Best, > Gang > > On Tue, Oct 30, 2018 at 5:31 PM Fang Zheng > wrote: > > > Hi, > > > > I have a question about the usage of ORC_UNIQUE_PTR in C++ code: > > > > > > The ORC_UNIQUE_PTR macro is used intensively in the public header files > in > > c++/include/. On the other hand, among those files in c++/src/ directory, > > std::unique_ptr appears much more frequently than ORC_UNIQUE_PTR (356 vs. > > 16 by grep). In fact, some function declarations in header files use > > ORC_UNIQUE_PTR while the definitions in src use std::unique_ptr (please > see > > JIRA ORC-428 and the pull request: > https://github.com/apache/orc/pull/331 > > ). > > > > > > Assuming that ORC_UNIQUE_PTR is intended to work regardless of whether > > std::unique_ptr is available, I am wondering if ORC_UNIQUE_PTR should be > > preferred in the entire c++ codebase. > > > > > > Thanks, > > > > Fang > > > --0000000000004c77d105798a2e39--