From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35966 invoked by alias); 26 Oct 2017 23:29:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35944 invoked by uid 89); 26 Oct 2017 23:29:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Oct 2017 23:29:24 +0000 Received: by mail-oi0-f43.google.com with SMTP id n82so8399568oig.3 for ; Thu, 26 Oct 2017 16:29:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=S8S2mf7HUDAK4LpWUDmZ/lcAp7cxZGO/0AZ0eXGEztE=; b=a/4Ed8ORa6+HRYYMfqJmO227wwxXfnQlV3zxO8ex7/MV0hEtegDpXDKM6e0iPI3Ddt nX3lGsth8Em/CqNGw2A1OQCq1LtkM2s0rU8mJYr437e60uA59tS9aoWuTCNeK7g3ts2Y UKfUbjxYFyiKXA9Nr3kBNB3ZOzZs42ittjRSGKT2px9MwJroSoVBbdGM0CU5SeSPu769 oWhFuWmQjaFoQHV1jxkkwVeX2dIdB11n7qlvkTjYIagVQe1e2ctseRfF0MfmjJ7Q8tmd pIN4lVhSni7FZvbp0icpUjo8ZVDlK371iRoBz+Ey36z2lK5aas1GlewULEhq9ZjLrDtu kh9Q== X-Gm-Message-State: AMCzsaWlpbqF0QHnqi8wFU3LpRIVFcWf8ANMNWVpoulDsRElpObICNmF VIfz+csvtEBzITK/om9XTAs= X-Google-Smtp-Source: ABhQp+SqCv2eRJEVXHsxq6dUgj1js9JwzAsz9mESVfMYfcBsSMibAbaSfOMXM7VVYoqYVfDlc8aiFQ== X-Received: by 10.157.49.54 with SMTP id e51mr3641186otc.81.1509060562550; Thu, 26 Oct 2017 16:29:22 -0700 (PDT) Received: from localhost.localdomain (71-218-5-6.hlrn.qwest.net. [71.218.5.6]) by smtp.gmail.com with ESMTPSA id q67sm2785477oif.11.2017.10.26.16.29.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 16:29:22 -0700 (PDT) Subject: Re: [006/nnn] poly_int: tree constants To: Pedro Alves , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <871sltvm7r.fsf@linaro.org> <878tg1u7cl.fsf@linaro.org> <877evi3oeh.fsf@linaro.org> <8737662tlp.fsf@linaro.org> <2840a6a6-f80c-ca8f-aab2-2729ac598bf6@gmail.com> <6a1236c2-f271-8309-5b7f-ac8723889cc0@redhat.com> <1c2abca8-d7e9-ab85-04c1-1618c8957368@gmail.com> <50c0362c-d8d5-b75f-cd05-9017ed481b5c@redhat.com> From: Martin Sebor Message-ID: <9957e036-79ae-486c-f786-28bb149a37b0@gmail.com> Date: Thu, 26 Oct 2017 23:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <50c0362c-d8d5-b75f-cd05-9017ed481b5c@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg02016.txt.bz2 On 10/26/2017 01:17 PM, Pedro Alves wrote: > On 10/26/2017 07:54 PM, Martin Sebor wrote: > >> (...) in the general case, it is preferable to >> declare each variable at the point where its initial value is known >> (or can be computed) and initialize it on its declaration. > > With that I fully agree, except it's not always possible or > natural. The issue at hand usually turns up with > conditional initialization, like: > > void foo () > { > int t; > if (something) > t = 1; > else if (something_else) > t = 2; > if (t == 1) > bar (); > } > > That's a simple example of course, but more complicated > conditionals aren't so easy to grok and spot the bug. > > In the case above, I'd much prefer if the compiler tells me > I missed initializing 't' than initializing it to 0 "just > in case". Sure. A similar observation could be made about std::string or std::vector vs a plain C-style array, or for that matter, about almost any other class. But it would be absurd to use such examples as arguments that it's better to define classes with a no-op default constructor. It's safer to initialize objects to some value (whatever that might be) than not to initialize them at all. That's true for fundamental types and even more so for user-defined classes with constructors. IMO, a good rule of thumb to follow in class design is to have every class with any user-defined ctor either define a default ctor that puts the object into a determinate state, or make the default ctor inaccessible (or deleted in new C++ versions). If there is a use case for leaving newly constructed objects of a class in an uninitialized state that's an exception to the rule that can be accommodated by providing a special API (or in C++ 11, a defaulted ctor). Martin