Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Tue, 8 Apr 2025 18:40:03 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 83
Message-ID: <slrnvvar60.ejp.candycanearter07@candydeb.host.invalid>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjgjn$1v1n4$1@dont-email.me>
 <vsjk4k$24q5m$1@dont-email.me> <vsjlcp$230a5$1@dont-email.me>
 <vsni1v$291i3$5@dont-email.me>
 <slrnvv82gk.2aciv.candycanearter07@candydeb.host.invalid>
 <vt1a7f$i5jd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 08 Apr 2025 20:40:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fa2a23ad082c7388cada7dbc42e5fdf8";
	logging-data="2989008"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/sotRCA5u1lH5ikTBDB9Xqvxc7Bisi6OCxq42XorftGg=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:kwPkaa3isoiodkQoXbkUWmib7Fo=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D
Bytes: 4764

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote at 19:49 this Monday (GMT):
> On 07.04.2025 19:30, candycanearter07 wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 03:01 this Friday (GMT):
>>> On Wed, 2 Apr 2025 16:33:46 +0100, bart wrote:
>>>
>>>> Here, tell me at a glance the magnitude of
>>>> this number:
>>>>
>>>>      10000000000
>>>
>>>     #define THOUSAND 1000
>>>     #define MILLION (THOUSAND * THOUSAND)
>>>     #define BILLION (THOUSAND * MILLION)
>>>
>>>     uint64 num = 10 * BILLION;
>>>
>>> Much easier to figure out, don’t you think?
>
> Yes, where appropriate that's fine.
>
> But that pattern doesn't work for numbers like 299792458 [m/s]
> (i.e. in the general case, as opposed to primitive scalers).
>
> And it's also not good for international languages (different
> to US American and the like), where "billion" means something
> else (namely 10^12, and not 10^9), so that its semantics isn't
> unambiguously clear in the first place.

I'd also say the difference between Megabytes (MB) and MiB is VERY easy
to mess up, but it's close enough for displaying to the end user until
you get into the really big files.

> And sometimes you have large numeric literals and don't want
> to add such CPP ballast just for readability; especially if
> there is (or would be) a standard number grouping for literals
> available.
>
> So it's generally a gain to have a grouping syntax available.
>
>> 
>> 
>> I used to do a bit of code for a codebase that did that with SECONDS and
>> MINUTES since (almost) every "time" variable was in milliseconds, and it
>> was very nice. That is just my subjective opinion, though. :P
>
> That actually depends on what you do. Milliseconds was (for our
> applications) often either not good enough a resolution, or, on
> a larger scale, unnecessary or reducing the available range.
>
> Quasi "norming" an integral value to represent a milliseconds unit
> I consider especially bad, although not that bad as units of 0.01s
> (that I think have met in Javascript). I also seem to recall that
> MS DOS had such arbitrary sub-seconds units, but I'm not quite sure
> about that any more.

Well, yeah. Using doubles for timescales is always going to be messy.

> A better unit is, IMO, a second resolution (which at least is a
> basic physical unit) and a separate integer for sub-seconds. (An
> older Unix I used supported the not uncommon nanoseconds attribute
> but where only milli- and micro-seconds were uses, the rest was 0.)
>
> Or have an abstraction layer that hides all implementation details
> and don't have to care any more about implementation details of
> such "time types".

I mean it was abstracted, everything timewise is measured as ticks
against world.time (10 ticks per second), so ye

>> it was more like
>> #define SECONDS *10
>> #define MINUTES SECONDS*60
>> #define HOURS MINUTES*60
>> 
>> , though. Probably would be more notably annoying to debug in weird
>> cases if the whole language/codebase wasnt borked spagetti :D
>
> Janis
>


-- 
user <candycane> is generated from /dev/urandom