I have not previously encountered this approach (and I have been coding professionally for nearly fourteen years). I disagree with the separate init() method approach for a number of reasons: a.) Expectations (one should follow convention) - most frameworks will initialise objects through the constructor, and users of your code (who can even be your co-workers or your future co-workers) are likely to expect that too. They will easily do something wrong if the class usage semantics are unconventional. b.) You create an additional source of failure (read source of bugs), because nother method must be called before the object can be used. Omission of this call can create a hard to track down bug. Why create this possibility? c.) Error checking. You have created an additional state for your objects to exist in. You have made it possible to use your class without it being initialised, and so you ALWAYS have to ensure that when a public method is called the object has been correctly initialised. Usually you would only have to place guards on the methods that are intended to modify the object's contents in order to ensure that the contents are valid. If your object can be inherited from (this is C++ so unless you only construct objects through a factory method, your class can be inherited from), then you have to place guards in the protected methods as well. Ugly! d.) Calling init() (or whatever you call it) multiple times becomes possible but probably does not make sense. If you need this capability for the object, then you are either reset()ing the object, or you need to construct a new one. e.) Copy constructors - when copy semantics are needed for a class, the constructor has to create a fully initialised object. This breaks the paradigm. f.) C++ will chain the calling of constructors. The compiler will tell you if you get the chaining wrong. You will have to implement this manually if you use an init() method, and there will be no compile-time errors to tell you that you got it wrong. It's even more error prone when you are using multiple inheritance. You have once again created a source of potentially hard-to-find bugs. Why? g.) Performance - initialising attributes within a constructor (especially within the member initialisation list) is more efficient than initialising them from a separate method. If performance is any concern, you will almost certainly want the constructor to do it all. h.) If you absolutely must perform initialisation in a separate method, make the method

With all these draconian measures to prevent piracy, how long will it be before weaknesses in the system allow it to be bypassed? The means to access the content exists within the PC after all. It only requires a few crackers to make the contents available. After this has occurred, don't all these measures collectively turn into a very expensive and inconvenient white elephant, that everyone is saddled with for a considerable length of time?

It's not actually fair to compare Turbo C# with Visual Studio. Turbo C# is Borland's entry level product. I agree that it would be nice to have .Net 2 capability (not having it makes the product useful for learning how to program only really), but that's what you get (and a whole lot more) with Borland Developer Studio. Borland probably want some differentiator to encourage you to buy the Developer Studio product. It integrates Delphi, C++ and C# into one product. This is the product to compare against Visual Studio if you are making comparisons between serious development tools. - Chris Bowen