On Tue, Feb 27, 2024 at 4:55 AM Dan Eble <nine.fierce.ball...@gmail.com>
wrote:

> On 2024-02-27 07:14, Luca Fascione wrote:
> > inline constexpr vsize VPOS (vsize(-1));
>
> OK, but don't repeat the type.
>
>      inline constexpr auto VPOS = vsize (-1);
>

Well. To that, yes and no. I read it better in the original way, and
repeating the type at a distance of less than 10 characters is ok IMO
(in that you obviously see it if/when you're changing the code, so parsing
the 'auto' is substantially more cognitive overhead than
reasoning about the type being there twice). Besides, depending on how good
code intelligence your editor has,
I want to see the type in the popup ballon describing VPOS at the usage
size, and finding 'auto' there will just make me frustrated.
In my school of thought auto should only be used where it's necessary (like
inside templates) or in places where the type declaration is so convoluted
that
reading it is not useful (like std::map<complex type, another complex
type>::const_reverse_iterator::value_type kinda things).


> Personally, I don't like flower's aliases related to vsize,
> ssize, and Real -- I'd rather just use standard names --
> but I remember that there was some resistance to changing
> them the last time I suggested it.
>

Redeclaring size_t is a thing of a very distant past, I've worked with APIs
that had declarations for int and float (and even void in one, yuck).
It's not a modern way of working, but if the thing is external you should
use types that match the API definitions, that'll make it easier
to keep your code correct when the typedefs move (like when you change
platform, the whole long vs long long thing on linux/windows is a complete
nightmare, for example)

I know that at the moment a native build on windows is not on the cards,
but it seems to me that
adding friction gratuitously is just an unwise thing to do.

But to me, if you have a variable that is intended to be passed as a
parameter to a thing that wants a foo_t,
even if you know that foo_t is a typedef for bar_t, your variable should be
declared as foo_t, you'll find bugs faster that way,
because you're pulling the detection of mismatched types closer to code you
can act upon.
L

-- 
Luca Fascione

Reply via email to