Jump to content
  • Advertisement
Sign in to follow this  
Lith

C++ Garbage Data

This topic is 2171 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Why are you adding _m after everything?!? it just make the code harder to read.
If you really like this notation you shoud at least put the m before, like this ---> m_particles, for example, but imo, this is better:

That's worse than what he's doing. A m_ prefix on everything messes up IDE/editor autocomplete features, whereas the _m postfix does not disturb the autocomplete, and will get autocompleted 95% of the time so you don't even have to type it out.
There's no one right way, but I have opted to use the Google style where class members are marked with a single postfix underscore (particles_). This doesn't hurt the readability, but still clearly distinguishes members from non-members. On simple classes with public data members, I omit the underscore so it's just Position p; p.x = 123;.

NIL? I suggest using NULL instead.

The correct choice in C++11 is nullptr, in C++98 0.

Share this post


Link to post
Share on other sites
Advertisement


the vector allocates memory in the "free store," which means your bug MAY still be there, and its not showing up (yet)

that is, unless there actually was something wrong with that simple array, which i highly doubt

honestly, i would go back to that array and investigate further

I agree - sweeping it under the carpet sure is tempting, but if you leave it, a memory overwrite bug will come back and bite you in the ass. Having a repeatable case to track and fix the problem is a good thing :)

Share this post


Link to post
Share on other sites

That's worse than what he's doing. A m_ prefix on everything messes up IDE/editor autocomplete features, whereas the _m postfix does not disturb the autocomplete, and will get autocompleted 95% of the time so you don't even have to type it out.

I have to say that's a really bad reason to change the naming of something. I use the m_whatever prefix and have never really had any problems with autocomplete. Not to mention it only affects member variables anyway.

Share this post


Link to post
Share on other sites

Indeed.  Autocomplete is the least of concerns when choosing your style.

“m_” as a prefix is fairly universal and easier for others to read, which is far more important if you plan to be a professional coder in a team environment in the future.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

Indeed.  Autocomplete is the least of concerns when choosing your style.

“m_” as a prefix is fairly universal and easier for others to read, which is far more important if you plan to be a professional coder in a team environment in the future.

 

 

L. Spiro

 

Agreed.

Anyway, if basing naming on auto-complete, you might as well also note that VS2012 has much smarter auto-completion that doesn't care so much what is at the beginning of your names.

 

The corruption bug is interesting... the only thing I can see is maybe you're not calling Weather::StartWeather before calling Weather::Update. Either way, your particles should be initialized in the Weather constructor... don't ever let it be in an invalid state - at the very least it narrows down the possibilities.

 

[edit] Nevermind they are initialized to default by being in a normal array. blink.png Forget I said anything.

Edited by achild

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!