From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by sourceware.org (Postfix) with ESMTPS id 053AD3858D38 for ; Wed, 12 Aug 2020 18:40:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 053AD3858D38 Received: by mail-io1-xd43.google.com with SMTP id u126so4025904iod.12 for ; Wed, 12 Aug 2020 11:40:17 -0700 (PDT) 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:cc:content-transfer-encoding; bh=E5/RuWN76v+Nre5MZOJUquGkT6/EK1Khy/C4aUcETVk=; b=Q+xV6pgbonWzAWQS1eOWcElJYXzjpOv5f5VIJ+KjmZkRJt7CnrSUoItrmfhFIuY1mN 9rkmphjyfBUp0YKp1mxW2m9jtm6qQ5Pm7p+PiS2OH8w+MbaZLdk75TICSlANaF4zADqT SitUskHXoWtKZwHsER+V7VZBCKTfcS0JXcSGZr794JlUxS3lvIDN0cHLFuhhbLzUsnAx sJY/TETs+0K1YN4edicvT+x6C8FmzISxcdmDhklAoFME9RoHXK3QrqNtk9SKIODtLEr0 Dns84q95tpfanXsWrYwQLoEmbFmfBn5dgM/axYZHJeUyHO9uISCRcldsBEgVyLp8n1T0 6lTA== X-Gm-Message-State: AOAM53289gQr19vHN5ELvIz2ENK48NnpbpIMKtEFb64LFR3v7TxkTP+v XZ0WRWxa/vHSlE7qiNoJLOB5zThuc+SEFAqmbtE= X-Google-Smtp-Source: ABdhPJxnX2fpnR6WARBSeJQTpwNr1pPWlI7wW1nzgpQ+MvQGbwA9qWYulQWXjiHXsV52WCbe1uxcr3DGP51YzxJEODg= X-Received: by 2002:a5e:870d:: with SMTP id y13mr1126074ioj.188.1597257617533; Wed, 12 Aug 2020 11:40:17 -0700 (PDT) MIME-Version: 1.0 References: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> In-Reply-To: From: David Blaikie Date: Wed, 12 Aug 2020 11:40:05 -0700 Message-ID: Subject: Re: Coding style for C++ constructs going forward To: Liu Hao Cc: Nathan Sidwell , Luis Machado , "gdb@sourceware.org" , gcc Mailing List , Pedro Alves , Simon Marchi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 18:40:19 -0000 On Tue, Aug 11, 2020 at 7:49 PM Liu Hao via Gdb wrote: > > =E5=9C=A8 2020/8/11 =E4=B8=8B=E5=8D=889:55, Nathan Sidwell =E5=86=99=E9= =81=93: > > > > I agree, it's the way I use auto. I particularly like the > > auto *foo =3D expr; > > idiom, when you're getting a pointer, but the type of the pointee is cl= ear. It informs how you use 'foo'. > > > > > > Personally I dislike this syntax. Pointers are objects, and `auto foo =3D= expr;` should suffice. What if the type of `expr` is > `unique_ptr` or `optional`? The ptr-operator just can't exist there= . So why the differentiation? > > `auto& foo =3D ...` and `const auto& foo =3D ...` are necessary to indica= te that the entity being declared is a reference (and > is not an object), while `auto*` doesn't make much sense, as I discourage= plain pointers in my projects. Then use of `auto*` would make it easier for you to spot use of plain pointers in your projects & scrutinize them further? > > > > -- > Best regards, > LH_Mouse >