|
|
Re: The Problem with Programming
|
Posted: Nov 30, 2006 2:39 PM
|
|
> > What you are advocating here is simply a higher-level
> > design that hides the resource-management from the
> client
> > code.
>
> Yes, that's it exactly. I'm not sure why I've had to
> explain in such depth. Maybe I'm just not being clear.
>
> > However, to actually implement such a design, RAII
> > can be a very valuable building block.
>
> I'm sure it would be helpful, however, it's not necessary.
> The whole point here is that even though Java lacks an
> n immediate destructor, it's not a huge problem because
> this pattern is more effective anyway. Using this
> approach has also lead me to abstracting out the query
> also. I can change the query or swap it out as needed
> without changes to the code.
>
At this point I think some people see "more effective" as your opinion and how effective or not RAII is in this sort of context depends a lot on the system architecture, granularity of classes, etc. All the things you describe can be done in C++. In the case you describe I would say that RAII buys you some insurance because in addition to your own methods managing the connection, if things go to hell in a handbasket the constructors should clean up the resources anyway.
> One problem with auto-pointers that I've heard mentioned
> is that you can have a sudden pointer-tree collapse that
> causes the application to stall. Is this a common problem?
I've never actually seen it. I can see how it can be done if things are improperly scoped, but then I would think this is indicative of a bigger problem. It would be a symptom of, in my opinion, of a badly flawed design.
Is there a reason something similar but much more subtle couldn't happen in a java or C# app? A pointer collapse would be caused by a root pointer being deallocated and having its constituents not be allocated which would result in leaked resources and all kinds of other nastiness. If you disposed of a root class but still had valid references to its constituents, wouldn't you possibly end up with a case where the container got garbage collected but you were able to still access objects that used to belong to the container? If that just isn't possible, great. If it is, I could see that leading to some really hard to diagnose and fix bugs whereas the C++ app would most likely fail miserably.
Which one of those outcomes can be argued to death and I don't see one side convincing the other that their way is "right". They are both bad. Personally I'd rather have the dramatic crash and burn vs. the app limping along, but that's just me. Don't waste your breath trying to convince me otherwise. I've dealt with both situations too many times to count and the dramatic crash and burn has, without fail, been easier for me to diagnose and fix. The users are more annoyed initially but their problems are fixed much more quickly and in the long run, in my experience, they have been happier.
|
|
Previous Topic
