Why should I use a pointer rather than the object itself?

I agree with grandparent that understanding what a pointer is and that almost everything in a Java program is a pointer it's critical for a Java programmer.

They learned programming by reading blogs and pirated PDF files on BitTorrent. Of course they don't got a level of understanding most hackers here have.

You want a good programmer you need 15+ years of experience plus a good understanding of computer science, recent high school and college dropouts don't have that.

You hire a cheaper labor source, you won't get that level of quality a more expensive labor source will give you and you get what you pay for!

But yes, a java programmer with embedded or native background would have a better understanding of this than people who learned Java first, which is what I'm really addressing here. And in the OP on SE you can clearly see that this is a big part of that person's confusion.

For example, let's say you have a class that news up an object in its constructor. Presumably, the corresponding delete lives in the destructor. But if that constructor throws an exception, the destructor will never be called. If it throws the exception after the "new," then you have a memory leak.

So basically, you need a class whose only job is to manage a single pointer. You could certainly roll your own smart pointer, but it would have to work pretty much exactly like one of the ones in the standard library.

First, auto or scoped pointer gets you a stack discipline. If your objects weren't very big, you might as well create them on the stack itself. More efficient and suitable for multithreading. If the lifetime does not follow the lexical stack then you are out of luck with this style of RAII.

Next, reference counted pointers: Cycles are clearly a problem. The traditional mantra is: use weak pointers to break cycles, but then you are back to error prone manual management (of cycles). If I am to be trusted with using weak pointers correctly, I wouldn't be too bad with manual memory management either. Pure functional languages with eager semantics do not allow cycles, so are ref counts a good idea in such cases ?

Although, many do not think about it that way, reference counted system is a _garbage_collector_. Just a particularly simple one. Just because one understands how it works, does not disqualify it from being a garbage collection system. It is just not a very efficient garbage collector for cases where running time is sensitive to cache locality, which is true fairly often.

I am quite excited about Rust's regions. I dont think programming with regions is easy and you would want to have a garbage collector anyway. I hope this style of programming sees more mainstream visibility. Something should come out of all the MLton work on this. EDIT Indeed meant MLKit but it draws enough from MLton that I thought HNers would be able to relate.

There is also D's scoped guards, but I am not yet familiar with what they do.

Right, that's implied by a C++ object being deallocated. I understand how it works - it's just that it's really obvious if you know anything at all about how the stack works (and C++ destructors).

  func f() error {
    var a, b, c *handle
    var err error	
    if a, err = acquireHandle(0); err != nil {
  	return err
    }
    defer a.Close()
    if a, err = acquireHandle(1); err != nil {
  	return err
    }
    defer b.Close()
    if a, err = acquireHandle(2); err != nil {
  	return err
    }
    defer c.Close()
    //use a, b, c
    return nil		
  }

        using (handle a = new handle(0))
        using (handle b = new handle(1))
        using (handle c = new handle(2)) {
            // use a, b, c
        }

edit 2: I judge a language in part by seeing if they actually can define nested / chained exceptions well. If they don't, they're probably not too serious about exception handling...

    handle a, b, c;
    if (!aquire_handle(&a, 0)) goto fail1;
    if (!aquire_handle(&b, 1)) goto fail2;
    if (!aquire_handle(&c, 2)) goto fail3;

Assuming that's hyperbole, I agree with the sentiment. It's possible to write exception safe code with try & catch - it's just almost as ugly as checking exit statuses and easier to miss something.

Qt also has used its own smart pointers for a while but these generally are declared within some container class, so the idiom basically allows you to do allocation entirely within containers and so never use the new operator directly.

Now, there may be situations where you have a complex chain of multiple connections that don't fit to an existing container. The sloppy way then is to use new and the good way to write a custom container. The idiom can also when dealing external libraries that allocate memory directly or somehow demand you use the new operator.