@fist-poster said:

@asuffield said:

int &a(void) {
  int b;
  return b;
}

int* a() {
  int b;
  return &b;
}

I  think once you have been told and understand why you shouldn't do this, that won't be a problem any more.

And if you've been told and still forget, no biggie as both of these examples produce easy to understand warnings from the compiler (I checked with gcc on linux and an MS one on 'doze), IMHO, being fastidious with compiler warnings is as important to program health as washing your hands after #2's is to your own health :)

To newbie, I've been doing C++ for 16yrs and you can 'carbon date' my source by looking at the ratio of * to &.  The earliest code (during my transition from C) is full of new/delete/*, over time I started to get sick of writing if(ptr!=NULL) {...} and ancillary activities like coding big3 functions (Cline/Lomow) to correctly handle my misguided desire to explicitly manage memory... slowly & started to creep into my function signatures, from then on it was smart pointers (thanks Scott Meyers), stl, and boost.  My latest code rarely has a new/delete/* and I virtually never have to think about memory management, heap corruption, pointer validity or any of that rubbish.... it just works and I can use my brain power solving the real problems.

@asuffield said:

Not for STL classes. The correct type for this function is std::list<T>::size_type

Fair point, I frequently use the value_type and iterator typedefs when writing templates that take STL container types as template parameters... totally forgot that size_type was in there too.

I'll admit to being a bit lazy on the size_type side of things though as all the STL implementations that I use (>1) have size_type typedef'd to size_t... if that laziness threatens to bite me though the compiler will tell me (I hope) and I'll switch to the technically correct but wordier form or use apropos typedefs to keep it brief/clear.

@seaturnip said:

you don't even know anything about the context.

And the proponents of casting knew more about the context?

@seaturnip said:

  There is a limit to perfectionism in code cleanliness, especially when it leads to painful cascades of changes.

Granted... and my wife is always complaining that I spend far too much time at the office and I have to admit that I do spend a fair amount of time grooming code.  OTOH, I do feel that my penchant for this (and the habit of using different compilers to help identify other potential problems) leads to code that works... the hours I spend up front making clean code is paid back by reduced problems later on and code that I'm happy to hand off to co-workers.

As for being painful... I did suggest that 'chipping' at the problem is a good approach... and once you are on top of it keeping it clean is not hard.

Don't even get me started on const-correctness :)

@bullestock said:

unsigned int NumProperties() const { return static_cast<unsigned int=""><unsigned int>(m_propList.size()); }</unsigned>

There, fixed it for you.

This answer surprises me.  IMHO the correct solution is:

  size_t NumProperties() const { return m_propList.size(); }

Which may of course trigger more 4267 at the function's call sites (and if it was a v-func, will require changing the base/sibling classes too but the compiler will give helpful warnings to guide you through that too).  While this sounds like a lot of work it will result in improved code quality and is not just a variation of covering the problem.

Chipping away at these warnings will put you in a good position when the time comes to throw the lever over to 64 bit and is grunt work that can be handed off to junior developers.  Plastering over these problems with pragmas and forms of casting (both old and new) just leaves something in the code that will be much harder to deal with later and will therefore require more expensive people to mop up.