"He, who sacrifices freedom for the sake of security, deserves neither."
- Benjamin Franklin
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 130 131 132 133 134 135 136 137 138 139 140 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438
Query FailedRichard S
Saturday, June 19, 2010

If you use custom memory pools (i.e. allocate all memory at startup, partition into your own system-specific pools, and allocate from there with custom allocators), the best way I've seen is to initialize all memory to known values at startup. That way you don't have to care about per-allocation overhead of the memory fill. Depending on your needs, you can re-fill on free also.

If you go with a different fill value per user, you can often catch some of the more nasty bugs quite easily - it's really simple to base the fill value off of the username (first byte, first 4 bytes, whatever); add USERNAME=$(USERNAME) to the Additional Defines settings for the project.
This helps as a bug may be 100% reproducible on only one member of the teams build, and if looking at the memory you see their username, it makes it really clear what the problem is.
dooz
Saturday, June 19, 2010

We had a very related problem in a game I worked on; vectors weren't been properly initialized before being used (and we had a design decision to not have the default ctor init x, y, z to 0), and this could lead to both obvious and very subtle bugs.

We solved this by turning on floating point exceptions, and having a debug build ctor initialize the values to NaN, so if you tried to perform math on an uninitialized value, an exception was thrown. Kinda cool, and it helped alot.
Arseny Kapoulkine
Friday, June 18, 2010

Sorry for the accidental double-post, I hate F5 form resending

Yep, if you have virtual functions, initializing the whole class is a bad thing. However, the same can be said about members with virtual functions - i.e. you have to be careful when deciding what variables are ok to garbage-init. If you're going through this, you might as well, uh, initialize them in the ctor.

Anyway, I'm glad it works for you.
Arseny Kapoulkine
Friday, June 18, 2010

There is one thing about class layouts that drives me crazy. And this is changing your memory layout between builds. This leads to all sorts of weird "unreproducible" bugs.

Some compilers (gcc) allow you to declare a zero-size array member, though that's not portable.

Anyway, why do you need those markers? If that's a debugging feature, just work on the whole class.
Sascha
Friday, June 18, 2010

A very good freeware tool is Cppcheck. According to the documentation, it should also check for uninitialized variables.

http://sourceforge.net/projects/cppcheck
MaciejS
Friday, June 18, 2010

FWIW, we're using Lint and it detects those cases quite nicely.
Humus
Friday, June 18, 2010

Arseny Kapoulkine, working on the whole class is less flexible, plus probably not portable. The v-table is included in sizeof() and you don't want to touch that. Also, you include all of deriving classes as well, which you really don't want to overwrite.

Mike, in-place new is common in game code. Also, you have to overhead of initializing the memory.

sqrt[-1], good stuff, I'll look into those tools.
Humus
Friday, June 18, 2010

fmoreira, yes, false positives are possible, although rare. Those can be special cased. I suppose a FAKE_INIT(m_MyBAADCODE_var) before the verify call should work.
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 130 131 132 133 134 135 136 137 138 139 140 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438