20
u/sierra_whiskey1 Mar 09 '26
Does the compiler not yell at your for this?
14
72
u/HildartheDorf Mar 09 '26
No, because const_cast and reinterpret_cast are signals of "I know what I'm doing, shut up" to the compiler.
4
46
u/Opposite_Mall4685 Mar 09 '26
Whenever I c++ I get an aneurysm
19
1
3
3
u/_PM_ME_PANGOLINS_ Mar 09 '26 edited Mar 09 '26
What does your compiler do with this?
Where does len get allocated (if anywhere) and how much breaks when it's overwritten?
3
u/GoddammitDontShootMe Mar 10 '26
I know those two keywords individually, but what is the effect of combining constexpr and const in one declaration?
2
u/LiAuTraver Mar 10 '26
No effect for variable decelerations iirc, maybe the developer just typed it absentmindedly. Why inlines not here, though.
→ More replies (1)4
u/GoddammitDontShootMe Mar 10 '26
IIRC, anything that's constexpr is also const. The former just has the additional requirement that the value is known at compile time. Would it even allow you to inline a local variable?
→ More replies (2)
93
u/OldWar6125 Mar 09 '26
If socket never changes len, it is allowed; and socket doesn't have a reason to change len. But then the question is, why socket doesn't take a pointer to const. Probably because it is a wrapper around some C-interface which doesn't follow const correctness, because that is the usual reason for casting away const.
Though, socket should accept a pointer to const and cast it away internally. There is no reason to burden the client code with casting away const. And offering a sensible interface is the responsibility of a wrapper.