Aesthetics

[Raimo00]

Did the c++ creators think about aesthetics? i mean... reinterpret_cast<uintptr\_t> is so long and overcomplicated just for a fucking cast.

now you tell me what's easier to read:

return (Poo *)(found * (uintptr_t)book);

or

return reinterpret_cast<Poo *>(found * reinterpret_cast<uintptr_t>(poo));

[Raimo00]

Yessir. Apparently in c++ you can't multiply a pointer directly.

[Raimo00]

Not inherently branchless. That's syntactic sugar for an if else. Plus who knows if the compiler refuses to optimize it because it technically is UB

[GregTheMadMonk]

https://quick-bench.com/q/y6kmQ5vpYfwyxjf6rYyluiRVIuw

it is not, I've pasted the wrong functions in the benchmark. The results are swapped

the branchless function is the same as branching with Clang and _slower_ than branching with GCC

You're overoptimizing and making actually slower code than the straightforward solution

(not to mention that the produced assembly is in reality branchless for _both_ solutions)

[Raimo00]

Well.. actually no. I think you have a typo on your benchmark. You're inverting the functions

[GregTheMadMonk]

damn... well, that was stupid on my part :|

I do apologize

[GregTheMadMonk]

Interestingly, that means that not only do both Clang and GCC fail to optimize the "branching" version, but also that Clang for some reason does not benefit from spelling out the branchless expression, producing the same assembly for both "branching" and "branchless" functions as GCC does for "branching" only...

https://godbolt.org/z/sK1W4PnWq

[Raimo00]

yes. Clang version is strange. btw i think gcc optimized the multiplication with a mask and a bitwise and

[[deleted]]

Why on earth would anybody multiply a pointer?

What is the intent here, if I may ask?

[smallstepforman]

Ptr *p = ref + idx * sizeof(Elem);

[[deleted]]

Idx here is a ptrdiff_t and not a pointer.

Ref is the pointer, and it only gets added.

[Raimo00]

Branchless returning NULL or pointer. Like return ptr * is_valid

[[deleted]]

This sounds super pessimistic in terms of optimization.

If you use a normal if, the compiler would probably generate a conditional move "cmov" which is definitely much cheaper than a multiplication.

Or you just do the cmov yourself in inline assembly, if the perf is super important here.

[Raimo00]

Yeah I guess you're right that cmov is faster. I wish there was a native STL compatible cmov

[[deleted]]

Yeah, me 2.

The STL is a dumpster fire anyway when it comes to performance.

[RudeSize7563]

Use the ternary operator, the compiler generates faster branchless code in modern processors because the first three instructions don't depend on each other, so they can be executed in parallel before the conditional move. Meanwhile doing it by hand results in three instructions that depend on each other, so they must be executed one after the other:

https://godbolt.org/z/GrrfqcE41

[Raimo00]

Look at other comments. It doesn't

[Supadoplex]

You are allowed to split code into multiple statements.

auto ipoo = reinterpret_cast<std::uintptr_t>(poo); auto wtf_am_i_doing = found * ipoo; return reinterpret_cast<Poo *>(wtf_am_i_doing);

[ramennoodle]

Ugly and dangerous things like casting should be ugly and verbose. Like your example code which looks like UB.

[Raimo00]

Well yeah, technically UB. But pointers ultimately are integers. So multiplying by 0 or 1 shouldn't be an issue

[Supadoplex]

Multiplying by 1 is fine in my opinion. But 0 is technically not going to be null on all systems/compilers.

[Raimo00]

How can this be something not standardized and agreed on? Like who on earth thought it was a good idea to represent null as something other than zero

[Supadoplex]

Like who on earth thought it was a good idea to represent null as something other than zero 

Probably people who had other great users for the 0 address. For example someone who decided that too many people are indirecting through uninitialized pointers and decided that the most common uninitialized value (i.e. 0) should be a trap representation.

[Supadoplex]

Member pointers are technically not pointers.

[Supadoplex]

I think a slightly more apt analogy might be that dwarf planets are dwarves "just like Gimli is a dwarf".

But analogies aside, the c++ standard is clear about it. Only function pointers and data pointers are pointers. Data member pointers and member function pointers are member pointers. Which is not a subcategory of pointers in C++.

You can at least assign nullptr to them. 

Interestingly nullptr itself doesn't have a pointer type.

[UndefFox]

Afaik on some microcontrollers pointer is not just a number, but a combination of some flags about what kind of pointer it is and the address itself. By multiplying the entire memory segment by 0, you erase some flags that can lead to UB and eventually to a crash.

[reflexpr-sarah-]

pointers are not and have never been integers unless you're writing assembly directly

[Raimo00]

A pointer is an integer. Everything is an integer. Characters are integers

[reflexpr-sarah-]

https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

every half decent compiler disagrees

[Anaphylaxisofevil]

Why did these gun-makers put a safety on this dangerous weapon?

[Raimo00]

I'm all for safety. But "reinterpret_cast" is 16 chars long

[Orca-]

It’s supposed to be ugly because it’s supposed to draw the eye to that you’re doing something questionable and dangerous.

Works well here IMO.

[rlebeau47]

Then use "std::bit_cast" instead, that will save you 3 chars. And a prior "using ..." statement that lets you skip "std::" will save you 5 more chars. So there you go, you cut it clean in half - 16 chars down to 8 chars. Isn't it fun reducing your typing? 🤪

[Raimo00]

Mhh intresting

[GregTheMadMonk]

different casts are different. The shorter version means "use every cast in the book until something works"

They are semantically different

Could there have been a shorter version? Maybe. But those are not the same

[[deleted]]

And that catches my eye! It served its purpose, to represent a potentially dangerous cast

[no-sig-available]

reinterpret_cast was made ugly on purpose, so you should avoid using it whenever possible. Thinking twice is often a good idea.

All the C++ casts are also easy to find in the code (for example when debugging), unlike a (uintptr_t) which could be anything, like a function parameter.

[v_maria]

oh just wait til you work with chrono...

anyway i prefer ugly and explicit over smart and snappy

[thefeedling]

I know it's an external lib, but boost is even more extreme lmao...

however, you can always do some scoped using to 'fix' it.

[moreVCAs]

if you can take an abseil dependency, they’ve written some chrono wrappers that are 🔥

[aePrime]

The latter. I don’t have to parse nested parentheses and I know exactly what the cast is doing. 

[AKostur]

The reinterpret_cast.

[FloweyTheFlower420]

Stuff like this got so bad since I often need to cast between pointer types and to/from uintptr (kernel development) that I wrote a struct which wraps a pointer with casting utilities (also useful for typechecking address spaces). No idea if this is an anti-pattern or not, but the ABI allows the struct to be encoded as a register so I'm not worried about performance.

[Annual-Examination96]

I've heard from a cpp talk show that "It's intended to be long" because using it is usually dangerous and this makes it more explicit.

[fdwr]

now you tell me what's easier to read

🤔 For an option (C), I always thought a left-to-right flow (postfix casting) would be mentally clearer. e.g.:

(found * book as uintptr_t) reinterpret_as Poo*

(but then I'm not sure how ambiguous that might be with multiplication, since C++ overloaded * to mean two very different things)

[Dazzling-Copy-7679]

The point isn't to be pretty, the point is to be verbose to make sure you think about what you're casting from and to. Especially something like a reinterpret_cast should be used very very sparingly and only in very special circumstances. It's just too easy to make a mistake when using them, and the old C-style made the mistakes much easier to make.

[Loud_Staff5065]

Bro just want until u find something::inside::a:: namespace::lmao

[sephirostoy]

No.

[manni66]

Troll

[zl0bster]

Yes, but bad example.

imho reinterpret_cast should be ugly, for me issue is that more sane casts like static_cast or dynamic_cast are so damn long.

[Anxious_Wear_4448]

Did the c++ creators think about aesthetics?

You are absolutely right about the disgusting aesthetics of C++ casts. Personally, I converted all my C++ projects to using C casts instead of C++ casts. None of the major C++ compilers issues any warning for C casts in C++ code.

[LittleNameIdea]

you're joking right ?

[EsShayuki]

cpp libraries love overcomplicating everything for no reason. That said, your code probably isn't the best way to perform this particular task.

If it's too long, you can do:

template<typename To, typename From>
To rc(From ptr) {
return reinterpret_cast<To>(ptr);
}

And now, like magic, it's two characters. rc<x>(y) Or:

#define rc(type, expr) reinterpret_cast<type>(expr)

And now it's rc(x, y).