another preference question....

[Howard Richards]

As Mrs Thatcher once said.. "No No No!"[^] If Init() is something that should always be performed on a class before being used then it should be part of/called by the constructor. It should only be called/callable by the outside 'user' if it's optional. What happens if the user forgets to call init? or clear? Why make them remember when you can encapsulate that behaviour. This is why we have encapsulation..! As for clear, same principle applies, or use IDisposable if required.

'Howard

[Bijesh]

Very interesting info! Thanks.. Bijesh

[Vishal Doshi]

I've found that using only constructors is the most recommended appraoch (RAII - Resource Acquisition is Initialization). However, there are cases when you need Init() for instance if you want to construct some bits in one thread and some bits in another thread. Another example is a File object. File->Open() is really the init operation. The file object could be created with no attached file... The solutions I've used are: 1) Try as far as possible to always initialize fully in the constructor 2) When it is not possible -> Create a factory. For example: class FileFactory { FileFactory(string sDirectory); File CreateFile(string Filename) } which allows you to ensure that File objects are always fully initialised. 3) When neither approach is possible - or you create a FactoryFactoryFactory :) - create an Init() method - but then make sure that all class methods "check" that the object is in the correc state and throw if not. This makes the classes brittle - but - means that people forgetting to call Init() will atleast generate meaningfull error messages. -Vishal

[Anna Jayne Metcalfe]

led mike wrote:

Well there is nothing wrong with breaking that out like that as long as they are then called from constructors,destructors, assignment operators etc.

One thing to be aware of is that doing so causes double initialisation (the default initialiser, then the init() called from the constructor. The only way to prevent that is to initialise class data in the constructor's initialiser list. Other than that, I've no issue with this approach except where someone then makes their init() and clear() virtual and calls them from constructors/destructor. This is such a bad idea in C++ it should cause a syntax error. X|

Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"

[Andy Brummer]

I hope that was humor, because my post definitely was.

---

This blanket smells like ham

[__Nick]

My .02. Having an init function that is required to be called outside of the constructor is only useful in three situations 1 - When you have multiple constructors that all perform a set of common steps in addition to the custom steps that require different constructors. Moving the common steps to an init() function and calling it from the constructor makes for more modular code. 2 - When you are designing a class at the base of a class hierarchy that will need custom initialization before it can be used. Making init virtual and _NOT_ calling it from the constructor will perform the custom initialization. (Calling init from the base class in a constructor is BASE::init and not DERIVED::init). This can usually be done in a different manner. 3 - The class manages an expensive resource (or requires additional function calls to set parameters - username/password), and can't/shouldn't be ready for use on initialization. Usually the expensive resource scenario involves not a call to init(), but a call to open() or something similar. The username/password is similar, but I've seen always open socket designs that require authentication, but in those cases the init took the credentials. Regardless of what any book says I think that calling Some_Type * c = new SomeType(); c->init(); // Use some type here c->cleanup(); delete c; Is unnecessary, creates more of an opportunity to screw up, and ultimately just involves a wasted function call. In general if you have two steps that should always follow each other with nothing in between, they should be encapsulated to make sure that you always do so. Not doing so does not add any appreciable benefit. Debugging should be easier b/c everything is properly initialized, rather than it being seperated out.

[Big Endian 1]

All class members must be initialized in the constructor initialization list. This is a C++ best practice. Don't count on the user to do stuff for you, your class must be self initialized to eliminate unexpected behaviours. As for destructors, there is nothing wrong by making a private cleanup method and calling within the destructor.

[SecondBreakfast]

I got in the habit of doing very little in constructors in C++ because they don't have a return value and it was difficult to know if an error occurred during the initialization process. But, this was back when exceptions only existed in the MFC library as primitive "set/jump" implementation (no clean up). In those days it made more sense to just initialize member varialbes and use a seperate init() method to do any heavy lifting. Then if something failed, the init() could return some meaningful information and the caller could do something intelligent. However, now with structured exception handling, garbage collection, etc, it's makes more sense to do the work in the constructor in most cases. Nevertheless, I'd still argue that it's not bad design to limit the constructor to simple variable initialization and seperate out more complex initialization operations to another step in some situations. I know, what situations? Any situation where you don't want to handle an error condition by simply throwing a exception to the caller.

[led mike]

Anna-Jayne Metcalfe wrote:

the default initialiser

Not sure what you mean?

[CBJG]

Unless there is a compelling reason for using an init() function, it is really a waste of time and bad coding practice. However, there are instances where it is needed, or is much simpler to use an init() function. I do real-time, embedded programming and most of the classes have init() functions. The reason is that memory is statically allocated and fixed and initializing classes via constructors does not guarantee what order the classes are initialized in. Therefore, if a class depends on another class being set up already, for example (there are other reasons as well), the init() functions can be called after all the necessary set up is done. This guarantees that it is known precisely when the classes start running.

[Leslie Sanford]

objarni wrote:

Well -- Dispose() will be called by the garbage collector in any case -- so you don't really need to call it, unless you REALLY want to control the timing of the cleaning up of you resource.

Clearly I need to brush up on my .NET knowledge. I was under the impression that you must call Dispose yourself. Here's the pattern I've learned from .NET documentation, at least when the class that implements IDisposable can be used as a base class:

public class SomeClass : IDisposable
{
~SomeClass()
{
Dispose(false);
}

protected virtual void Dispose(bool disposing)
{
    if(disposing)
    {
        // Release managed resources as well as unmanged ones.
    }
    else
    {
        // Release only unmanaged resources if they have not 
        // been released already.
    }
}

public void Dispose()
{
    Dispose(true);

    GC.SuppressFinalizer(this);  
}

}

My impression, which is apparently wrong, is that it's up to you to call Dispose(). If you do, you should call Dispose(bool disposing), passing a true value indicating that the call is coming from Dispose() and not the finalizer. In addition, in our Dispose() method we tell the garbage collector not to call the finalizer since we've taken care of everything ourselves. However, if we forget to call Dispose(), the finalizer still gets called. In the finalizer, we call Dispose(bool disposing) passing the false value indicating that it's being called by the garbage collector and should only release any unmanaged resources that have not already been released. So what you're saying is that the garbage collector will call Dispose() in any case? [EDIT]Just to qualify things, I understand that Dispose() will be called automatically when using the, um, using construct. I'm wondering about other situations in which you may forget to call Dispose() yourself and you don't have the using construct taking care of it for you.[/EDIT]

[Momony]

Reason's why you might want an initialize and cleanup routines separate from constructors. 1) Your class has many constructors to handle argument type conversion, or allows multiple ways to "start-up" the object. In these situations, it is common to have a bunch of initialization code that is common to all of the constructors, and it is preferred to create 1 private function which all of the constructor's call after handling their special initialization circumstances. 2) Your class has some resources that have no performance penalty to declare, but have a significant performance penalty if they are going to be used, and there are many instances in which the class can be used without using the performance heavy resources. Then you would want to separate the initialization of the performance heavy resources to make it optional. I think an example of this is the CWnd class in MFC C++ 4.2. There are a lot of things you can do with a CWnd that don't require a Window Handle to be created (which causes a lot of OS overhead). Thus, the model was you construct a CWnd object, and if you wanted to use the features requiring a handle, then you called the create function. 3) For cleanup, sometimes you want you object to exist, but you want to free the resources independently. This usually happens when you are "reusing" an existing object instead of deleting the object and creating a new one. Thus, by calling a clean-up function, you can essentially "reinitialize" the object to the constructed state without having to reconstruct the object. I think these situations are rare, and not necessarily the best design, and usually occur in applications needing the highest performance. Performance is rarely a good argument for complicating a class design, but sometimes you really do need it. However, consistency of class design is a good thing in a project, so if all the classes are construct / initialize / clear / destruct that is better than some you do that way, and some you dont. Now the question of if the initialization and clear routines need to be public is another question. Hope this helps, -Kent

[patbob]

I learned as you. It prevents people from forgetting to init()/cleanup() the instances. If implemented right, it saves a lot of testing within the code to see if the object has been initialized, and if the initialization succeeded resulting in smaller, tighter, cleaner, easier to maintain code. ... of course, can't do it with C# since we no longer have the ability to control destruction timing. We're doomed to repeat, I guess.

patbob

[Jacek Ostrowski]

There is one important reason to use virtual Init() methods in C++ -- if you want to let descendant classes override initialization procedure, you cannot call it from constructor. C++ always completely constructs base class before it sets VMT pointer to the descendant class VMT, so it always calls virtual methods from the class being constructed. Delphi, for example, behaves differently -- you can call descendant class' virtual methods from constructor. jacostro

[objarni]

Leslie Sanford wrote:

So what you're saying is that the garbage collector will call Dispose() in any case?

It will if a Dispose() call is placed in the Finalizer/destructor of the class (~DatabaseConnection in my case..) -- and that is the case if you follow the NET documentation pattern for implementing IDisposable:

public class SomeClass : IDisposable
{
~SomeClass()
{
Dispose(false);
}
...

.. so if you've followed that pattern, forgetting some Dispose() (or using-clauses equivalently) calls would not be that dramatic for your application. BUT: I'm still not 100% clear on the low-level semantics of GC/Dispose in .NET. Below is a link to a long technical discussion I'm reading up on just to be sure what I've said is correct. Otherwise, I have quite a lot of things to do next week at work ;) : http://www.thescripts.com/forum/thread214497.html A link within that discussion points to a "morale" of why/how Dispose came about, really interesting read. Apparently it's written by one of the original .NET designers: http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572 -- modified at 15:26 Friday 10th August, 2007

[brianhood]

constructor and the destructor or for memory management. init() is for class that have to many properties to pass in as arguments. unless you won't to use a config file/mem and decipher. ounces the object is constructed ,even if all it does is initialize the object to a NULL state, then you can set properties and call Init() the time the destructor in where you clean up,even if you got to call special function from the destructor, to keep the good clean.

[brianhood]

exactly: and in easier terms. constructor and the destructor or for memory management. init() is for class that have to many properties to pass in as arguments. unless you won't to use a config file/mem and decipher. ounces the object is constructed ,even if all it does is initialize the object to a NULL state, then you can set properties and call Init() ,the destructor in where you clean up,even if you got to call special function from the destructor, to keep the code clean.

[Rob Allan]

I believe the primary reason for this separation (which a few people have already suggested or hinted at) is that you can do something in your Init() function that you can't do in your constructor. Namely, you can call virtual functions and expect them to operate correctly! You can't do this in a constructor. To quote Scott Meyers in Effective C++: "You shouldn't call virtual functions during construction or destruction, because the calls won't do what you think, and if they did, you'd still be unhappy". You can read more about this at http://www.artima.com/cppsource/nevercall.html[^]. I have a friend who worked at a company that got so badly burned by bugs related to calling virtual functions from constructors, that they completely banned the use of constructors in all of their C++ code! This seems an extreme solution to me, but you get the point. To my mind constructors should be used to perform "simple" initialization -- initialize data members, allocate some memory, load resource strings, etc. If you need to do very complex initialization that involves calling other functions, then there may be an argument for breaking this out into a separate Init() function. If your initialization involves calling virtual functions, then it must be broken out into an Init() function to ensure it works reliably. Similar arguments would apply to destructors. Rob.

[peggyjmoore]

It is useful to initialize simple member variables in a constructor. However, if the class that is being constructed needs to instantiate other objects (such as COM components or additional non-trivial classes or additional threads) then doing those kinds of operations in the constructor can cause major problems since the parent class is not yet completely formed. sweetpickle

[ChrisNic]

After following this discussion I come back to something that has been bothering me for some years now. Where is the good old top down method of programming where there were no classes and you solved everything with a gosub and a goto. These arcane problems with classes never came up then. And even back then, the programs still worked. Chris