Or at least, I posted in the same thread as Bjarne Stroustrup*! The thread is about an addition to C++ named "move semantics." Its wonderful to hear someone so intelligent defend silly dogmatic attacks on the language.

Here is the thread.
And here is the article.

Has anyone else heard of move semantics and / or have an opinion on them?

_{* For those unfamiliar, Stroustrup is the father of C++}

If you think you are famous, then what can I say? I'm the guy with the silly dogmatic attacks, as you call it, which are neither silly nor dogmatic.

I am a professional C++ programmer for 10 years now. I can't tell you how much time is spent in dealing with memory management in C++. Writing big and complex applications in C++ is a very difficult, time-consuming, mind-boggling, temper-stretching tasks in the programming field.

If you ask why don't I move to another language, I'll answer that it's not my choice. I program in whatever tools I am given. It's not my decision.

If you want a debate on C++, then please use informed and educated arguments, not 'people don't like it' replies like Stroustrup.

The only reason the C++ committee has not made garbage collection the top priority item in their list is because they are dogmatic. They think that memory should be managed manually, without ever giving any persuasive argument on why it should be so.

They say that C++ is used in embedded systems that can't have GC. Ok, I say 'make it optional'. There are plenty of ways to do that.

They say that C++ is a system's programming language. Fine, I don't see anything that prevents C++ from having a garbage collection. Boehm's collector works, it just need some type information help to make it efficient, and it's only the compilers that can do that.

I really don't see any argument that can hold against having optional garbage collection in C++. What I see is a big list of very big and complex applications that have great problems with wild pointers and buffer overflows and occasionally crash, and they all have been made with C++.

This rant should not be thought of as inflammatory or anything like that. It's just an informed post about the state of programming and the C++ programming language. I see many flaws in it, and I would like to see them corrected. It affects my everyday life, and of course the lives of many other people, since a memory error can have multiple consequences in many levels, including people being fired for not managing complex projects adequately (yeap, I've seen that in my career as well).

you need to go outside more often

Yeah — if you're inside for long enough to come up with one full paragraph of opinions every 365 days, then obviously there's something wrong with you.

Sadly I'm completely clueless as to anything higher level than classes in C++ and really just use it as C with more flexible scope. So I have no opinion as to the real substance of this conversation.

But, ummmm... didn't you think you were famous whenever you last appeared in a thread here with Matt Smith? There's an entire school of platform games that probably wouldn't have existed but for him.

Didn't we just recently have a gc in C++ thread? Based on what you've said so far in this thread, I'm inclined to agree with Stroustrup before even reading what he has to say.

I'm with Thomas Harte :S

Ând I am having some kind of deja vu.

Do you think that I care too much about C++ and I should care less? is that what you mean by saying that?

Well, C++ has give me and many other people enough headaches. Unlike others, I care, and I want to see the situation improved.

I understand that. Everyone says that, actually. No one examines the actual arguments. I am mr Nobody, while Stroustrup is famous, has appeared numerous times in famous web sites and other media and has written books on the subject. So I must be wrong.

Well, somebody really famous said:

My opinion that C++ should have garbage collection has already been ridiculed in numerous sites.

Right now it is violently opposed.

But I don't give up. The 3rd step is close! :-)

And I'm having a coca cola.

What are we talking about here? Pushing for a gc to be built into the C++ language or letting it be an (external, like boehm's) option, as it is today?

Trying to argue why C++ should be forced a gc is just plain stupid.
It's like saying Volvo needs to change so their customers can use xyz part from Toyota. Let their owners decide if they want to modify their cars or the xyz part from Toyota, don't enforce it.

Personally, I don't want a GC built in or as an option, I don't need one.

We are talking about C++ having optional garbage collection.

It's very difficult to use Boehm's gc with C++. It requires many hacks. There are STL issues, linking issues, DLL issues, initialization issues etc. I've tried it, that's why I know.

But that's why I say it should be optional.

I respect that, but I need it. I hope you can understand that different people may have different needs.

From the thread you linked:

So what is the argument about?

I'm not sure anyone really knows, as the original thread is about rvalue and move semantics, not Garbage collection.

Stop the vanity, please.

Agreed. But you are still advocating that the C++ committee should take this as their priority task and I can't understand why.

I appreciate that. And of course I understand that different people have different needs.

[edit]
As if this was the first time on a.cc threads go nutty?

The argument is that "C++ needs garbage collection vs C++ does not need garbage collection".

Until the C++ standards committee announces a C++ version and a release date with GC, I will not believe it. Stroustrup did not convince me that he wants GC in C++. He just says that so as that he does not look very outdated. If he really wanted GC, he would have pushed to it, and he would have strong arguments that would have persuaded the rest of the committee by now.

Move semantics and rvalues exist solely because C++ lacks garbage collection.

Let me explain with easy steps on how the need for move semantics and rvalues was created:

1) C++ is a value-based language.

2) returning a value from a function creates a copy of the returned value.

3) copying is cheap when data can be held in registers.

4) copying is expensive when data can be not held in registers.

5) a solution for the problem of the expensive copying is to move the data. Moving is much cheaper than copying.

6) In order to statically recognize a copy operation from a move operation, the language needs new syntax. RValues are born.

So the whole problem, right from the start, is the excessive copying. And the perfect solution is garbage collection! with GC, two value instances can share the same heap block without any special tricks.

With move semantics, you get:

1) new syntax for rvalues. Programmers need to update their knowledge.

2) a whole series of tools need to be updated (compilers, IDEs, etc).

3) responsibility transfer: the fiasco of auto_ptr. It's no coincidence that nobody uses it.

4) reduntant memory accesses: move semantics means to swap pointers or copy and set pointers.

With GC, you get:

1) no changes in syntax, even if the GC is optional. The compiler could use a special template wrapper class to wrap GC'd types, for example gc<T>, gc<T *>.

2) changes in the compiler, but no changes for the tools.

3) no auto_ptr fiasco. With GC, data sharing is as easy as copying a pointer.

4) no extra memory accesses: moving a memory block is no longer required, since sharing (i.e. copying a pointer) is more than enough.

GC also eliminates the need for shared pointers and reference counting, with many advantages:

1) no need to write shared_ptr<T> all the time.

2) no need to include <shared_ptr>.

3) no danger from unwrapping a shared ptr (by calling shared_ptr.get()) and then wrapping it up in another shared ptr, creating two reference counts.

4) avoiding atomically incrementing/decrementing a reference count, which is an expensive operation.

5) avoiding reference count allocations. In TR1::shared_ptr (which is boost::shared_ptr), ref counts are allocated on the heap (that's how it is possible to share the reference counts between shared ptrs).

Garbage collection has numerous advantages over manual memory management. It simplifies the language, it simplifies coding, and you don't have to bang your head against the wall with wild pointers or illegal delete operations on already deleted objects.

EDIT:

Why is it nutty to discuss a change in something? I don't get it.

I guess it depends on how you interpret the OP.
From being "famous" to discussion about C++ and GC, I would say it is nutty, at least out of topic

Although with the rant and links, I guess GC is right on topic, in a way

OMG!!!! Spellcaster!!! Deja vu? Hey, you didn't have to read this particular thread!

I think axilmar has a much different experience and perspective than any of us do. How many of us have worked on really large C++ applications? I haven't. So on that basis alone I think his opinions should be heard. He also knows what he's talking about and I learn a lot from reading his posts, so be nice.

I don't doubt axilmar's experience and/or knowledge, but I still think that those who want to use CG with C++ should make one themselves or use whatever is available and not try to push it into a standard. Better yet, use C#, Java or whatever has a GC to begin with.

Size of project IMHO doesn't matter when it comes to handling memory. It's basically the same all the way anyway. Unless of course you need to do some dynamic magic because of heavy usage of RAM memory.

ps.

I am being nice, always

That's true, and all of what he says makes sense. It's just that I don't agree with giving C++ gc. I'm not qualified to say much on the subject, but I don't see how GC can ever be implemented without a performance hit (although you've spoken about optimal GC so maybe I'm wrong).

My personal experience of C++ was that it's total cack for general purpose programming compared to modern languages like C#, and if I really cared so much about performance, I'd just do it in C.

For a large project that really needs performance for some bits, it would be safer to do most of it in C# and then interface a C dll for the performance parts than trying to do it all in C++. In the cases where there is a choice, I think it'd almost always be beneficial to avoid the monster that is C++. But I suppose for some people who have known nothing but C++, such additions as rvalues are like exciting new trinkets to fiddle with.

If C++ were the only programming language available to me, I'd be off playing golf somewhere. It seems to me that C++ is more and more becoming a language for elite language nerds. From the article:

template <class T, class A1>
std::shared_ptr<T>
factory(A1&& a1)
{
    return std::shared_ptr<T>(new T(std::forward<A1>(a1)));
}

I'm sure to a veteran the above code makes sense, but I look at it and think "Is this really what programming has come to?"

Why two ampersands? Because one was already taken. So the next semi-related feature gets 3. Brilliant.

I don't care enough to be as nearly informed on the topic as, say axilmar, so my opinion really isn't worth anything from a technical perspective, but it appears that he wants to address the root of the problem as opposed to addressing a symptom with some more obscure syntax. (Which is good.)

It's the classic programmer's excuse. When asked why something doesn't work well or is too complicated, you get some technical excuse instead of "it's not designed properly." Give me a circle, and I'll shove this square through.

The thing that perplexes me is how anybody can defend the C++ language. At a surface level, it would appear that something like D provides basically the same features at a fraction of the syntax.

Then you have "VM" languages like C# that are almost beautiful to work with. What can you do in C++ that you cannot in the others? I'm talking about results; not nerdy little coding tricks.

The more features that C++ gets, the fewer people that will understand it, and the fewer people who will use it. It means you'll be able to make a lot of money in 10 years supporting legacy C++ applications, but all new development will be in other languages.

Optional garbage collection sounds just fine to me as long as I can continue using new and delete without some strange new convention. It's really never bothered me to allocate my own memory when necessary or appropriate as it's fairly easy to put new in constructors and copy constructors or initializers , delete in cleanup or destructors , and both in assignment operators. Of course I forget here and there but that's what testing is for. Personally I've never had the need for garbage collection. Perhaps someone can clarify this for me , but when do most garbage collectors actually free memory? When there are no more pointers to it?

Also , if this rvalue debate is about minimizing unnecessary object creation then why not just use plain object references? No need to copy an object when you have a reference to it.

Also , what would an rvalue reference be doing that it would need to be qualified with two ampersands instead of just allowing rvalues to be referenced in the first place?

Currently you can't use an rvalue as a reference :

Doesn't the 5 just get changed by the compiler to (int temp=5 , sc.foo(temp))?
I don't see the reason for the restriction on rvalues being passed by reference in the first place.

I'm also somewhat confused by what they mean when they say move and forward operations. Are they talking about assignment operations or transferral of pointer ownership or what?

Depends on the garbage collector. Some will free it immediately when no one else is using it, some periodically, some progressively in the background, some all at once only when memory is exhausted, etc. It is completely dependent on implementation (which can be argued as a potential downside, since you now have more nondeterministic run times than usual; of course, if it is configurable, or well documented, it usually isn't a problem.)

The major benefit of garbage collectors is that you can have lazy destruction of objects (both memory and anything else; which is both an advantage and a disadvantage for different resources). You don't have to keep track of everyone holding on to the pointer of an object; the garbage collector does this for you. This removes the need for shared pointers, for example. While it's true GC's do promote some degree of laziness (e.g. data structures that simply let objects fall to the GC instead of explicitly cleaning up after itself), it makes life much, much easier. And if the GC is good enough to not be completely obnoxious about when/how/why it frees memory, it is essentially a non-issue for all but the most performance critical sections.

Of course, depending on the garbage collection scheme, RAII is kinda b0rked when you have a non-deterministic destruction time. Garbage collectors fix problems with memory resource leaks, but cause problems elsewhere. It's all fine and dandy that you can't leak memory, but if you can still leak open file handles, network sockets, locks, etc. the problem becomes somewhat more complicated. But provided both are possible (RAII to perform automatic cleanups, and a really nice GC), it can make a lot of programs much, much easier to code.

C++ sucks and so does Bjarne. That doesn't make you famous.

Move semantics are great whether you're using a GC or not.

This blanket statement is false. What you should say is:

To say the industry shares your stance is silly. It only takes 1 person in the industry to disagree with you and the statement is false. Not only do I disagree with you, the vast majority of #C++ on freenode also disagree.

Let me get this straight... Your solution to the same problem is to double your memory footprint? I fail to see this as a solution... are you sure you understand what move semantics really fixes?

Bjarne himself said the code was not meant for the publics' eyes. The code you referenced is designed to illustrate the need in a way veteran C++ coders could easily see. These code chunks are needed to convince the committee to approve changes.

It was not designed as a model of C++ to non-C++ coders... Try to give it the benefit of the doubt.

It's the most logical syntax I can think of... its fitting given its similarity to references.

Bjarne is not the kind of man to pick an agenda and make up strong arguments for it. He is the kind of man who finds strong arguments and creates an agenda around them.

Thats what makes and keeps C++ so great.

[off topic]

Am I the only insane one who enjoys programming in C/C++ ?

C/C++ programming languages are an almost perfect combination. You can use them almost in every plataform: from PCs to microcontrollers, almost every hardware has its own C/C++ compiler. So trying to improve this(C++) wonderful language makes a lot of sense to me.

I won't talk about performance, portability, or syntax. And yes! as we already know, C++ is not an easy subject to master, just like calculus, algebra, physics or any other stuff.

Paul Whoknows. A happy user(and humble defender:-*) of the C/C++ languages.

[/off topic]

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.

Stop clumping C and C++ together like that! C will always be great for low-level programming, embedded systems and small high performance based applications. It's C++ that's trying so hard to be so much more and in so doing becoming more monstrous.

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.

You're right , that works now. I forgot a semi-colon to end the class too.

I still don't see why rvalues can't be used as a reference though. The rvalue has to have some place in memory. As long as you don't expect it to stick around , what's the problem?

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

Perhaps using 5 wasn't the best example.

Take this example from the article Dustin posted.

A&  a_ref3 = A();  // Error!
A&& a_ref4 = A();  // Ok

Why not just make an rvalue reference (&&) behave as if it were just an lvalue reference (&)? What I mean is , why not allow use of rvalue objects through the current lvalue reference methodology? What does disallowing an rvalue reference in the current standard achieve and what does the proposed rvalue reference really do that allowing current rvalue references would not?

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...

Consider this example (from the article):

ifstream &&find_and_open_data_file(/* ... */);

...

ifstream data_file = find_and_open_data_file(/* ... */);  // No copies!

Since the data_file goes out of scope inside find_and_open_data_file, it would normally be closed. Since we specified move semantics however, the code functions as expected.

Currently there is no real way to do this type of operation in C++.

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?

Yeah, but thats just one application.

Another one is a typical swap operation. Consider Type to be a complex type, one that requires vast resources to copy.

Here is a common swap implementation

void swap(Type& a, Type& b)
{
    Type tmp(a);
    a = b;
    b = tmp;
}

This involves 3 copies.

Now here is the move semantics version:

void swap(Type& a, Type& b)
{
    Type tmp(move(a));
    a = move(b);
    b = move(tmp);
}

This involves 0 copies and has the same result.

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.

SiegeLord, you're on the right track for understanding. One of the differences between a pointer and an rvalue is that the rvalue must follow certain rules regarding scope while a pointer does not respect any.

Consider this example:

ifstream &&find_and_open_data_file(/* ... */);

...

ifstream data_file = find_and_open_data_file(/* ... */);  // No copies!

Try to rewrite the above using pointers, I think you'll find it a bit more awkward.

At the end of the day you can get the job done without move semantics (like we have for decades).

However, move semantics provide amazing relief to those of us who like to enjoy certain paradigms (namely OOP) yet prefer not to pay for them or deal with inelegant complications (like pointers to pointers of objects!).

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

Precisely.

The code would have no effect on a or b.

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.

Doesn't make any difference. If you can't keep track of your news and deletes you shouldn't be coding anything complex anyway.
Unfortually there are programmers who can't and are involved in projects like FF, Explorer and other popular programs. But it doesn't mean we need GC in the C++ standard.

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.

I should have added that thereafter you'd access a and b only through pa and pb. Yeah, stupid and error-prone, I know...

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

Now, thats just scary.

Maybe the company you work for should start using a decent SCM tool. It sounds like they have no idea of how to manage traceability and auditability.

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

No, Baf sells his bottom for free ya know

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

Axilmar, for someone who knows so little about this subject you sure talk loud. I do hope people are not mislead.

That code is just copying pointers. Since a pointer is such a simple type, moving and copying have the same overhead.

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.

It's not possible, realistically, to document every pointer access in a program. In a 200,000 lines of code, developed over 10 years, the documentation project would take another 10 years to be 100% complete.

Look, there is a reason for people wanting garbage collection. I do not see the point in resisting it, since it's going to be optional. If you don't want it, don't use it, but I see no point in forcing the rest of the world to your paradigm.

It's reality, though. I have to finish a 60,000 LOC project in 4 months. In C++.

You are saying that I know so little. Can you prove it? do you have an argument? do you have any arguments against my arguments?

It's insulting to me, as a human being, to being told that I am wrong, without explaining why. I make a big effort here to maintain a good level of discussion where feelings are not important and only arguments count. But I don't see that from you and from other guys. At least my replies are full of arguments and explanations of why recent decisions for C++ are wrong.

C++ is a nice language for the niche it fills: Something that allows some basic OO while still offering the cutting-edge runtime performance that other compiled languages have.
With increasing hardware possibilities and the focus moving from runtime performance to developer performance, this niche gets smaller by the day though. For most business application, a 10% runtime performance increase has zero value, while a 10% developer performance increase is worth, well, 10% of a developer's salary.

There are situations though where C++ is the only possible choice of language, while GC would still be useful. I don't see how (optional) GC in C++ would hurt anyone - if you don't want it, don't use it; if you do, a standardized way of building GC into the syntax and the compiler just makes sense.

BTW, said it before (in that other thread): Microsoft's idea of C++ already includes language-integrated GC, mainly because .NET needs it.

I need to get from point A to point B in my car as fast as possible. I don't have the time to check the brakes so I'll just wrap the car into a huge bubble.

Of course, the optional GC is just fine by me. Not when its forced into a standard.

Yeah, they will not change the face of the world. Nothing enough big to be interesting.
One day people will realize that they are STILL limited by the amount of instruction their processor have. No matter the language, no matter the complexity, it's always reduced to these few amount of instruction.

That's my opinion.

Ha, also, it makes the code ever more unreadable.

EDIT: While you are at GC thing, don't forget to collect yourself.

You are full of bullshit, aren't you? Sorry, but, are you playing stupid? If its in the standard doesn't mean you have to use it. It would be like <cmath> or <cstring>... OPTIONAL.

No I'm not full of shit.

Let say GC becomes part of the standard.
Next time someone wants support for featureX
Next time someone wants support for featureY
Next time someone wants support for featureZ

Hell, while we are at it, lets make the whole .NET library C++ standard.

Look what happened to HTML.

.NET is C# standard, and it sure as hell beats C++ and it's pathetic libstdc++.

We dig it BAF, you like C#

How many parts of your body has been sold to Micro$oft ?

None, just his soul.

Well, it's not an important part for a Zealot as Baf ;-p

Due to their nature, I don't think we can compare C++ against C# or Java. However, comparisons between C++ against D or C makes more sense.

A Father would not like to be compared to his son. Stop comparing C to anything, it's da Father ya know !

I think that you are becoming unreasonable, ixilom. You seem to be implying that anyone who ever makes a memory management mistake should basically be sacked from any complex programming job. Can you honestly say that you never make mistakes in your memory management?

If it wasn't for those 'inadequate' programmers, it is likely that we wouldn't have those buggy programs at all. Including FF and Explorer, but also most of our favourite games and other important software. As axilmar has said, these problems are quite common across a large range of projects. To say that the people who made the mistakes should not have been involved in those projects is - in my opinion - a very narrow viewpoint.

If you want to argue against including GC in the C++ standard, you really should take a different angle, like "no more bloat" or something like that.

I'm not implying that I'm perfect with memory management, but I do test my applications to the extreme.

Maybe I was a bit harsh on the FF and IE example. What they should do rather than sack them is to educate them the importance of good code and documentation, and not wrap them into some huge bubble (read: gc).

'no more bloat' is one way to saying what I've been trying to tell people here, so I agree to that statement

I would like to give another perspective:

Most of programmers are people who choose programming as a way to pays his bills, and they don't have any interest in being a guru. Maybe nerds think this is because they are stupid, but those guys maybe need to take care of other things, like family, etc...

And from the company side, if you have the tools to let those guys work without making disasters. As long the results satisfy your desired quality, contracting better programmers to do the same job, is just an absurd way of losing money.

The conservative attitude is fine, the C++ mafia is not interested in the previous scenario, so other technologies like .NET will fill that (big) space.