C++ Community News Forum - The Problem with Programming

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

C++ Community News Forum
The Problem with Programming

212 replies on 15 pages. Most recent reply: Dec 8, 2006 6:12 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 212 replies on 15 pages [ « | 1 ... 4 5 6 7 8 9 10 11 12 ... 15 | » ]

Posts: 19
Nickname: pmd
Registered: Oct, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 7:17 AM

Reply

Advertisement

> Now if only C++ had garbage collection...

This would be nice, perhaps. I think there is a GC available for C++. But I haven't felt a strong need. I don't think it takes much programming discipline to overcome the problems a GC tries to solve. Use of std::auto_ptr or other smart pointers and good object design go a long way toward minimizing memory leaks while maintining better control over memory allocation/deallocation. Memory is often not the only resource we would like to release when an object is destroyed. Having explicit control over releasing locks, closing or removing files, etc. is often too important to leave to a GC. RAII has been very useful to me in C++. Is there a good way to do that in Java?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Nov 30, 2006 7:25 AM

Reply

> RAII has been very useful to me in C++.
> Is there a good way to do that in Java?

You can use the reference types (basically GC sensitive pointers) to this effect but it depends on the GC to release the Object, which may or may not be what is desired.

Personally I think RAII is a less effective solution to what I use for important resources. RAII depends on the Object being released which is unreliable. I prefer a service approach where a code provides a handler that describes what it wants to do with a resource to something that manages that resource. In this way, as soon as the task is finished, I can determine how to deal with the resource regardless of whether any Objects are released.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 7:37 AM

Reply

> > Now if only C++ had garbage collection...
>
> This would be nice, perhaps.

The only reason I would want a GC is to easily avoid memory fragmentation. But again, for that you need a compacting GC which is pretty hard (impossible?) with C++.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 8:21 AM

Reply

> The only reason I would want a GC

Just to avoid any confusion: that should be "the only reason I would want a GC with C++..."

Of course, in many languages the object model really requires a GC.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: The Problem with Programming

Posted: Nov 30, 2006 8:22 AM

Reply

> > The only reason I would want a GC
>
> Just to avoid any confusion: that should be "the only
> reason I would want a GC with C++..."
>
> Of course, in many languages the object model really
> requires a GC.

I'm just curious, what kind of applications do you write?

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: The Problem with Programming

Posted: Nov 30, 2006 8:32 AM

Reply

> > RAII has been very useful to me in C++.
> > Is there a good way to do that in Java?
>
> You can use the reference types (basically GC sensitive
> pointers) to this effect but it depends on the GC to
> release the Object, which may or may not be what is
> desired.
>
> Personally I think RAII is a less effective solution to
> what I use for important resources. RAII depends on the
> Object being released which is unreliable. I prefer a
> service approach where a code provides a handler that
> describes what it wants to do with a resource to something
> that manages that resource. In this way, as soon as the
> task is finished, I can determine how to deal with the
> resource regardless of whether any Objects are released.

Since C++ guarantees that an object's destructor will be called when it goes out of scope, I'm wondering what would be more reliable? Or are you referring specifically to Java or C# where you cannot rely on the garbage collector cleaning things up in a timely manner? I've gotten bitten by that in .NET at times.

I think your method allows slightly more granular control but in practice I don't see how it differs substantively from using a locally allocated object to complete your task and then just letting the destructor clean up after itself.

What am I missing? An example would be helpful.

Thanks.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 8:52 AM

Reply

> > > The only reason I would want a GC
> >
> > Just to avoid any confusion: that should be "the only
> > reason I would want a GC with C++..."
> >
> > Of course, in many languages the object model really
> > requires a GC.
>
> I'm just curious, what kind of applications do you write?

In the last 6 years, mostly natural language processing applications and libraries. Currently I am working on a translation memory server: http://www.babelport.com/news/1893

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Nov 30, 2006 8:54 AM

Reply

> Since C++ guarantees that an object's destructor will be
> called when it goes out of scope,

My technique doesn't have this requirement.

> I'm wondering what would
> be more reliable? Or are you referring specifically to
> Java or C# where you cannot rely on the garbage collector
> cleaning things up in a timely manner? I've gotten bitten
> by that in .NET at times.

This is a solution to that, but once I started using it, I've found it to be vastly superior in other ways. Mainly with separation of concerns.

> I think your method allows slightly more granular control
> but in practice I don't see how it differs substantively
> from using a locally allocated object to complete your
> task and then just letting the destructor clean up after
> itself.
>
> What am I missing? An example would be helpful.

Java has JDBC which is an API database interaction. It's very powerful and flexible and portable to some degree but highly procedural in design (IMO).

I created a think abstraction around this for my work. Basically, I have a manager class that takes a query object and a handler, it executes the query and passes each row back to the handler. The manager guarantees that the connection is cleaned up (or not, it's transparent to the 'client'). This happens even if the handler or query objects are never released. It happens as soon as the handler returns after the last row, blows up, or signals that it wants no more rows. Obviously, if the handler never returns, I'm stuck but that's not a problem I've seen yet and is a problem regardless of this design.

It's perfectly acceptable for the client to hold onto queries for the life of the application (rows and handlers too but there is little point). It actually encouraged because the queries can be compiled on the database and rerun with different parameters, and connections refreshed, statements recompiled as needed and is transparent to the client class.

With RAII, you essentially have a requirement that the object be released. I don't know if or how you document this behavior in APIs, but it's an unnatural side-effect, if you ask me.

Posts: 19
Nickname: pmd
Registered: Oct, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 9:53 AM

Reply

> With RAII, you essentially have a requirement that the
> object be released. I don't know if or how you document
> this behavior in APIs, but it's an unnatural side-effect,
> if you ask me.

Using RAII doesn't require that the object be destroyed. It ensures that any resources aquired by the object are released if--and when--the object is destroyed. If you don't want this "side-effect" (which seems quite natural to me), don't use RAII.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Nov 30, 2006 10:02 AM

Reply

> > With RAII, you essentially have a requirement that the
> > object be released. I don't know if or how you
> document
> > this behavior in APIs, but it's an unnatural
> side-effect,
> > if you ask me.
>
> Using RAII doesn't require that the object be
> destroyed. It ensures that any resources aquired by the
> object are released if--and when--the object is destroyed.
> If you don't want this "side-effect" (which seems quite
> e natural to me), don't use RAII.

You're missing the point. If you want to make sure resources are released properly, all client classes must release the Objects in question in order to trigger the cleanup. As long as the Object remains in scope, the resource will be held. With the technique I describe above, that is not the case. Resource management is completely decoupled from how the client class manages it's Objects.

Posts: 19
Nickname: pmd
Registered: Oct, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 10:21 AM

Reply

> > Using RAII doesn't require that the object be
> > destroyed. It ensures that any resources aquired by
> the
> > object are released if--and when--the object is
> destroyed.
> > If you don't want this "side-effect" (which seems quite
> > e natural to me), don't use RAII.
>
> You're missing the point. If you want to make sure
> resources are released properly, all client classes must
> release the Objects in question in order to trigger the
> cleanup. As long as the Object remains in scope, the
> resource will be held.

Not necessarily true. It depends on how you design the object. There's nothing about using RAII that requires you to destroy an object to make it release its resources. It just means that resources are acquired when the object is initialized and released (if they are still being held) if and when it is destroyed. There's nothing that prevents an object from releasing those resources or acquiring new ones as a result of some other interaction with the client.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Nov 30, 2006 10:30 AM

Reply

> There's nothing that
> prevents an object from releasing those resources or
> acquiring new ones as a result of some other interaction
> with the client.

How is that special in C++? The whole point of your post that initiated this sub-discussion was about auto-releasing resources based on the Object life-cycle. Now you are making the case that its not needed.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Nov 30, 2006 10:34 AM

Reply

> > There's nothing that
> > prevents an object from releasing those resources or
> > acquiring new ones as a result of some other
> interaction
> > with the client.
>
> How is that special in C++? The whole point of your post
> that initiated this sub-discussion was about
> auto-releasing resources based on the Object life-cycle.
> Now you are making the case that its not needed.

Just to be clear, this is what you wrote:

>> Memory is often not the only resource we would like to
>> release when an object is destroyed. Having explicit
>> control over releasing locks, closing or removing files,
>> etc. is often too important to leave to a GC. RAII has
>> been very useful to me in C++. Is there a good way to do >> that in Java?

I agree that it's too important to leave to a GC. I also think it's too important to couple to the life-cycle of an Object that is under the control of some class with unrelated responsibilities.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Problem with Programming

Posted: Nov 30, 2006 11:08 AM

Reply

How about some code?

Here is the point of RAII:

if (some condition) {
db_connection conn(some_connection_string);
conn.query(some_query);
// conn.close(); // unnecessary, but possible
} // conn gets destructed here and the connection to db closed

Now, what happens if the call to query throws an exception? RAII makes sure that the connection is closed without any "finally" blocks.

Would you care to illustrate your technique?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: The Problem with Programming

Posted: Nov 30, 2006 11:21 AM

Reply

> Changing the state-of-the-art in language design/usage
> does first of all require to become a language designer
> oneself.
>
Well, I don't mean the state of the art in programming language design, but in software development. I have to develop software today given the languages and other tools that exist. What can I do given that context today to make better software faster? One thing I could do is use a different language, so it is useful to me to understand the differences between them, the advantages and disadvantages of them, what kinds of problems they are a good fit for, and so on. But once a language (or languages) have been chosen, how do I maximize my effectiveness?

For example, one thing I've tried to do lately is reduce the amount of hand-written code in the system. We wrote several code generators, and we're planning to add a few more, that generate portions of our system from smaller input files in little grammers we devised. So we're trying to replace big swaths of hand-written Java code with much smaller pieces of hand-written code in our little languages. It also reduces code because we have fewer tests to write, as we don't bother writing tests against the generated code.

Flat View: This topic has 212 replies on 15 pages [ « | 4 5 6 7 8 9 10 11 12 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use