🚀 go-pugleaf

In article <41vlgv$q33@druid.borland.com>, pete@borland.com (Pete Becker) writes:
> In article <41tjep$2hn@deyke3.fc.hp.com>, rainer@deyke3.fc.hp.com says...
>>
>>Pete Becker (pete@borland.com) wrote:
>>: In article <41kici$p4t@deyke3.fc.hp.com>, rainer@deyke3.fc.hp.com says...
>>: >: TApplication* MyApp;
>>: >: MyApp = new TApplication("My Application");
>>: >
>>: >: without new and delete?
>>: >
>>: >Why bother with doing both at the same time?
>>: >
>>: >MyApp = (TApplication *)malloc(sizeof(TApplication));
>>: >create_TApplication(MyApp, "My Application");
>>
>>: The difference is in the gap between the two lines, where you have 
> something 
>>: that claims to be a pointer to a TApplication object, but isn't. C++ makes 
> it 
>>: very hard to perform operations on objects that have not been initialized. 
>>: Separating memory allocation from initalization makes it much easier to 
>>: accidentally do things like this, as we have all done at one time or 
> another.
>>
>>Real programmers don't "accidentally" forget to initialize objects.
>>
> 
> Real programmers are human and make mistakes.
> 
>>:       Or, to turn the question around the other way, why separate them?
>>
>>Obviously when using an array where each object is initialized to a
>>different value.  Especially a resizable array.
> 
> That's not the example you posted, which allocated a single object. So, let me 
> ask again: in the code you posted, what benefit is there in separating 
> allocation from initialization?
> 

Pete, this example is so beautiful it isn't even funny. The fact that
you can have a pointer to unitialized data lying around at
all is a source of bugs in its own right.

Obviously Raynier is wasting alot of company time reinventing the wheel
40 hours a week :)

-Garrett