Thread: Declare object without initializing

Originally Posted by C_ntua

An uninitialized object does exist in C++. It just has an empty constructor. If that is what you want, then use that (along with an initialization function).

Where there's a will, there's a way.

It is possible to pre-allocate a buffer, where an object can later be constructed.

Originally Posted by phantomotap

If the constructor has not been called, the object does not exist. (It doesn't mean anything if you have a "do nothing" constructor and a secondary "init" method. Without the constructor, the "init" method doesn't exist as part of the object.) The existence of memory where an object may eventually reside doesn't advance the notion that you can have an "uninitialized" object. Using a punned pointer to an area in memory where an object, not a "built in", has not been constructed is undefined. (It has been a while. It may be truly illegal instead of just undefined.)

You seem to be arguing semantics, when my point was about function. Whether you call a preallocated block an uninitialized object or not, it does conceptually provide such an interpretation. Which goes to my larger point that C++ has no lack of power.

Undefined is illegal. It's the harshest criterion on runtime behavior in the standard.

Speak with some code cause I think you are just using different words for the same thing.
The point is that an uninitialized object can exist.

I have to say that someone can argue thought that the above is not true for an object statically allocated, but only for an object dynamically allocated. Because as initialization one could count allocation as well. Thus considering an object initialized when memory for all its member is allocated (w/o a specific value give).
In this case, MK27 has a point, and you could only achieve that with a pointer and dynamical allocation. And the whole problem is indeed a scope problem, since you lack the ability just to declare an object for scoping reasons. That could be possible, but don't know how useful...

Originally Posted by phantomotap

Function? An object doesn't exist until it is created. An object doesn't exist after it is destroyed. An object that has not been created can not be uninitialized because it doesn't ........ing exist. That is the functionality.

End of story.

If you define it that way, then it's semantics. And beside the point. Logically a buffer allocated for later construction is an uninitialized object. It's something someone can use to get the functionality they want when they ask questions like in the OP. (not that doing so is a good idea for the OP)

Undefined is undefined. Illegal is illegal.

Soma

I suppose then by illegal you mean the compiler is required to give an error diagnostic. This won't happen from trying to access a pre-allocated buffer, because doing so requires a reinterpret_cast, which is allowed.

Originally Posted by C_ntua

I have to say that someone can argue thought that the above is not true for an object statically allocated, but only for an object dynamically allocated. Because as initialization one could count allocation as well. Thus considering an object initialized when memory for all its member is allocated (w/o a specific value give).
In this case, MK27 has a point, and you could only achieve that with a pointer and dynamical allocation. And the whole problem is indeed a scope problem, since you lack the ability just to declare an object for scoping reasons. That could be possible, but don't know how useful...

No, you can pre-allocate a buffer on the heap, on the stack, or in global memory. It's useful for memory pools and things like std::vector. The buffer will generally have to be a char buffer if on the stack, but the size_t version of new returns a void * that can be used. Then placement new is used to call the constructor.

The problem is that when using the singleton pattern you cannot rely on destructors for proper cleanup if those singletons make use of other singletons or pointers to objects managed by other singletons for their operations. You can end up with dangling pointers and references quite easily during cleanup. This is because the order of cleanup is not guaranteed. To get around this you would implement a cleanup function that would be called prior to actual object destruction which would then allow your system to order the cleanup correctly. Most game design books recommend not relying on constructors for any init besides operations that cannot fail and recommend not relying on destructors for object cleanup b/c the order of cleanup becomes undefined to the programmer since the compiler controls the order.

Here is a good article on the issue at hand:
http://www.research.ibm.com/designpa...s/ph-jun96.txt

But back to constructors and initialization:
Essentially relying on constructors for initialization is ok given that none of the init operations can fail. If they can fail your only option is exceptions which work fine when handled correctly and propogated correctly but trying to throw exceptions across a module boundary is fraught with problems. It can be done given certain restrictions are met. However given the nature and design of DLLs is to act as units of logic, IE: libraries, that can be replaced long after the release of a product there is no guarantee that the restrictions are going to be met. Assuming the user of the DLL and the DLL are both compiled on the same compiler version is a huge assumption in most complex systems.

Just because an object has been created in memory does not guarantee it is ready for use unless you completely init the object in the constructor which means you may have to end up throwing a lot of exceptions from it and using std::auto_ptr or boost pointers to ensure memory allocated prior to the throw point is cleaned up. There are many times when objects may require a significant amount of setup prior to usage that may or may not be done in the constructor. Sometimes at the point of construction the object cannot be setup completely for usage or perhaps it is unwieldy to pass in a whole bunch of parameters to the constructor just to 100% init the object for use. Now in the constructor you can set pointers to 0, values to 0, etc, etc. which means the object has been properly constructed....but the pointers that are 0 cannot yet be used. They have just been init to 0 but they don't point at anything meaningful and b/c of this no function that relies on these pointers can be called. This is the 'invalid state' that has been talked about and it is definitely a problem with the two step approach. However complete init in the constructor is fraught with just as many problems so it's really a matter of picking your poison b/c neither approach is 100% satisfactory in all cases.

And what is an ABI?

O_o

At least I'm honest. I'm not going to act as if I know what you are talking about when I don't. Honestly I don't use that term or abbrev. often. I thought you might have meant API and made a typo.

But you are obviously only open to your own thoughts so I will leave you with them.

Originally Posted by MK27

I think it is an even worse idea to treat a general principle as a law. Yes, the reason there are special members called constructors is to construct the object, and obviously these work well in most cases, but there is also freedom to deal with things differently if appropriate.* And "ready to use" could mean a lot of things -- all of those meanings will be qualified "ready to use properly", as in, ready to use like this or like that, but "obviously I didn't mean used improperly". Eg, an empty vector<string> is not "ready to use" in sorting; you have to push some data into it first (after the constructor call).

* If the authors had intended that to be impossible, it would be.

I'd be careful with such sayings in C/C++. Obviously you can do really bad things™, and the language won't hinder you (eg throwing an exception in a destructor).
With C/C++, you have to remember that the languages gives you the gun, with the safety off! If you don't know how to use, you will eventually shoot yourself in the foot
The language won't stop you from doing that. It just provides you with the gun. The tools!

Originally Posted by C_ntua

An uninitialized object does exist in C++. It just has an empty constructor. If that is what you want, then use that (along with an initialization function).

What is the difference of doing

Code:

try {
  Object o;
....
}
o.val = 1;

rather than

Code:

Object o;
try {
   o.init();
....
}
o.val = 1;

just one line of code which is essential in the end to see in what scope the object o is. If the first example was valid then in order to find the type of o and where it is declared you would have to look in all try blocks. Which you can avoid the way the language is now. So you cannot have everything in the end.

Except now you've brought up the two-stage construction again, which laserlight pointed out is a double-edged sword.

Originally Posted by Bubba

For certain programming tasks it is not recommended to rely on constructors and destructors for initialization and destruction or cleanup. We all know the inherent problems with constructors operations failing and if you are inside of a DLL the problem only gets worse. When it comes to destruction the problem can be magnified if you are using singletons and the like. Yes, the compiler is guaranteed to call the destructor for your class, however, it does not guarantee the order in which the destructors for objects will be called which can cause problems in more complex systems that may rely on a certain destruction order. It would be nice if these could be avoided but unfortunately this is not a perfect world. One example of where I got burned by this:

My object that managed various D3D render states was a singleton which worked great....until shut down. At shut down the object managing the device would cleanup the device long before the singleton would get cleaned up. So even though the render state object would attempt to clean up correctly release had already been called on the device. At this point the device was in an invalid state and leaked every COM object that was allocated by the singleton object. Not good. Hard to avoid though since if the device is cleaned up before any other D3D COM allocations the allocations will be leaked. The device must be the last thing to be cleaned up.

The two stage setup/shutdown process IMO are perfectly valid approaches so long as it is well documented what is going on and as long as all objects in the system conform to the same creation/destruction specification. It is not without its own perils and the invalid state during construction argument is a perfectly valid argument against it.

I don't like relying on singletons at all (some do call it an anti-pattern, after all). After better yet, I like to avoid globals, because there is no way to tell when they're constructed and destructed. I like deterministic order, so I would define everything I could, in order, inside your main function and provide pointers/references to them.
Just a thought.