Deutsch English Français Italiano |
<v6jnu8$1ebr7$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown <david.brown@hesbynett.no> Newsgroups: comp.lang.c Subject: Re: question about nullptr Date: Tue, 9 Jul 2024 18:19:20 +0200 Organization: A noiseless patient Spider Lines: 72 Message-ID: <v6jnu8$1ebr7$1@dont-email.me> References: <v6bavg$3pu5i$1@dont-email.me> <20240706054641.175@kylheku.com> <v6bfi1$3qn4u$1@dont-email.me> <l9ciO.7$cr5e.2@fx05.iad> <877cdyuq0f.fsf@bsb.me.uk> <2ckiO.19403$7Ej.4487@fx46.iad> <87plrpt4du.fsf@bsb.me.uk> <9bCiO.7108$sXW9.3805@fx41.iad> <877cdwu9s1.fsf@nosuchdomain.example.com> <20240708222804.00001654@yahoo.com> <v6hotk$11nib$2@dont-email.me> <20240709104848.00005732@yahoo.com> <86cynmajh9.fsf@linuxsc.com> <20240709155014.000039d0@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 09 Jul 2024 18:19:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b5f81ffa340fccea092912f722a4136c"; logging-data="1519463"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+6AODa0tYMMFpzu4vRPWLIERcHPw+5tcs=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:4s+Q7UeL5XwscBV4uFOU7A0pW7Y= Content-Language: en-GB In-Reply-To: <20240709155014.000039d0@yahoo.com> Bytes: 4235 On 09/07/2024 14:50, Michael S wrote: > On Tue, 09 Jul 2024 04:32:50 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Mon, 8 Jul 2024 15:23:47 -0700 >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >>> >>>> On 7/8/2024 12:28 PM, Michael S wrote: >>>> >>>>> On Sun, 07 Jul 2024 15:17:34 -0700 >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>> >>>>>> I just about always use NULL, not 0, when I want a null pointer >>>>>> constant. Similarly, I use '\0', not 0, when I want a null >>>>>> character, 0.0 when I want a floating-point zero, and false when >>>>>> I want a Boolean zero. I just like being explicit. >>>>> >>>>> Pointer: I very rarely use NULL. >>>>> Character: I never use '\0'. >>>> >>>> Not even something like: >>>> >>>> #define CLINE 128 >>>> >>>> char x[CLINE] = { '\0' }; >>>> >>>> ? >>>> >>>> ;^) >>> >>> I see nothing special about your case. {0} is the most appropriate. >>> >> >> Any use of '\0' almost always strikes me as an affectation. It's >> like people want to somehow pretend that it's not the same as >> just 0. >> >>> And, BTW, I never use #define for integer constants. >> >> What do you do if you need to define a compile-time constant >> whose value is outside the range of signed int? With the >> understanding that the context is C as it is now, and not >> C++ or some imagined other language. > > In comment above "integer constant" meant "within the range of signed > int". But let's accept more general meaning. Then, when it happens, I > have a problem and forced to flex my principles :( > Luckily, it's pretty rare. I mean, it's pretty rare that the constant > is both outside the range of signed int and I really really have to > have it as compile-time constant. More often big numbers like these are > used in arithmetic/logic, so 'const wide_type' or 'static const > wide_type' is practically as good as a "real" compile-time constant > despite being "less constant" in theory. > static const of the appropriate type should be as good as a define'd value in almost any circumstance (assuming, of course, an optimising compiler). There are circumstances where you can use an enumeration constant as a named integer constant, but where a static const int value cannot be used, such as the size of statically allocated arrays. But you are very unlikely to need such a large value to be an integer constant, rather than just a value that the compiler sees as a compile-time constant for optimisation purposes. (And C23 helpfully allows enum values that are of larger integer types. And also "constexpr" declarations.)