Declare object without initializing

Can I declare an object variable without initializing it? This is mostly a scope problem:

Code:

---

int main () {
      SomeObj eg;  // but this is an initialization ...
      try {
            eg(blah blah);    // so this is pointless
      }

---

If I move the declaration into the try block, it is not in main's scope. I know I can do this:

Code:

---

int main () {
      SomeObj *eg; 
      try {
            eg = new SomeObj(blah blah);
      }

---

But now I am using a pointer when I don't need to; also it's my understanding that if you use new, you then need to explicitly use delete.

Kind of a hassle, is there any way out?

A declaration of a variable of class type will always initialise the object by invoking a class constructor. If that initialisation fails, an exception will be (or should be) thrown. An exception causes the stack to be unwound - until a scope is reached where, effectively, that object has never existed.

Code:

---

int main()
{
    SomeObj example;

      example.something();  //  this line will not be reached if construction of example fails
}

---

If you're worried about example.something(); being called if construction of example fails, then don't. The standard guarantees it will not happen - assuming the constructor throws an exception if the object cannot be constructed in a valid state.

Code:

---

int main () {
      SomeObj* egPtr;.
      try {
         
          SomeObj eg(blah blah);
          egPtr = ⪚
      }

---

Can't you do sth like the above? You initialize the object where you want it to be initialized and you use a pointer for it to be in the scope you want it.

You are not using a pointer when you don't need to. Instead of using eg, you use egPtr. Meaning that outside the try only egPtr is available.

EDIT: Sorry was in a hurry. The above obviously won't work...

An object will always be initialized when you declare it. Why do you want to avoid that? More info please.

I want to avoid it so I can do a try/catch on the initialization, without having to resort to a pointer for a local variable.

Since a variable declared in a scope ceases to exist outside that scope, this can do what you want

Code:

---

int main()
{
    try
    {

        SomeObj eg;

          do_something(eg);
    }
    catch (WhateverExceptionThrownIfConstructorFails &)
    {
        // handle a failed construction
    }
    catch (...)
    {
        // handle any other exceptions
    }
}

---

More broadly, good practice with exceptions, usually involves minimising the number of try/catch blocks. Having one for a single operation tends to make the software, as a whole, hard to maintain.

Quote:

---

SomeObj *eg;

---

Even in this instance I would prefer to initialize the pointer to 0.

Quote:

---

Originally Posted by MK27

I want to avoid it so I can do a try/catch on the initialization, without having to resort to a pointer for a local variable.

---

So put the declaration inside the try-catch block. Use grumpy's code.

Quote:

---

Originally Posted by MK27

If I move the declaration into the try block, it is not in main's scope. I know I can do this:

Code:

---

int main () {
      SomeObj *eg; 
      try {
            eg = new SomeObj(blah blah);
      }

---

But now I am using a pointer when I don't need to; also it's my understanding that if you use new, you then need to explicitly use delete.

---

You do need a pointer here, because if construction fails, you would not have a valid object to work with. So you need a pointer than can be set to null.

Better to use code like grumpy. Then whatever uses the object will not have to worry about dealing with an invalid object.

Quote:

---

Better to use code like grumpy. Then whatever uses the object will not have to worry about dealing with an invalid object

---

This can also be accomplished without the try catch block if you only do operations in a constructor that are guaranteed to never fail. What if if someone wanted to declare a SomeObj instance on the stack in a class?

Code:

---

class Foo
{
    public:

    private:
      SomeObj m_someObj;
};

---

That's not what the question was about, Bubba. The question concerned being able to catch exceptions thrown when constructing an object within a try block, but allow that object to be used after the try block. He wanted to be able to do this;

Code:

---

int main()
{
    try
    {
        SomeObj example;  // and no use of pointers here
    }
    catch (...)
    {
        recover();
    }

    // do things with example here
}

---

In other words, he wants an object local to a scope to remain usable after exiting that scope.

Quote:

---

Originally Posted by mustermeister

So put the declaration inside the try-catch block. Use grumpy's code.

---

Okay, well the whole reason I started this thread was because the first (and so far, only) time I tried that I get an error:

Code:

---

int main() {
        try {
                OATserver valis(666, 1, "oatsv.log");
        }
        catch (int err) {
                cerr << "OATserver FAIL -> ";
                switch (err) {
                        case (SOCKERR):
                                perror("Socket: ");
                                break;
                        case (BINDERR):
                                perror("Bind: ");
                                break;
                        case (LISTENERR):
                                perror("Listen: ");
                                break;
                        default:
                                cerr << "??????\n";
                }
        }

        struct sockaddr_in in;

        valis.acptlist.push_back("127.0.0.1");
        valis.waitOnCall(&in);

        return 0;
}

---

server.cpp: In function ‘int main()’:
server.cpp:92: error: ‘valis’ was not declared in this scope

Is this some nuance here that will make this work? It seems very silly to me (altho it is normal scoping, wouldn't it be nice if try "returned" it's variables on sucess?), I am glad to hear it is not supposed to be that way.

If you read grumpy's example in post #6, you should be able to see that this can work:

Code:

---

int main() {
    try {
        OATserver valis(666, 1, "oatsv.log");

        struct sockaddr_in in;

        valis.acptlist.push_back("127.0.0.1");
        valis.waitOnCall(&in);
    }
    catch (int err) {
        cerr << "OATserver FAIL -> ";
        switch (err) {
            case (SOCKERR):
                perror("Socket: ");
                break;
            case (BINDERR):
                perror("Bind: ");
                break;
            case (LISTENERR):
                perror("Listen: ");
                break;
            default:
                cerr << "??????\n";
        }
    }

    return 0;
}

---

Quote:

---

Originally Posted by Bubba

This can also be accomplished without the try catch block if you only do operations in a constructor that are guaranteed to never fail. What if if someone wanted to declare a SomeObj instance on the stack in a class?

---

Good point, and I had been thinking to just use an empty constructor* and then a separate init() function. But I don't think that should be necessary, and the reading I've done explicitly stated that part of the purpose of exceptions was for constructors, since constructors cannot return a value, making normal error checking awkward (tho there are other simple ways around that).

*It is hard to meaningfully "construct" an inet server object that does not involve some operations that cannot be guaranteed not to fail.

Quote:

---

Originally Posted by laserlight

If you read grumpy's example in post #6, you should be able to see that this can work:

---

Well of course it will :p So am I suppose to keep all of main inside the try block then?

Quote:

---

Originally Posted by MK27

So am I suppose to keep all of main inside the try block then?

---

At least all of the code in the global main function that uses valis, I suppose.

Yes, laserlight is right. Use her code. Your mistake was double: You used the var valis outside of its scope AND you used it after it had failed to construct! It's all right, however, to have critical code in the constructor. After all, a net connection object is useless if the connection fails. Bubba's objection is not valid: You CAN have such an object as a member element too. It is constructed when the containing class C is, and if the member fails to construct so should C. You must catch an exception from trying to instantiate C.

Quote:

---

Originally Posted by MK27

Okay, well the whole reason I started this thread was because the first (and so far, only) time I tried that I get an error:

Code:

---

int main() {
        try {
                OATserver valis(666, 1, "oatsv.log");
        }
        catch (int err) {
                cerr << "OATserver FAIL -> ";
                switch (err) {
                        case (SOCKERR):
                                perror("Socket: ");
                                break;
                        case (BINDERR):
                                perror("Bind: ");
                                break;
                        case (LISTENERR):
                                perror("Listen: ");
                                break;
                        default:
                                cerr << "??????\n";
                }
        }

        struct sockaddr_in in;

        valis.acptlist.push_back("127.0.0.1");
        valis.waitOnCall(&in);

        return 0;
}

---

server.cpp: In function ‘int main()’:
server.cpp:92: error: ‘valis’ was not declared in this scope

Is this some nuance here that will make this work? It seems very silly to me (altho it is normal scoping, wouldn't it be nice if try "returned" it's variables on sucess?), I am glad to hear it is not supposed to be that way.

---

Like I said, how are you supposed to use valis if construction failed? This would invariably lead to a bug. The pointer solution has the same problem. You can only use valis if construction succeeds, so it is a good thing that the language won't let you use it when it might not have.

MK27, it looks like you might be falling into the trap that some C to C++ learners fall into, in that they make lots of local exception catchers around just the one line that fails. This is the opposite of the ideal situation.
What you need to do is to catch the exception as late or high up as possible.

Quote:

---

Originally Posted by King Mir

Like I said, how are you supposed to use valis if construction failed? This would invariably lead to a bug. The pointer solution has the same problem. You can only use valis if construction succeeds, so it is a good thing that the language won't let you use it when it might not have.

---

Yes, that was the complete program in finished form right there :p

The intent was primarily to identify the exact error. The runtime reporting (on my system) for an uncaught exception is totally uninformative. It just says "int thrown". Which int? As you can see, there are three possibilities. To identify the error, I need to catch it.

The reason I highlighted "You can only use valis if construction succeeds" is because that's not true. You can't use it even if it succeeds, because it goes out of scope with the try block.

The other situation where I find this irritating is in class definition:

Code:

---

class whatever {
    SomeClass SomeObj;

---

if "SomeObj" requires initialization inside "whatever"s constructor, then it need to be a pointer now too! Why not allow an object to be declared uninitialized? This must be a very common scenario (class members that are objects requiring initialization in the constructor).

I'd write Bjarne a letter explaining how daft he is, but I imagine he is not so daft and this is just impossible to implement for one reason or another, because everyone must have been aware of it for a long time.

Quote:

---

Originally Posted by MK27

The reason I highlighted "You can only use valis if construction succeeds" is because that's not true. You can't use it even if it succeeds, because it goes out of scope with the try block.

---

It is true because you can use it in the try block.

Quote:

---

Originally Posted by MK27

if "SomeObj" requires initialization inside "whatever"s constructor, then it need to be a pointer now too! Why not allow an object to be declared uninitialized? This must be a very common scenario (class members that are objects requiring initialization in the constructor).

---

You would just use the constructor initialisation list to invoke the member variable's appropriate constructor.

If you really want, you can design the class to use two stage construction, i.e., the constructor does not initialise the object, rather, an initialisation function is provided for the task. But this means that it is possible to have objects with invalid state, and this can be Bad Thing.

Quote:

---

Originally Posted by laserlight

You would just use the constructor initialisation list to invoke the member variable's appropriate constructor.

---

That's not inside the constructor, eg, for example: the member object is optional and may throw it's own exception, which you want to catch in the constructor. I just noticed you can do that (use try) in the initialization list, but I'm guessing there are some things you can't do.

In the end I did go with two stage construction (the first stage is not empty, it sets a local "errno" which is examined by the second stage before execution proceeds).

As for the member pointer, here's the actual situation: It's optional based on a parameter. I haven't tried yet because I'm not sure how it should look, but can you put an if/else block in an initialization list? Eg, if the param is NULL, I don't want to initialize the object at all -- but I'm guessing "an uninitialized object" cannot exist in C++, just an initialized pointer? This is not a big deal, just want to make sure I am not giving up too soon or missing something.

Quote:

---

Originally Posted by MK27

That's not inside the constructor, eg, for example: the member object is optional and may throw it's own exception, which you want to catch in the constructor.

---

If the member is optional then it makes sense for the member to be a pointer.

Quote:

---

Originally Posted by MK27

I just noticed you can do that (use try) in the initialization list, but I'm guessing there are some things you can't do.

---

Read GotW #66: Constructor Failures.

Quote:

---

Originally Posted by MK27

In the end I did go with two stage construction (the first stage is not empty, it sets a local "errno" which is examined by the second stage).

---

So you are not satisfied with the solution that involves just writing the code in the try block? That is one of the reasons to use exceptions in the first place, i.e., the normal flow of control can be written normally, with exceptions handled further down.

Quote:

---

Originally Posted by MK27

As for the member pointer, here's the actual situation: It's optional based on a parameter. I haven't tried yet because I'm not sure how it should look, but can you put an if/else block in an initialization list?

---

No, but for this you can use the constructor body.

Quote:

---

Originally Posted by laserlight

If you really want, you can design the class to use two stage construction, i.e., the constructor does not initialise the object, rather, an initialisation function is provided for the task. But this means that it is possible to have objects with invalid state, and this can be Bad Thing.

---

I believe you are wrong. You cannot avoid constructing members when the container is constructed. If you don't do so explicitly in the initializer list, the default constructors will be called. This goes for member objects as well as base classes.

Quote:

---

Originally Posted by mustermeister

I believe you are wrong. You cannot avoid constructing members when the container is constructed.

---

I am right, because I talked about avoiding initialisation, not construction. If you can arrange to use members whose constructors do not initialise them (or initialise them to a known invalid state), then you can do two stage construction.

Quote:

---

Originally Posted by laserlight

So you are not satisfied with the solution that involves just writing the code in the try block? That is one of the reasons to use exceptions in the first place, i.e., the normal flow of control can be written normally, with exceptions handled further down.

---

Nah -- the whole program is about the valis object, I'm not putting it all into a try block. I suppose a try is not really needed, the program has to fail anyway. Except that it does allow the exception to be identified -- without a try/catch it says nothing beyond the fact that "an exception occurred".

Maybe this is actually an inappropriate use of exceptions -- it is easy enough to use an errno type variable or some some check() function to make sure the initialized object is in good working order (in fact I took all the exceptions out and had the init() func return a value for error checking).

I'm also guessing they are for use in libraries and such so that the onus is put on the user: if you don't do error checking in the form of try/catch, then your program will just fail (rather than providing error reporting which can be ignored or left unchecked).

Quote:

---

No, but for this you can use the constructor body.

---

Ie, a member pointer. So definitely: no such thing as an uninitialized object in C++?

Quote:

---

Originally Posted by MK27

That's not inside the constructor, eg, for example: the member object is optional and may throw it's own exception, which you want to catch in the constructor. I just noticed you can do that (use try) in the initialization list, but I'm guessing there are some things you can't do.

---

You CAN'T catch an exception from a member object IN the constructor. It seems permitted to do so in the initializer list, but that's terribly bad programming practice. Never do so! You don't WANT to do it, because the construction of the container SHOULD fail when the construction of some member does.

Quote:

---

Originally Posted by MK27

Nah -- the whole program is about the valis object. So a try is not really needed, the program has to fail anyway. Except that it does allow the exception to be identified -- without a try/catch it says nothing beyond the fact that "an exception occurred".

---

I do not understand: what is the point of your program?

Quote:

---

Originally Posted by MK27

Maybe this is actually an pointless use of exceptions -- it is easy enough to use an errno type variable or some some check() function to make sure the initialized object is in good working order.

---

This goes back to the debate between error codes and exceptions. It is easy enough to check, but a check might be forgotten. On the other hand, carelessness can also lead to a lack of exception safety.

Quote:

---

Originally Posted by MK27

Ie, a member pointer. So definitely: no such thing as an uninitialized object in C++?

---

There are, but the norm is to avoid them.

Quote:

---

Originally Posted by mustermeister

You CAN'T catch an exception from a member object IN the constructor. It seems permitted to do so in the initializer list, but that's terribly bad programming practice. Never do so! You don't WANT to do it, because the construction of the container SHOULD fail when the construction of some member does.

---

Not if the member object is unessential. As I said, in this case it's optional based on a parameter. If the construction fails, I can just leave the pointer null and the class method will function as if that option had not been selected in the first place.

Quote:

---

Originally Posted by laserlight

I do not understand: what is the point of your program?

---

Well, it's a server, one of a few variations which all use the same base class. So each such server program contains one server object providing the base functionality.

Quote:

---

Originally Posted by laserlight

I am right, because I talked about avoiding initialisation, not construction. If you can arrange to use members whose constructors do not initialise them (or initialise them to a known invalid state), then you can do two stage construction.

---

You're always free to do nothing in your constructors, in particular in your default ones, but that's bad programming practice and contrary to the spirit of the language. The reason why C++ has special member functions called constructors is - surprise, surprise! - to construct the object. Which means initializing it, to use oldfashioned terminology. When an object has been constructed it should be ready to use. Don't break the unwritten laws of the language.

Quote:

---

Originally Posted by MK27

Well, it's a server, one of a few variations which all use the same base class. So each such server program contains one server object providing the base functionality.

---

Right. Actually, now I see what you are getting at. The thing is, if an exception is thrown, it must be handled somewhere. This means that if an exception might be thrown you should have at least one set of try/catch in your program, e.g., in the main function.

Quote:

---

Originally Posted by mustermeister

You're always free to do nothing in your constructors, in particular in your default ones, but that's bad programming practice and contrary to the spirit of the language. The reason why C++ has special member functions called constructors is - surprise, surprise! - to construct the object. Which means initializing it, to use oldfashioned terminology. When an object has been constructed it should be ready to use. Don't break the unwritten laws of the language.

---

I agree. As I noted: "this means that it is possible to have objects with invalid state, and this can be Bad Thing."

Quote:

---

Originally Posted by MK27

Not if the member object is unessential. As I said, in this case it's optional based on a parameter. If the construction fails, I can just leave the pointer null and the class method will function as if that option had not been selected in the first place.

---

Strange thinking, MK. If you don't need it, why not leave it out in the first place?

Quote:

---

Originally Posted by mustermeister

You're always free to do nothing in your constructors, in particular in your default ones, but that's bad programming practice and contrary to the spirit of the language. The reason why C++ has special member functions called constructors is - surprise, surprise! - to construct the object. Which means initializing it, to use oldfashioned terminology. When an object has been constructed it should be ready to use. Don't break the unwritten laws of the language.

---

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.

Quote:

---

Originally Posted by mustermeister

Strange thinking, MK. If you don't need it, why not leave it out in the first place?

---

Specifically, in this case it's a log. You can start the server object with some logging enabled (of events which take place within the server class methods). But if you don't want those things logged, you don't enable logging. The logging is handled by a separate logger class, so the server class has a member object of it.

I suppose I could have written the logger class to do nothing when initialized, but then you fall into that other caveat (an object should be ready to use). So in fact it is initialized with a file name which it attempts to open append in the constructor (or it throws). If it is not going to be used, no log file is submitted to the server and the logger is never initialized.

Quote:

---

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.

---

No, an empty vector<string> is as good as any other vector<string>. Any function taking such an argument should work equally well whether empty or not.

It's not possible to make all abuse impossible/illegal. The compiler cannot stop you from writing programs that crash at run time.

Quote:

---

Originally Posted by MK27

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).

---

Note that there are other constructors for a vector that may make sense if it is immediately going to be sorted after construction. Furthermore, an empty vector is not in an invalid state, e.g., you can safely do:

Code:

---

std::vector<std::string> strings;
std::sort(strings.begin(), strings.end());

---

Quote:

---

Originally Posted by MK27

So in fact it is initialized with a file name which it attempts to open append in the constructor (or it throws). If it is not going to be used, no log file is submitted to the server and the logger is never initialized.

---

In my opinion, it makes sense to have a member (smart) pointer which you initialise to be a null pointer. In the constructor body, you check that say, the string provided is not an empty string, and if so you create the object and make the member pointer point to it. If an exception is thrown, you allow it to propagate from the constructor.

EDIT:
I have also thought of suggesting the option of a pointer parameter as it would facilitate polymorphism, e.g., the caller can provide a logger object of his/her choice that inherits from some abstract base logging class, or a null pointer, but this may be rather unnecessary.

Quote:

---

Originally Posted by MK27

Specifically, in this case it's a log. You can start the server object with some logging enabled (of events which take place within the server class methods). But if you don't want those things logged, you don't enable logging. The logging is handled by a separate logger class, so the server class has a member object of it.

I suppose I could have written the logger class to do nothing when initialized, but then you fall into that other caveat (an object should be ready to use). So in fact it is initialized with a file name which it attempts to open append in the constructor (or it throws). If it is not going to be used, no log file is submitted to the server and the logger is never initialized.

---

The contradiction here is that you say the logging is optional, but the log object is constructed unconditionally. You should only construct it when the option of logging has been chosen. A solution is to have a child server class WITH log object, while the mother has none. If logging is chosen, you create the child, other wise the mother. Another solution is to use a pointer to a log object instead of a log object.

I haven't read everything, but most of it, but I don't see one very obvious suggestion. It might not work in all cases, but generally:

Code:

---

ObjectType obj;
try {
  obj = ObjectType(param1, param2, ..., paramn);
}
...

---

Of course, that needs a copy constructor for the object, but it allows you to use the design you wish. Maybe it won't optimize the extra copy away though, but I think it might.
Of course, this might be problematic in classes that can't be copied. But most classes should be copyable. Otherwise you should just make a function and not use the constructor.

Quote:

---

Originally Posted by EVOEx

that needs a copy constructor for the object

---

That would use the copy assignment operator, not copy constructor. I guess that it is a variant of two stage construction.

Quote:

---

Originally Posted by mustermeister

The contradiction here is that you say the logging is optional, but the log object is constructed unconditionally.

---

No, it is not constructed at all if it is not required, which was why I wanted to know if you could have uninitialized objects in C++. There is nothing obviously wrong with the idea, but when in Rome...so I'm using a member pointer.

C++ is actually the 4th language I've done OOP in, and most of the others had dynamic typing, so eg in perl:

Code:

---

package WhatEver;  // a package is a class
our $logobj; 
sub new {  // the constructor
    $logobj = Logger->new();

---

So this allows $obj to be a public member of a WhatEver, but it is initialized inside the WhatEver constructor.*

It's a scoping problem, is all.

Quote:

---

Originally Posted by laserlight

In my opinion, it makes sense to have a member (smart) pointer

---

Okay, what's a "smart" pointer? I guess I can look this one up myself, but comments are always appreciated.

*Actually, $logobj could be initially declared as 0:

Code:

---

our $logobj = 0;

---

because of dynamic typing. Then later it is easy to check if logging is enabled or not:

Code:

---

if ($logobj)....

---

but you don't need dynamic typing in order to have an uninitialized object, I would think (altho of course in the perl example $logobj is not such a thing, that's what it would be if the typing were static).

Quote:

---

Originally Posted by MK27

Yes, that was the complete program in finished form right there :p

The intent was primarily to identify the exact error. The runtime reporting (on my system) for an uncaught exception is totally uninformative. It just says "int thrown". Which int? As you can see, there are three possibilities. To identify the error, I need to catch it.

The reason I highlighted "You can only use valis if construction succeeds" is because that's not true. You can't use it even if it succeeds, because it goes out of scope with the try block.

---

Right, the language makes it almost impossible to use an object that may not have been constructed. This is good. Your program as you have drafted has a big bug: you are trying to use valis (call acptlist and waitOnCall) when you might not have a valid valis object. The language stops you.

You can use valis in a context where is has surely been constructed, namely inside the try block.

Quote:

---

Originally Posted by MK27

Nah -- the whole program is about the valis object, I'm not putting it all into a try block. I suppose a try is not really needed, the program has to fail anyway. Except that it does allow the exception to be identified -- without a try/catch it says nothing beyond the fact that "an exception occurred".

---

What's wrong with the whole program being in a try block? It's a good practice. If an error occurs, you can log the error and return from main. You don't go on with the program trying to use an invalid object.

Quote:

---

Originally Posted by MK27

Okay, what's a "smart" pointer? I guess I can look this one up myself, but comments are always appreciated.

*Actually, $logobj could be initially declared as 0:

Code:

---

our $logobj = 0;

---

because of dynamic typing. Then later it is easy to check if logging is enabled or not:

Code:

---

if ($logobj)....

---

but you don't need dynamic typing in order to have an uninitialized object, I would think (altho of course in the perl example $logobj is not such a thing, that's what it would be if the typing were static).

---

This is a good use case for a (smart) pointer:

Code:

---

boost::scoped_ptr<Log> logobj = 0;
if(use_log)
  logobj = new Log();

//later
if(logobj)
  logobj->logthis("error");

---

A smart pointer is like a regular pointer, except you don't have to call delete. There's more to it, but you can look it up.

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.

Quote:

---

But this means that it is possible to have objects with invalid state, and this can be Bad Thing.

---

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.

Quote:

---

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.

Quote:

---

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

---

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.)

Quote:

---

My object that managed [...] thing to be cleaned up.

---

This sounds like a major failure of the design.

Let me see if I have this "correct".

1) You have an object (from now called D3DDM) managing ("ACDD" and other facilities) a Direct3D device.

2) You have an object (from now called D3DRS) managing ("ACDD" and other facilities) the rendering states of the device managed by D3DDM.

3) D3DDM has no knowledge of D3DRS. D3DRS has only the knowledge of D3DDM necessary to for the facilities relating to D3DDM to function correctly.

4) D3DDM is a singleton, or traditional global, implemented in such a way that the compiler or standard library destroys the object. (A global instance in a translation unit, a singleton using `atexit' to register a "free me" function, or some such facility.)

5) D3DRS is a singleton, or traditional global, implemented in such a way that the compiler or standard library destroys the object and requires, as a client of D3DDM, that D3DDM is "ready to go" during the use but not necessarily during construction. (A global instance in a translation unit, a singleton using `atexit' to register a "free me" function, or some such facility.)

Under the assumption that my understanding is correct, the only way I see this failing (at any point of execution) is that if both objects aren't treated as potentially uninitialized (not constructed) objects, a broken `atexit' (or similar) implementation, or badly designed objects. (If either objects isn't treated as a true singleton. If `atexit' doesn't apply the functions in reverse order they were registered. If any object managing, exporting, more than one "globally accessible facility with state" treats them as independent during creation but dependent during destruction.)

D3DRS, as an eventual client of D3DDM, must assume that D3DDM is in a valid state as long as D3DRS exists. D3DDM, if treated as a true singleton, must necessarily exist at least as long as its oldest client. I want more information about this.

Soma

ACDD: Allocation Construction Destruction Deallocation

Quote:

---

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.

---

Quote:

---

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.

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.

Undefined is undefined. Illegal is illegal.

Soma

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...

Quote:

---

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)

Quote:

---

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.

Quote:

---

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.

Quote:

---

If you define it that [...] questions like in the OP.

---

Unfortunately I've had enough beating my head against the wall, I guess you just have to continue that nonsense without me.

Quote:

---

The problem is that [...] since the compiler controls the order.

---

From my post:

Quote:

---

the only way I see this failing (at any point of execution) is [...] a broken `atexit' (or similar) implementation[...].

---

It is perfectly safe to rely on destructors for proper cleanup. For a singleton you only need to control when the destructors are called. This could be said to be the same as a "destroy" method and a separate destructor. I'm not going to argue with that beyond saying that, in a singleton, neither is a necessary, or valid, part of the public interface.

Quote:

---

Here is a good article on the issue at hand:

---

I have no interest of an article written about the implementation of singletons in C++ from before the standard was published. That said, he article has several errors and invalid techniques. (An example would be "double checked locking".)

Quote:

---

If they can fail your only [...] with problems.

---

This is true, but has nothing to do with singletons. Or, rather, the problem isn't innate to singletons.

Quote:

---

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.

---

And yet, since there is no standard ABI, a perfectly valid assumption. Even something as simple as a single option to the compiler during compilation of either the library or the client can break compatibility if not used during the compilation of both the library and the client. If you can't assume a compatible ABI you can't export any C++ object through the library. If you can assume a standard ABI, and the ABI allows "thread jumping", you can safely throw exceptions from library to client and back.

Quote:

---

Just because an object has [...] point is cleaned up.

---

There is nothing wrong with relying on constructors to do what they were designed to do. This is much the same as destructors. If you need to create an object with a constructor that can raise exceptions while "hampering" the exceptions, you only need to create a new instance of the object within a `try' block.

Using exception safe primitives like `std::auto_ptr<???>' is a good idea in general. I can't imagine why you are complaining about it.

Quote:

---

There are many times when [...] satisfactory in all cases.

---

There is always at least one less problem with constructors that a separate "init" method has: I must remember to call this separate "init" method. You say "You only need to clearly document that the "init" method must be called."? I say that you only need to clearly document that construction can fail and therefore may raise an exception.

I will never use an object directly that has a two stage "init" process. I always wrap it in a class that does this for me. I'm sure most C++ programmers would eventually.

Also, if an object has to be "100%" initialized for use, and this "initialization" requires many parameters, you can't get around these necessary parameters by separating their assignment into multiple functions. An "init" method doesn't save you from complexity of implementation; it only moves it around.

Soma

Quote:

---

It is perfectly safe to rely on destructors for proper cleanup. For a singleton you only need to control when the destructors are called. This could be said to be the same as a "destroy" method and a separate destructor. I'm not going to argue with that beyond saying that, in a singleton, neither is a necessary, or valid, part of the public interface.

---

We obviously do not see eye to eye here.

Quote:

---

I have no interest of an article written about the implementation of singletons in C++ from before the standard was published. That said, he article has several errors and invalid techniques. (An example would be "double checked locking".)

---

A few invalid techniques does not invalidate the entire text of the article.

Quote:

---

There is always at least one less problem with constructors that a separate "init" method has: I must remember to call this separate "init" method. You say "You only need to clearly document that the "init" method must be called."? I say that you only need to clearly document that construction can fail and therefore may raise an exception.

---

Which is not possible in all circumstances. Unfortunately when you develop on a platform developed by Microsoft they really do not care about the standard or what things should do. It is generally a bad idea to throw exception across a module boundary in Win32. Period. I do not know about other platforms or OS's or how they deal with the issue.

Quote:

---

And yet, since there is no standard ABI, a perfectly valid assumption.

---

An assumption that could be extremely costly later down the line. You must work within the confines of your target platform. Working against it won't do much good for anyone involved.
And what is an ABI?

Quote:

---

Also, if an object has to be "100%" initialized for use, and this "initialization" requires many parameters, you can't get around these necessary parameters by separating their assignment into multiple functions. An "init" method doesn't save you from complexity of implementation; it only moves it around.

---

I did not say it was not without it's faults. You are claiming it is an invalid approach and I am saying it is not as straightforward and simple as you make it out to be.

Quote:

---

This is true, but has nothing to do with singletons. Or, rather, the problem isn't innate to singletons.

---

I did not say it did. If you notice in my post I make this statement prior to what you have quoted.
But back to constructors and initialization:

Anyways I'm done arguing with you over this since there isn't a clear cut answer or a reason to continue. Do what you will but realize that not everything fits into nice little neat molds as you are claiming they do. I would invite you to think a bit before making all encompassing statements about a language that pretty much allows you to do anything you want even if it isn't the best idea in the world.

Quote:

---

A few invalid techniques does not invalidate the entire text of the article.

---

I offered you a mechanism that is guaranteed to work if you have a standard `atexit' and follow the trivial documentation of "Call the `get_singleton' method in the constructor of dependent objects.".

An article posing "While this obviates the need for destroyers, the real problem remains. Garbage collection, anyone?" just isn't interesting.

Quote:

---

And what is an ABI?

---

O_o

Quote:

---

Anyways I'm done arguing with you over this since there isn't a clear cut answer or a reason to continue.

---

Considering the above, that's probably for the best.

Quote:

---

Do what you will but realize that not everything fits into nice little neat molds as you are claiming they do.

---

^_^

You are the only person who said "nice" or "neat". I offered something that works. You are using something that obviously does not work. Hah! Congratulations on finding an implementation that isn't "nice", "neat", or functional.

Quote:

---

I would invite you to [...] best idea in the world.

---

Here is an example of why that comment was stupid: "Memory leaks are bad!", a statement falling into the "all encompassing" category and yet absolutely true even if that's what some bozo want's to do.

Soma

Quote:

---

And what is an ABI?

---

Quote:

---

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.

Quote:

---

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!

Quote:

---

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.

Quote:

---

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.