Recurring C++ and Qt anti-patterns
-
yeah...referencing "this" in the delegated call is bad juju...I still prefer tools that "allow" me to shoot myself in the foot thought.
Here's one that gets people in trouble when they start parsing network buffers.
uint8_t buffer[] = { 0x45, 0x00, 0x12, 0x34, 0x00, 0x00, 0xf3, 0xbb, 0xff, 0x65}; int i = *(int*)&buffer[2]; // bonus if you understand the potential problem...and I don't mean use of C-style casts as opposed to C++ caststhe correct way is either a pragma pack(1) union of the buffer array and a struct containing the interesting elements, or the following:
uint8_t buffer[] = { 0x45, 0x00, 0x12, 0x34, 0x00, 0x00, 0xf3, 0xbb, 0xff, 0x65}; int i=0; memcpy(&i, &buffer[2], sizeof(int)); -
yeah...referencing "this" in the delegated call is bad juju...I still prefer tools that "allow" me to shoot myself in the foot thought.
Here's one that gets people in trouble when they start parsing network buffers.
uint8_t buffer[] = { 0x45, 0x00, 0x12, 0x34, 0x00, 0x00, 0xf3, 0xbb, 0xff, 0x65}; int i = *(int*)&buffer[2]; // bonus if you understand the potential problem...and I don't mean use of C-style casts as opposed to C++ caststhe correct way is either a pragma pack(1) union of the buffer array and a struct containing the interesting elements, or the following:
uint8_t buffer[] = { 0x45, 0x00, 0x12, 0x34, 0x00, 0x00, 0xf3, 0xbb, 0xff, 0x65}; int i=0; memcpy(&i, &buffer[2], sizeof(int));@Kent-Dorfman said in Recurring C++ and Qt anti-patterns:
the correct way is either a pragma pack(1) union of the buffer array and a struct containing the interesting elements
That has a plethora of problems itself. The standard dictates that reading one field and writing another in a union is undefined behaviour. (although compilers implement it correctly).
or the following:
That's the proper way to do it, in my opinion.
-
@kshegunov said in Recurring C++ and Qt anti-patterns:
That has a plethora of problems itself. The standard dictates that reading one field and writing another in a union is undefined behaviour. (although compilers implement it correctly).
Actually, that's kind of news to me. I'd love to see the spec section that defines it as undefined, as that seems to negate the purpose of unions...so I'd hope that compilers implement it correctly. C? C++? or both?
-
@kshegunov said in Recurring C++ and Qt anti-patterns:
That has a plethora of problems itself. The standard dictates that reading one field and writing another in a union is undefined behaviour. (although compilers implement it correctly).
Actually, that's kind of news to me. I'd love to see the spec section that defines it as undefined, as that seems to negate the purpose of unions...so I'd hope that compilers implement it correctly. C? C++? or both?
@Kent-Dorfman said in Recurring C++ and Qt anti-patterns:
so I'd hope that compilers implement it correctly. C? C++?
No I was talking about the C++ standard. C99 and C11 are both adamant that it is well defined and does what you'd expect (which thankfully every cpp compiler I've worked with also does, but the cpp standard doesn't make such a provision).
Actually, that's kind of news to me. I'd love to see the spec section that defines it as undefined, as that seems to negate the purpose of unions...
Here's a decent answer:
https://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior -
@fcarney said in Recurring C++ and Qt anti-patterns:
Why doesn't delete set the pointer to null then? That seems like it may be an antipattern in and of itself.
I have indeed asked that myself. If someone has the correct answer for that, I'm all ears.
https://isocpp.org/wiki/faq/freestore-mgmt#delete-zero this might answer you question.
