Zero This

[tsdnz]

It is much worse than that.

Once the object has been constructed, that means all the member constructors have been run as well.

Then he just slaps zeroes on top of it all.

When the object goes out of scope, the destructors will run, assuming well-formed member instances.

This is desaster waiting to happen. It might work for the POD type he is working with now, but as soon as any of his constructors do any significant work, it will blow up.

Init() and memset() are the very things C++ objects were meant to REPLACE....

I see what you are saying, the classes with ZeroThis in the Init are not static / stack variables, or variables in another class.
They are only created using memory allocation directly.

None of the classes will go out of scope, no destructors are ever called.

But yes, very good points, terrible way of doing it.
How would you automatically zero all the properties in a class?
Or how would you automatically add 0xDEADBEEF?

Ali

[gerryg400]

... the classes with ZeroThis in the Init are not static / stack variables, or variables in another class.
They are only created using memory allocation directly.

None of the classes will go out of scope, no destructors are ever called.

But yes, very good points, terrible way of doing it.
How would you automatically zero all the properties in a class?
Or how would you automatically add 0xDEADBEEF?

Heed Solar's advice. It is vitally important because I see in another thread you are inviting others to work on this code. Most experienced engineers will steer clear of junk code because that undefined behaviour will affect their ability to do a good job.

How do you enforce that instances of classes with ZeroThis are not static or created on the stack or contained in another class ?

What do you mean by 'automatically'?

If you want to zero the members of a class then assign zero to each of its members.
If you want to write some pattern to the underlying memory (presumably to perform some sort of run-time checks) then you need to modify your memory allocator. That pattern will be set in memory before the class is constructed.

[Solar]

But yes, very good points, terrible way of doing it.

To make certain you understand the scope of it: I am working C++ professionally for 15 years now, specializing in maintenance (cleanup) coding. Between this and the macro abuse, I wouldn't touch your codebase with prongs. In a hazmat suit. Remote-conrolled.

Or rather, I would immediately apply some very rough global search and replace on it and see what I could salvage...

No offense intended. We all did things non-idiomatically at some point.

How would you automatically zero all the properties in a class?

By writing appropriate default constructors for object members, and writing zero initializer lists for POD types. If I had the need for it, which I don't, because that's the point where I would be assigning them "real" values anyway. (If you don't know the "real" value yet, chances are you shouldn't be creating the object at this point. RAII and all that.)

[alexfru]

But yes, very good points, terrible way of doing it.

To make certain you understand the scope of it: I am working C++ professionally for 15 years now, specializing in maintenance (cleanup) coding. Between this and the macro abuse, I wouldn't touch your codebase with prongs. In a hazmat suit. Remote-conrolled.

Or rather, I would immediately apply some very rough global search and replace on it and see what I could salvage...

Well, some may argue that if crappy code can attract money, then who cares, you take the money and then you have several options: quitting, cleaning it up yourself (you still get paid to do it) or hiring people to do it. Not that I'm arguing for it, but it's a common way of doing things. You know, trying to make a prototype/demo into a real product.

[Schol-R-LEA]

OK, I see from some of the other threads you are using the Cygwin port of gcc and binutils, but when you got the disassembly from objdump, you used the intel syntax switch. That answers my other question, I guess, though it probably isn't relevant given what Solar said.

[tsdnz]

To make certain you understand the scope of it: I am working C++ professionally for 15 years now, specializing in maintenance (cleanup) coding. Between this and the macro abuse, I wouldn't touch your codebase with prongs. In a hazmat suit. Remote-conrolled.

Nice response, very funny.

Everyone: Many thanks for all the responses.
I have cleaned the code, the comments got me to thinking about other people having to read/understand the code if needed.
I had been meaning to change the code at some point and with the current bug I had I decided to clean it all up.
No ZeroThis, etc..
All done inside constructors.
I can now guarantee all classes can be constructed and destructed.
It was an easy change, and fun.

The bug I had was the stack starting at 0x....0, I assumed, wrongly, that the stack needs to start at 0x...0, it needed to start at 0x...8.
Easy to figure out once I found the offending instruction. movdqa XMMWORD PTR [rsp],xmm0
It was a great find as this would have crashed the Userspace as well as I aligned the stack as above, now all changed....

My use/abuse of macros, I find them easy and fast to use, for example Forn, FIL, etc.
Why is this a bad use of macros?

Code: Select all

#define ForAll(Var, To) for (DWORD Var = 0; Var < (To); Var++)
#define Fori(To) ForAll(i, (To))
#define Forn(To) ForAll(n, (To))
#define Forc(To) ForAll(c, (To))
#define Fore(To) ForAll(e, (To))
#define Forz(To) ForAll(z, (To))
#define Forx(To) ForAll(x, (To))
#define Fory(To) ForAll(y, (To))

It is great to be able to discuss ideas on this site, absolutely awesome!!

Ali

[Solar]

My use/abuse of macros, I find them easy and fast to use, for example Forn, FIL, etc.
Why is this a bad use of macros?

Oh, where to begin?

• There is little tangible benefit to the construct except for (perhaps, marginally) marginally quicker typing.
• Every C programmer has used the for loop thousands of times before he comes across your code base. He knows the implications, intricacies, and caveats of that construct. ForAll(), on the other hand, is a completely new concept to him; kind of like tsdnz-C. Every time he comes across it, he has to stop, check the implementation, and mentally translate it, until it becomes second nature to him. Once it does become second-nature, he will be uncomfortable when he has to return to standard C, i.e. everywhere else but your codebase. (Readability trumps typing speed.)
• Initializing the loop counter in the loop itself is a C99 construct, not downward compatible. (Minor issue, agreed.)
• You are using a non-standard type for the loop counter. (Another minor issue.)
• You hide the type of the loop counter, and enforce a specific type. I might be facing signed / unsigned comparison warnings in the loop body, or encounter unexpected range limitations.
• CamelCase is something not encountered in standard C. for_all() might have been marginally more acceptable.
• Your macro is only good for 0..(To-1) loops. I will be using a different syntax for any other kind of loop (inconsistency == bad).
• The in-loop declaration of the loop counter makes it impossible to access the counter after the loop, which can be helpful at times. Again, I will be using a different syntax for that kind of loop (inconsistency == bad).
• ForAll( i, n ) is implicitly declaring the explicitly-named variable i. This is non-idiomatic C. A declaration is <type> <identifier>.
• Fori( To ) is even worse, because it is hiding the existence of the i declaration. If I declare another i in the loop, I am facing compilation errors that will be rather confusing. First-time readers will be confused where that i is coming from that I am using in the loop.

I could probably come up with more, but the above should be sufficient. Macros are for those situations where you cannot really achieve something without them. Using them for tweaking the syntax of the language is generally considered bad style.

[tsdnz]

Cheers, completely understand where you are coming from.

My use/abuse of macros, I find them easy and fast to use, for example Forn, FIL, etc.
Why is this a bad use of macros?

Oh, where to begin?

• There is little tangible benefit to the construct except for (perhaps, marginally) marginally quicker typing.
• Every C programmer has used the for loop thousands of times before he comes across your code base. He knows the implications, intricacies, and caveats of that construct. ForAll(), on the other hand, is a completely new concept to him; kind of like tsdnz-C. Every time he comes across it, he has to stop, check the implementation, and mentally translate it, until it becomes second nature to him. Once it does become second-nature, he will be uncomfortable when he has to return to standard C, i.e. everywhere else but your codebase. (Readability trumps typing speed.)
• Initializing the loop counter in the loop itself is a C99 construct, not downward compatible. (Minor issue, agreed.)
• You are using a non-standard type for the loop counter. (Another minor issue.)
• You hide the type of the loop counter, and enforce a specific type. I might be facing signed / unsigned comparison warnings in the loop body, or encounter unexpected range limitations.
• CamelCase is something not encountered in standard C. for_all() might have been marginally more acceptable.
• Your macro is only good for 0..(To-1) loops. I will be using a different syntax for any other kind of loop (inconsistency == bad).
• The in-loop declaration of the loop counter makes it impossible to access the counter after the loop, which can be helpful at times. Again, I will be using a different syntax for that kind of loop (inconsistency == bad).
• ForAll( i, n ) is implicitly declaring the explicitly-named variable i. This is non-idiomatic C. A declaration is <type> <identifier>.
• Fori( To ) is even worse, because it is hiding the existence of the i declaration. If I declare another i in the loop, I am facing compilation errors that will be rather confusing. First-time readers will be confused where that i is coming from that I am using in the loop.

I could probably come up with more, but the above should be sufficient. Macros are for those situations where you cannot really achieve something without them. Using them for tweaking the syntax of the language is generally considered bad style.