|
Boost : |
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2025-01-20 10:16:35
Am 18.01.25 um 12:48 schrieb Christopher Kormanyos via Boost:
> > Could you illustrate such a use case?
> > Concretely, what do you mean by
> > several widths of types? Do you
> > mean decimal32 vs decimal64?
> Yes. Let's say you made a program
> that uses one data table for a type T that could be decimal32, 64 or 128.
> But you only wanted one table.
> You would make the table entries with the highest width suffix and decoratee ach table entry with a static-cast to T in order to get all the table entries into type T.
> To be fair, everyone already has todo something like this with normal float, double and long double.
>> With the syntax you have today,
>> you already have distinct suffixes
>> for each type (i.e. _df always constructs
>> decimal32, _dd always constructs decimal64,
>> and so on).
> Yes. And I gave one potential recipe on how to deal with this in generic code above. My judgement may have been hurried and might seem unfair.
> But my intuition tells me, a whole bunch of clients would run into compilation failures. Until they come up with their own recipes for generic literal values.
> And the result would be more frustration than had we simply done nothing.
I'm not sure I understand this.
How can you have "generic code" with different suffixes where there are
compilation failures that would not be there in non-generic code?
From "one data table for a type T" I imagine something like
`T table[] = {1.25_df, 3.2_df, 51_df}`
So while your table type is generic the constants used are not.
If the above errors due to using `1.25352397826723672375_df` you ought
to use `_dd` to be able to use it in `decimal64 table[]` anyway.
I don't see a scenario where it would be ok to truncate a constant and
then store them in a type that would have been able to store the
nun-truncated value.
The other way round is more reasonable to use rounding/truncation when
really required by the target type.
Can you explain which case you had in mind?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk