Re: replicating default constructor's "non-initializing state"
Jason Doucette wrote:
No, it's not my choice. I do *not want* to make a default constructor
myself. I want to keep the original default constructor that does no
initialization. But, C++ is forcing me to make my own.
You can write a do-nothing constructor, but even that will be heavier
than not having a constructor at all:
struct C
{
C() { }
...
This is the most lightweight solution you can do in C++ if you already
have another constructor. Of course the compiler might add some implicit
function calls to it. However, if your structure only contains POD
types, they will remain uninitialized. There's a good chance the
compiler can inline this for you, and remove the empty body.
Another solution to consider: simply don't write your own constructor at
all. Create a static function, or a non-member function to initialize
your data. Example:
struct Color
{
int r, g, b;
static Color Create(int ar, int ag, int ab)
{
Color c;
c.r = ar;
c.g = ag;
c.b = ab;
return c;
}
};
This has to perform two assignment operations for each member, though.
If performance is really so important for you, you might want to use a
less convenient method:
inline void InitColor(Color& c, int ar, int ag, int ab)
{
c.r = ar;
c.g = ag;
c.b = ab;
}
The compiler will likely inline this for you in release builds. And
there's always a possibility of using a macro (ouch!).
Otherwise my tip would be to avoid early optimizations, and optimize
only after doing some benchmarking. Did you know that calling malloc
just once can be a thousand times slower than initializing those
integers with 0? There is a possibility that you're trying to optimize
something that's not likely to be anywhere near the bottleneck.
Tom