C# is where it's at!

Performance doesn't matter much these days in most applications, there are far more portable languages (run the same binary everywhere), and the syntax sucks (for example, nested templates and the >> issue).

C++ isn't the worst language ever, but there are far better languages out there for a lot of applications.

One main goal of the C++ language is to produce software that can run as fast as the hardware allows, so the main issue is that such a garbage collector shouldn't use a single cycle of the processor if it is not needed.

I think shared_ptr's are a good solution

Edgar Reynaldo should modify his class to:

class someclass {
  private :
    int baz;
  public :
    void foo(const int& bar) {
      baz = bar;
    }
}

if he wants sc.foo(5) not to be an error.

5 is a constant, so how can you reference it in memory? It isn't in memory...

I enjoy programming in C++. But then again, I haven't worked on any large scale programs.

I've never used D, but I imagine that I'd like it as much or more than C++. And I'd program in C# over C++ any day. Java is the only language that I'd prefer to not deal with. And the more I use PHP, the less I like it...

I think I see some of the problems they're trying to solve now, although I still don't quite understand how move operations function at the lowest level - do they just rearrange references? How are they simpler or more effective than an assignment operation that lets the rvalue object go out of scope - well, wait, I guess that's what they actually are, they basically change the scope ownership of the object by allowing a higher level scope to take over management of a lower level object that is about to go out of scope. Is that somewhat accurate?

Err, pardon my ignorance, but wouldn't the whole problem be moot if you used pointers instead of references?

Like this:

Swap(Type ** a, Type ** b)
{
    Type* temp = *a;
    *a = *b;
    *b = temp;
}

Type* a = new Type("1");
Type* b = new Type("2");
Swap(&a, &b);//a is now 2, by is now 1

Also, how do these rvalue references translate to pointer language? The standard reference is just a shortcut way of saying *const iirc (with a whole set of rules associated with that of course). Are these new things now **const? And if not, I think there should be an rvalue pointer as well as an rvalue reference.

std::swap already does for pointers what you have shown. I think the point is that people sometimes want to work with objects.

Of course you could throw some more indirection at it:

Complex a, b;
Complex* pa = &a;
Complex* pb = &b;
swap(pa, pb);
etc

I tried. Here is my try to use the Boehm gc in my programs. Unfortunately, there are some major issues that do not allow for using the Boehm gc in applications other than trivial ones (in C++; the situation is better for C).

I also tried to make a garbage collector using special ptr classes. You can find here my draft code for making a collector out of standard C++. But it's slow, and it does not work with threads.

When we say 'size', we refer to complexity. Big programs tend to be more complex than smaller ones, but that's not a definitive rule, of course.

Actually, GC may speed things up! Java allocation is way faster than C++ allocation. I've made some benchmarks in the context of Boehm's gc, and Java is way faster in allocation than C++, except in the case that C++ uses the same algorithm as in Java (i.e. increasing a pointer).

But it's not my choice. Our clients demand C++. Our managers want C++, and they want to show that we can do it. If it was on me, I would choose Java (because our projects could be run on Linux in the future).

Indeed, that's what I am trying to do. I agree with the rest of your comments.

I would agree with you, but unfortunately reality is different.

The Windows Explorer frequently crashed up until recently with segmentation faults.

Firefox has memory leaks and crashes.

Interner Explorer crashes with segmentation faults.

MS Word frequently crashes, again with segmentation faults.

If you search the internet, you will see many issues with big C++ applications. It's not only me.

The memory footprint is not doubled when you use GC. A copying GC defragments memory, so you have a lower memory footprint overall. You also have the advantage of better cache coherence.

Between two collections, an application would use more memory, that's true. But it does not matter: this memory will be paged out anyway. The working set of the application would be the same.

There should be no distinction of code for veterans and non-veterans. Good code should be equally readable by anyone.

Where are those strong arguments in favor of GC in C++? I have searched the web thoroughly, but I have not found them. All I found was some comments in the form 'yes, I like it, other members of the C++ standards committee like it, we will see in the future...'

Those two statements are contradictory! shared ptrs are much slower than garbage collection. If you study the code for boost::shared_ptr, and especially the assembly listings, you will see that a simple shared ptr assignment results in two pages of assembly, where as in GC a simple pointer assignment is 2 lines of assembly code (load from memory to register, store from register to memory).

Move semantics are exactly like auto_ptr: ownership is transferred to the object destroyed last.

That's a double-edged sword that will byte many in the future. Just like people complained about auto_ptr and it was not used anywhere (except in trivial cases), people will complain in the future about move semantics as well.

Yeay, they made swap faster. Great! Now if GC was used, swap of pointers would be much faster than this.

The swap example is the typical example of trying to cure the symptom instead of the cause. And it perfectly fits my explanations about copying and moving in my previous post.

OOP has nothing to do with move semantics. Java, Smalltalk, C#, Ruby are all OOP, yet they have no move semantics.

I think you meant to say 'move semantics provide amazing relief to those of us who like to use objects instead of pointers'. But that's an implementation issue which could be covered without changing the language.

Perhaps you are not aware of many factors that can make things difficult.

First of all, source code is never written from scratch except in very rare circumstances. I am still playing with code that started on 1/1/2000. It's very hard to track changes in an old project, because there are things that you might have forgotten. One of the often repeated problems is to delete something somewhere, forgetting that another deletion of the same object happens in another place.

Secondly, projects involve more than one person, and many different persons over the course of time. So, in a large project, it's very difficult to remember everything, and when a person is replaced with another one, some knowledge is usually lost. This lost knowledge shall not include memory management details, otherwise big problems may be created.

Thirdly, managers push for projects to be finished as soon as possible. Not having to manage new/delete, makes life much easier and the development time much shorter.

Forthly, if managing new/deletes manually was enough, then solutions like shared ptrs would not exist. Obviously, some people had problems managing memory and they wanted the solution.

Finally, there are some algorithms that require garbage collection. For example, when referential cycles are involved.

EDIT:

Do you guys know that boost::shared_ptrs are not thread safe? despite what is said here, if you study the code you will see that is possible for a thread to kick in and increase the ref count of an object just before another thread prepares to delete the shared reference count structure.

EDIT2:

boost::shared_ptr instances are not thread safe, but if you don't use the same shared ptr from two different threads, it's ok.

Still, all of this would be unnecessary if C++ had garbage collection.

Then thats your problem for not documenting/planning correctly. I'm sure a GC would take care of that

Now, thats just scary.

Are they paying you to say that?
http://www.oreillynet.com/xml/blog/2007/01/an_interesting_offer.html

This still copies the data (just pointers, but still) around. Move semantics does not copy anything, right?

The way I'm seeing copy semantics, is its just a language level feature to alias and/or rename symbols, not actualy a machine level action that moves things.