Nice, add a red herring instead of addressing the personal responsibility poiunt.
No, it's not a red herring. The fact is that your
viewpoint that it's acceptable is not a widely held one. I do address the "personal responsibility" point.
Wel, that's bull, and the chinese citizens should be taking their actions against the companies that are dumping the stuff - i.e. their own people.
Yes, to the extent that they have the means to do so.
However, you shouldn't be paying people to dump it in their back yards.
Yes, your reply is nonsense, and you failed to address the rest of my points which clarified it.
No, it isn't nonsense at all. The mercenaries analogy is perfectly analogous, IMO. If you pay a waste disposal (nudge nudge, wink wink) company to dump your trash in someones back yard, you are responsible.
As for the Bum taking the money? Well, He took it didn't he? He knows what he's getting into doesn't He?
Try and get that one past the human subjects guidelines in America. Good luck! You might consider it ethical, but fortunately, the research community here does not.
But Dr. Spork, idiots
like you (normally I don't flame, but I do believe in "tit for tat") feel that personal responsiblity extends only to things that
you don't find too confining, or too difficult to do.
I think you've got that wrong. People like you want to create waste, and not take responsibility for its disposal. You also want to hold ordinary Chinese citizens responsible for the actions of companies that they can't control.
The government has come up with a solution, we are not responsible for all the worlds ills.
Dumping your shit in someone elses back yard is not a "solution". Your red herring about grain is just that.
As I stated earlier (something you failed to address) it isn't as if we are the ones spreading it on the countryside, we pay them
money to dispose of the stuff. At that point (believe it or not) It's the responsibility of the ones taking the money to do the
right thing by it.
Nonsense. If you pay the lowest bidder to dispose of your waste, and you know that they're cheap because they're dumping it in the river, you are responsible.
It's like hiring mercenaries to drive people off your land, and claiming that it's the mercenaries responsibility to do it ethically.
Do I want my old computer ending up in a river? No. But don't blame me if it does, *I* didn't throw it in a river or asked
anyone to burn plastic off its wires...
Come on. You want it sent off to the cheapest "waste disposal" or "recycling" company in China, and then you want to pretend that you don't know what they'll do with it ?
There are too many other responsible parties here that are DIRECTLY responsible to come after me with some tax or $30
increase on PC sales to try to resolve the problem.
The parties that produce the waste are responsible for safely disposing of it. Having China "ban" it does not solve anything, because you're still going to use the lowest bidder as your "waste disposal" company, and it will end up in a river in some other country.
China is buying the equipment and then dumping it in China.
First, the article does not say that the sovereign state of China buys it. Second, "China" is not a person. The analogy is just fine. You're paying some company in China to dump it in someones back yard.
Global trade is the CAUSE of wealth imbalances, not the solution for them.
Nope. A lack of global trade is an obstruction to social mobility. It results in an aristocracy of citizenship. There are obviously people with a vested interest in creating and maintaining such a thing (namely, lower/middle class citizens of wealthy countries). But a lack of global trade is certainly not good for curing wealth imbalances.
Creating a wealthy elite in third world countries will just raise local prices even further out of the reach of the poor, adding to the problems caused by local goods being sold at global (i.e. western) prices.
This goes against all existing experience. A country can use taxes and social problems to redress social inequalities. Currency increase is rarely bad for the economy. Countries with strong currencies have high standards of living, countries with weak currencies have low standards of living.
Also purely from a selfish POV, I don't want to see my salary capped because some shortsighted manager is trying to increase his bonus by reducing costs by exporting jobs overseas.
Right on! You are one of the people with a vested interest in maintain an aristocracy of citizenship, and you aren't really that interested in fairness. In fact, fairness probably isn't in the interests of most people in western countries
American companies...
American companies have their own interests too. They are neither moral or imoral. They are indifferent to morality.
A start to a real solution at eliminating global wealth disparities would be for us to start importing grain
Question 21: Based on the above, the authors goal is:
To put American farmers out of business
To prevent third-world countries from developing brain economies
To create a dependency on other countries for essential food resources
Instead we currently prefer to subsidize domestic production thus keeping prices artificially high.
Now I'm confused. Is protectionism good or bad ? First you were saying it's good, and we need more of it, and now you're attacking it.
One has got to wonder if mandating programmers is the correct way to spur the development of a publicly developed UI. When Corel tried to do that with KDE, they ended up being pushed out simply because they could not contribute code at the level and skill of the rest of the KDE hackers.
I think putting QA people on the job is a very good move. If they focus on bugfixes, running backtraces and fixing core dumps, and that sort of thing, it's probably a lot easier for them to contribute than if they try adding substantial new features. The problem with Corel is that they wanted to substantially extend existing code, with their "innvative file manager" (yes, they really called it that) and other things.
Another explanation is that it's easier to develop proprietary software for Gnome: GTK and most Gnome-Libs are LGPL, while, if you would use KDE, you would either have to purchase a commercial license for Qt, or to use the GPL version
I don't see why this is an enormous problem. If they're using Suns C++ compilers, they're already paying an arm and a leg as it is. I doubt SUn would have trouble negotiating a discount bundle-ware deal with Trolltech.
So, I think it is a C vs C++ thing. It's not just about what Sun know, I think the linkage issues with C++ are probably an issue (because you're stuck with whatever compiler was used to build the
libraries).
BTW, a lot of the closed source apps developed on Solaris either have no GUI, are never released (in-house), or both.
The US is responsible for 26% of regular UN budget and 31% of the peacekeeping budget. For the amount being paid into it, the US should have such a majority control (not in a dictoral manner, but in a majoritian manner). In a democratic nation, such as the US, one cannot blame the people for not wanting to be the majority support of an organization that likewise does not provide a majority voice to the US (it essentially goes against the fundamental concepts of democracy).
The US, along with a small number of powers, do enjoy priveliged status on the UN. They are one of the few states with veto power, and they do use this to their advantage (namely, they can block resolutions condemning the US or Israel)
I don't understand your point about "majority support", 26% and 31% are not "majorities" by most measures.
In C/C++, I have problems with memory leaks - not freeing pointers.
What's this strange language called C/C++ that you are using ? If you really don't think the two are any different, maybe the problems are in part caused by the fact that you don't know how to use C++ properly. There's a big difference between using the occasional new/delete for a low level class, or for performance optimisation (which is what happens in C++), and having to manually allocate and free every string.
Java doesn't have a UI. It abstracts the user interfaces of other systems. This leads to lowest-common demoninator problems, at least in the case of AWT.
Accumulating unneeded objects
never happened to me a single time - and if it was a problem in practice it would have been easy to add to modern language
compilers/VMs a debug option to see where is memory kept as an addition to profiling and branch coverage. So maybe
garbage collection isn't a magic pixie but it's really 99.99% of a magic pixie (taking into account the probability that the
catastrophy you fear).
Well, I only very rarely run into problems caused by unmatched new and delete. These are rarely problems in practice. 99% of the memory problems I get are dereferencing a NULL pointer as a result of not checking that an operation succeeded. I've never run into "cycle" problems with reference counts in C++ code, because I don't abuse reference counting (reference counting, if misapplied causes more problems than it solves, as you've pointed out)
When you have GC, resource accumulation can occur if objects hold references that they are no longer using. There are cases where this can happen. An obvious example is an array implementation where removing from the back doesn't actually zero out the reference, so the array still holds on to the reference. More subtle and nastier examples include GUIs accumulating doodads (listeners, validators or whatever) that the user tacks onto a
widget, and forgets about.
Look, if an object is accessible, it ain't garbage, it's sitting at the end of some pointer, which if you access, you'd better get
valid memory.
The problem is that a reference to an object might not be accesible to public member functions in that class. An example where this sort of thing is a potential problem would be a vector/array class. "Removing" an element from the end of the container doesn't necessarily involve deleting anything, it merely involves modifying a member variable. So you've got a reference that is being held, despite the fact that (a) the container is no longer using it, and (b) will not be released as a direct result of anything the user does. To make matters worse, the garbage collector reserves the right to clean up the container itself whenever it feels like it. This is not strictly speaking a memory leak, but it is a problem that occurs when containers do not release resources in a timely manner.
Garbage collection is about removing the accounting errors that lead to true memory leaks, which means you can focus
your human intelligence on figuring out what resources your program needs to solve the problem it is working on.
Again, garbage collection is not a cure for ignorance on the part of the programmer. It's merely a strategy for managing memory that uses accesibility as the basis for determining whether an object is garbage.
Moreover, since you're talking about resources in general, I hope you don't expect GC to automatically manage things like filehandles, network resources, references to CORBA objects, etc.
That's true, but the "ownership" can change. Example: Internet Chess GUI - as long as you are playing the game, it's the server which updates the current game - when the game is finished you (and the GUI) get exclusive rights about editing and changing the game.
That still doesn't require garbage collection. one could do it by using a dynamic policy object, or something like that.
I disagree. A problem domain *may* give a clear resource ownership model (so you are right in this sense), but then there is absolutly no proof that this model can hold if you are making changes which are still perfectly consistent with OO.
That's a pity, because garbage collection is a resource management model, which typically uses accesibility as the criteria for deletion. It is also possible to abuse it if one is ignorant of the way it works. In particular, if accesible objects accumulate, you have a memory leak. I think it's dangerous to view garbage collection as a sort of magic pixie dust that takes care of everything.
That said, garbage collection is useful, and you've raised a few examples as to where one could benefit from it. Of course, one can use garbage collection in C++, just as they can use any other model (-;
Re: your example, I don't see why this is a problem. You have the graph reference-count its own nodes.
You certainly don't want to share nodes between different data structures, or different graphs. This will put you on a fast track to madness.
And why did this happen?
Because the programmers designed their data structures in bad faith ? (-; Just kidding. I can see your point, in that if you have relationships between objects sufficiently complex, garbage collection may be a good strategy. One obvious (though trivial) example would be a possibly cyclic graph where you don't want to nodes that are inaccesible from a base node. In fact implementing this policy manually amounts to implementing garbage collection. Other strong candidates for GC would be examples that have similar complex relationships between objects (directly or indirectly self referential data structures)
Look, you guys keep saying "ownership" as if it is the magical solution to memory allocation.
If things were simple enough that you could define a clear policy of "ownership" and stick to it, then you wouldn't leak memory in the first place. Memory leaks happen because the ownership model was not specified clearly enough, or because it wasn't followed, because someone didn't understand all the possibilities that could happen at run time.
There is an ownership model, whether you know it or not. The difference is that C++ programmers are not ignorant of the fact that memory is allocated, and the "magic garbage collector" will clean it up. The garbage collector is far from magical. The model used in reobust garbage collection strategies is one of accesibility -- an object is considered "garbage" if and only if it is not accesible. This has some important consequences. In particular, you had better understand that if you want a resource disposed of, you need to render it inaccesible. If accesible objects are allowed to accumulate, you will get a memory leak in garbage collected software.
Using garbage collection is not a license to be ignorant. Rather, it is putting to use one of the many strategies that can be used to manage memory.
And if an object is in more than one list? It has to be copied anew? What if it doesn't make sense to copy/clone it?
You can store reference counted objects in lists just fine. Or you can store non-reference counted objects. Or you can store garbage collected objects. Or you can store pointers. In fact, you can store just about anything besides objects with destructive copy semantics.
All I'm saying is that the node structure of the list shouldn't be reference counted.
I'm interested in your comment that Lisp and C++ have different design goals. Common Lisp is designed to provide the programmer with a flexible, robust, object-oriented environment, suitable for large programming tasks. How does that differ from C++'s stated goals?
First, as stated, the goal is very general. It's all well to aim to provide the best of everything, but what design choices and trade-offs are involved ? Basically, the "goal" you've stated doesn't mean very much by itself.
Moreover, I don't believe that you're correct. Lisp AFAIK started out as a functional programming language, and Common Lisp added objects much later.
As for the design goals of C++, one of the major goals is compatibility with C. This was considered important for the language to be easily and widely adopted. A closely related goal is performance.
Performance takes precedence over purity.
Another goal is flexibility -- it is a multi-paradigm programming language, and has been from day one. This is in stark contrast with languages that claim to be pure object oriented.
1) having to distinguish between different kinds of ownership means you have to restrict your design to fit the memory management model. This is progress? In Lisp, it is relatively common, for instance, to create circular lists to represent arbitrarily-long periodic sequences. With reference counting, your "list" abstraction either isn't abstract enough to handle this, or this usage has to be forbidden or made a special case.
If shared ownership is not a good model (which it is not with any node based data structure), then don't use it. For a linked list, the obvious ownership strategy is for the list to own the nodes.
In reference counting, you spend time incrementing and decrementing counters even if the thing never becomes garbage. An object only becomes garbage once (ignoring certain finalization or "weak pointer" issues), but you pay many times.
Incrementing and decrementing counters is a very fast operation. It's only a performance issue if your object can be copied very quickly.
The main overhead issues in reference counting are
memory overhead (for very small objects), and
multi-thread overhead.
It's truly amazing to see the turnaround. The beef against Lisp used to be "perhaps powerful, but too bloated and slow."
There's nothing wrong with LISP, but it's kind of silly to compare it with C++. The design goals, and hence the benefits are not even moderately similar.
If the object is "observer" and not container, or child, it's for a good reason... the object is generally owned by someone else.
I guess the key question is, who is it owned by.
Whoever owns the resource is responsible for acquiring and releasing it. If views don't have any legitimate claim of "ownership" to documents, they shouldn't own counted references to them either (this amounts to them having a shared ownership of those documents). This is probably a good example of a case where a reference counted model leads on a fast track to chaos.
Unfortunatly memory mangement is orthogonal to problem domain.
I don't see how. Memory management is about resource ownership, and that is very much related to the problem domain.
For instance if you have a Document/View design, then each you want each View to have a reference, necessarily counted, to the Document(s). But then as Views are observers of
Documents, Documents have reference to them. Now assume that the Documents are actually instances used internally out of the GUI, that you temporary examined and brought back to the GUI through Views: lots of fun to find out how to manage memory allocation. But the most important is one such requirement "be able to interact with object XXX via GUI" can ruin your memort management strategy, and if your programs gets big enough, and is managed by many people, it will.
In this particular case, I'd suggest that the document should probably be managed by some other party.
The document will be closed at some point, either
by the application itself, or by a user event. In any case, I don't see a document as a very strong candidate for a reference counted model under normal circumstances. If there were some kind of distributed document editing application, where several users shared an open document, the document needs to be reference counted, but it is the users who "own" references to the documents, not the views.
What Qt does is a little different from GC. It uses parent/child management. Parent objects delete their children, and everything is free store allocated. This memory model works quite well, because you never (or very rarely) want a child widget to outlive its parent, so it's transparent to the programmer.
Reference counting does not count as true garbage collection, because
1) it does not deal with cyclic references (such as you would get with a doubly-linked list, or with an Observer pattern)
In both of these examples, reference counted memory models just don't make sense. In the case of the doubly linked list, the obvious ownership strategy is for the list to own its nodes. The nodes should not own other nodes. In the observer pattern example, one approach would be for the observer to own everything. This approach makes sense since the observer sees everything.
C++ allows you to choose a memory management model that fits the problem domain. In some cases, reference counting is a terrible model. GUI programming is a great example of where it would be a bad model (which is why Qt uses a tree based memory management strategy)
This is a red herring. One uses reference counting when shared ownership makes sense. Mutual ownership is at odds with "shared ownership".
2) you have ignored any time performance. Reference counting adds overhead even if you never accumulate a significant amount of garbage.
The overhead is very small unless you use copy-on-write, or the objects are very small. You only pay during construction, destruction, and assignment. And even then, the cost is substantially less than that of a deep copy.
For very small objects, there are other memory management strategies that are more suitable than
reference counting. These can also be implemented in C++.
In the code you're giving as an example, there is no advantage to an::add implementation. But I'd argue that's because you're overlooking the simple fact that there is an implicit overloading of the assignment operator. And it's still hiding implicit calls to other functions that may be computationally expensive. If there is a good answer to keeping computational efficiency in such situations using C++, I haven't seen it.
First, how is this a problem with operator overloading, and why is this only an issue in C++ ? I'd argue that "value" behaviour, as opposed to the reference behaviour of perl, python, java, etc is the culprit.
Second,
Maybe you haven't looked very hard. There are a number of ways. One is for operator+() to return a placeholder, and have the assignment accept the placeholder as an argument. There are actually toolkits implemented that use this approach, and it can provide very fast computation. (For example, the naive method of computing A * B^-1 is not the most efficient)
As you may have guessed by now, I don't use C++ for anything that needs to be super-efficient. It's not for lack of trying.:)
That's too bad. I've used it for a lot of things that need to be efficient, and it beats the hell out of trying to do it in C.
Did you realize that, in coding this way, you invoke a Matrix constructor and destructor every single time you use such syntax? This is the kind of hidden cost that just kills program efficiency.
Not true. There are a lot of ways around this. One of them is to use a reference counted matrix class, which is actually what a lot of programming languages already do (eg: Python, Perl) or use some other form of managed reference (eg Java, and several other languages)
The problem here has absolutely nothing to do with operator overloading, it has a lot to do with the fact that a naive implementation of a matrix will use an object that behaves like a reference, whereas a naive implementation in most other languages would have matrix objects that act like references.
"IT" in "it is still controlled by Microsoft" referred to.NET not ECMA
Yes, right. I wanted to make the distinction clear.
FYI, I'm not a great fan of cloning all of.Net, except as a way to pre-empt probable additions to the standard. In particular, I don't think turning it into some kind of WINE is a worthwhile goal. But then, it's not Miguels goal either.
[ snip: examples ]
At least three examples of perl functions that don't make much sense under Windows are chmod() and symlink(), and ioctl(), in fact the problem here is that the file functions are modelled around the UNIX filesystem.
As for myself I like the occasional magic that makes Perl work,
I actually like perl for some things, I just don't see it as an exemplar of a standard, cross-platform language. The two best aspects of Perl are CPAN and the fact that it's very easy to use if you already know how to write bourne shell scripts.
Sorry if this became offtopic, this is an old discussion anyway, but it is just nice exchanging ideas.
Yes, to all the above. Time to check "no score +1 bonus". Cheers,
I don't quite agree with this. I agree more with your later comment -- standards tend to codify existing practice.
b) Incompatibilities with the standard are generally fixed by changing the standard or referring to the 'reference implementation' (DCE, Kerberos, C++...).
I'd think that if something is defined by a "reference implementation", it isn't much of a standard. Standards codify existing practice, so if an idea is widely adopted,
or there is a consensus that the idea is a good one,
there is a good chance it will end up in the standard. For example, variable length arrays, and C++ comments were vendor extensions. However, since the standards body is non-partisan, extensions that are blatantly vendor-dependent do not get added. That is why we don't have POSIX, COM or Win32 or even MFC in ISO/ANSI C/C++.
Slashdot Mirror
No, it's not a red herring. The fact is that your viewpoint that it's acceptable is not a widely held one. I do address the "personal responsibility" point.
Wel, that's bull, and the chinese citizens should be taking their actions against the companies that are dumping the stuff - i.e. their own people.
Yes, to the extent that they have the means to do so. However, you shouldn't be paying people to dump it in their back yards.
Yes, your reply is nonsense, and you failed to address the rest of my points which clarified it.
No, it isn't nonsense at all. The mercenaries analogy is perfectly analogous, IMO. If you pay a waste disposal (nudge nudge, wink wink) company to dump your trash in someones back yard, you are responsible.
Try and get that one past the human subjects guidelines in America. Good luck! You might consider it ethical, but fortunately, the research community here does not.
But Dr. Spork, idiots like you (normally I don't flame, but I do believe in "tit for tat") feel that personal responsiblity extends only to things that you don't find too confining, or too difficult to do.
I think you've got that wrong. People like you want to create waste, and not take responsibility for its disposal. You also want to hold ordinary Chinese citizens responsible for the actions of companies that they can't control.
The government has come up with a solution, we are not responsible for all the worlds ills.
Dumping your shit in someone elses back yard is not a "solution". Your red herring about grain is just that.
As I stated earlier (something you failed to address) it isn't as if we are the ones spreading it on the countryside, we pay them money to dispose of the stuff. At that point (believe it or not) It's the responsibility of the ones taking the money to do the right thing by it.
Nonsense. If you pay the lowest bidder to dispose of your waste, and you know that they're cheap because they're dumping it in the river, you are responsible. It's like hiring mercenaries to drive people off your land, and claiming that it's the mercenaries responsibility to do it ethically.
Come on. You want it sent off to the cheapest "waste disposal" or "recycling" company in China, and then you want to pretend that you don't know what they'll do with it ?
There are too many other responsible parties here that are DIRECTLY responsible to come after me with some tax or $30 increase on PC sales to try to resolve the problem.
The parties that produce the waste are responsible for safely disposing of it. Having China "ban" it does not solve anything, because you're still going to use the lowest bidder as your "waste disposal" company, and it will end up in a river in some other country.
First, the article does not say that the sovereign state of China buys it. Second, "China" is not a person. The analogy is just fine. You're paying some company in China to dump it in someones back yard.
Nope. A lack of global trade is an obstruction to social mobility. It results in an aristocracy of citizenship. There are obviously people with a vested interest in creating and maintaining such a thing (namely, lower/middle class citizens of wealthy countries). But a lack of global trade is certainly not good for curing wealth imbalances.
Creating a wealthy elite in third world countries will just raise local prices even further out of the reach of the poor, adding to the problems caused by local goods being sold at global (i.e. western) prices.
This goes against all existing experience. A country can use taxes and social problems to redress social inequalities. Currency increase is rarely bad for the economy. Countries with strong currencies have high standards of living, countries with weak currencies have low standards of living.
Also purely from a selfish POV, I don't want to see my salary capped because some shortsighted manager is trying to increase his bonus by reducing costs by exporting jobs overseas.
Right on! You are one of the people with a vested interest in maintain an aristocracy of citizenship, and you aren't really that interested in fairness. In fact, fairness probably isn't in the interests of most people in western countries
American companies ...
American companies have their own interests too. They are neither moral or imoral. They are indifferent to morality.
A start to a real solution at eliminating global wealth disparities would be for us to start importing grain
Question 21: Based on the above, the authors goal is:
Instead we currently prefer to subsidize domestic production thus keeping prices artificially high.
Now I'm confused. Is protectionism good or bad ? First you were saying it's good, and we need more of it, and now you're attacking it.
I think putting QA people on the job is a very good move. If they focus on bugfixes, running backtraces and fixing core dumps, and that sort of thing, it's probably a lot easier for them to contribute than if they try adding substantial new features. The problem with Corel is that they wanted to substantially extend existing code, with their "innvative file manager" (yes, they really called it that) and other things.
I don't see why this is an enormous problem. If they're using Suns C++ compilers, they're already paying an arm and a leg as it is. I doubt SUn would have trouble negotiating a discount bundle-ware deal with Trolltech.
So, I think it is a C vs C++ thing. It's not just about what Sun know, I think the linkage issues with C++ are probably an issue (because you're stuck with whatever compiler was used to build the libraries).
BTW, a lot of the closed source apps developed on Solaris either have no GUI, are never released (in-house), or both.
The US, along with a small number of powers, do enjoy priveliged status on the UN. They are one of the few states with veto power, and they do use this to their advantage (namely, they can block resolutions condemning the US or Israel)
I don't understand your point about "majority support", 26% and 31% are not "majorities" by most measures.
What's this strange language called C/C++ that you are using ? If you really don't think the two are any different, maybe the problems are in part caused by the fact that you don't know how to use C++ properly. There's a big difference between using the occasional new/delete for a low level class, or for performance optimisation (which is what happens in C++), and having to manually allocate and free every string.
Well, I only very rarely run into problems caused by unmatched new and delete. These are rarely problems in practice. 99% of the memory problems I get are dereferencing a NULL pointer as a result of not checking that an operation succeeded. I've never run into "cycle" problems with reference counts in C++ code, because I don't abuse reference counting (reference counting, if misapplied causes more problems than it solves, as you've pointed out)
When you have GC, resource accumulation can occur if objects hold references that they are no longer using. There are cases where this can happen. An obvious example is an array implementation where removing from the back doesn't actually zero out the reference, so the array still holds on to the reference. More subtle and nastier examples include GUIs accumulating doodads (listeners, validators or whatever) that the user tacks onto a widget, and forgets about.
The problem is that a reference to an object might not be accesible to public member functions in that class. An example where this sort of thing is a potential problem would be a vector/array class. "Removing" an element from the end of the container doesn't necessarily involve deleting anything, it merely involves modifying a member variable. So you've got a reference that is being held, despite the fact that (a) the container is no longer using it, and (b) will not be released as a direct result of anything the user does. To make matters worse, the garbage collector reserves the right to clean up the container itself whenever it feels like it. This is not strictly speaking a memory leak, but it is a problem that occurs when containers do not release resources in a timely manner.
Garbage collection is about removing the accounting errors that lead to true memory leaks, which means you can focus your human intelligence on figuring out what resources your program needs to solve the problem it is working on.
Again, garbage collection is not a cure for ignorance on the part of the programmer. It's merely a strategy for managing memory that uses accesibility as the basis for determining whether an object is garbage. Moreover, since you're talking about resources in general, I hope you don't expect GC to automatically manage things like filehandles, network resources, references to CORBA objects, etc.
That still doesn't require garbage collection. one could do it by using a dynamic policy object, or something like that.
I disagree. A problem domain *may* give a clear resource ownership model (so you are right in this sense), but then there is absolutly no proof that this model can hold if you are making changes which are still perfectly consistent with OO.
That's a pity, because garbage collection is a resource management model, which typically uses accesibility as the criteria for deletion. It is also possible to abuse it if one is ignorant of the way it works. In particular, if accesible objects accumulate, you have a memory leak. I think it's dangerous to view garbage collection as a sort of magic pixie dust that takes care of everything.
That said, garbage collection is useful, and you've raised a few examples as to where one could benefit from it. Of course, one can use garbage collection in C++, just as they can use any other model (-;
Re: your example, I don't see why this is a problem. You have the graph reference-count its own nodes. You certainly don't want to share nodes between different data structures, or different graphs. This will put you on a fast track to madness.
And why did this happen?
Because the programmers designed their data structures in bad faith ? (-; Just kidding. I can see your point, in that if you have relationships between objects sufficiently complex, garbage collection may be a good strategy. One obvious (though trivial) example would be a possibly cyclic graph where you don't want to nodes that are inaccesible from a base node. In fact implementing this policy manually amounts to implementing garbage collection. Other strong candidates for GC would be examples that have similar complex relationships between objects (directly or indirectly self referential data structures)
If things were simple enough that you could define a clear policy of "ownership" and stick to it, then you wouldn't leak memory in the first place. Memory leaks happen because the ownership model was not specified clearly enough, or because it wasn't followed, because someone didn't understand all the possibilities that could happen at run time.
There is an ownership model, whether you know it or not. The difference is that C++ programmers are not ignorant of the fact that memory is allocated, and the "magic garbage collector" will clean it up. The garbage collector is far from magical. The model used in reobust garbage collection strategies is one of accesibility -- an object is considered "garbage" if and only if it is not accesible. This has some important consequences. In particular, you had better understand that if you want a resource disposed of, you need to render it inaccesible. If accesible objects are allowed to accumulate, you will get a memory leak in garbage collected software.
Using garbage collection is not a license to be ignorant. Rather, it is putting to use one of the many strategies that can be used to manage memory.
You can store reference counted objects in lists just fine. Or you can store non-reference counted objects. Or you can store garbage collected objects. Or you can store pointers. In fact, you can store just about anything besides objects with destructive copy semantics. All I'm saying is that the node structure of the list shouldn't be reference counted.
I'm interested in your comment that Lisp and C++ have different design goals. Common Lisp is designed to provide the programmer with a flexible, robust, object-oriented environment, suitable for large programming tasks. How does that differ from C++'s stated goals?
First, as stated, the goal is very general. It's all well to aim to provide the best of everything, but what design choices and trade-offs are involved ? Basically, the "goal" you've stated doesn't mean very much by itself.
Moreover, I don't believe that you're correct. Lisp AFAIK started out as a functional programming language, and Common Lisp added objects much later.
As for the design goals of C++, one of the major goals is compatibility with C. This was considered important for the language to be easily and widely adopted. A closely related goal is performance. Performance takes precedence over purity. Another goal is flexibility -- it is a multi-paradigm programming language, and has been from day one. This is in stark contrast with languages that claim to be pure object oriented.
If shared ownership is not a good model (which it is not with any node based data structure), then don't use it. For a linked list, the obvious ownership strategy is for the list to own the nodes.
In reference counting, you spend time incrementing and decrementing counters even if the thing never becomes garbage. An object only becomes garbage once (ignoring certain finalization or "weak pointer" issues), but you pay many times.
Incrementing and decrementing counters is a very fast operation. It's only a performance issue if your object can be copied very quickly. The main overhead issues in reference counting are memory overhead (for very small objects), and multi-thread overhead.
It's truly amazing to see the turnaround. The beef against Lisp used to be "perhaps powerful, but too bloated and slow."
There's nothing wrong with LISP, but it's kind of silly to compare it with C++. The design goals, and hence the benefits are not even moderately similar.
I guess the key question is, who is it owned by. Whoever owns the resource is responsible for acquiring and releasing it. If views don't have any legitimate claim of "ownership" to documents, they shouldn't own counted references to them either (this amounts to them having a shared ownership of those documents). This is probably a good example of a case where a reference counted model leads on a fast track to chaos.
Unfortunatly memory mangement is orthogonal to problem domain.
I don't see how. Memory management is about resource ownership, and that is very much related to the problem domain.
For instance if you have a Document/View design, then each you want each View to have a reference, necessarily counted, to the Document(s). But then as Views are observers of Documents, Documents have reference to them. Now assume that the Documents are actually instances used internally out of the GUI, that you temporary examined and brought back to the GUI through Views: lots of fun to find out how to manage memory allocation. But the most important is one such requirement "be able to interact with object XXX via GUI" can ruin your memort management strategy, and if your programs gets big enough, and is managed by many people, it will.
In this particular case, I'd suggest that the document should probably be managed by some other party. The document will be closed at some point, either by the application itself, or by a user event. In any case, I don't see a document as a very strong candidate for a reference counted model under normal circumstances. If there were some kind of distributed document editing application, where several users shared an open document, the document needs to be reference counted, but it is the users who "own" references to the documents, not the views.
But reference counting often is. For example, the g++ implementation does use reference counting, so the example offered should perform as well as +=
What Qt does is a little different from GC. It uses parent/child management. Parent objects delete their children, and everything is free store allocated. This memory model works quite well, because you never (or very rarely) want a child widget to outlive its parent, so it's transparent to the programmer.
In both of these examples, reference counted memory models just don't make sense. In the case of the doubly linked list, the obvious ownership strategy is for the list to own its nodes. The nodes should not own other nodes. In the observer pattern example, one approach would be for the observer to own everything. This approach makes sense since the observer sees everything.
C++ allows you to choose a memory management model that fits the problem domain. In some cases, reference counting is a terrible model. GUI programming is a great example of where it would be a bad model (which is why Qt uses a tree based memory management strategy)
This is a red herring. One uses reference counting when shared ownership makes sense. Mutual ownership is at odds with "shared ownership".
2) you have ignored any time performance. Reference counting adds overhead even if you never accumulate a significant amount of garbage.
The overhead is very small unless you use copy-on-write, or the objects are very small. You only pay during construction, destruction, and assignment. And even then, the cost is substantially less than that of a deep copy.
For very small objects, there are other memory management strategies that are more suitable than reference counting. These can also be implemented in C++.
First, how is this a problem with operator overloading, and why is this only an issue in C++ ? I'd argue that "value" behaviour, as opposed to the reference behaviour of perl, python, java, etc is the culprit.
Second, Maybe you haven't looked very hard. There are a number of ways. One is for operator+() to return a placeholder, and have the assignment accept the placeholder as an argument. There are actually toolkits implemented that use this approach, and it can provide very fast computation. (For example, the naive method of computing A * B^-1 is not the most efficient)
As you may have guessed by now, I don't use C++ for anything that needs to be super-efficient. It's not for lack of trying. :)
That's too bad. I've used it for a lot of things that need to be efficient, and it beats the hell out of trying to do it in C.
Not true. There are a lot of ways around this. One of them is to use a reference counted matrix class, which is actually what a lot of programming languages already do (eg: Python, Perl) or use some other form of managed reference (eg Java, and several other languages)
The problem here has absolutely nothing to do with operator overloading, it has a lot to do with the fact that a naive implementation of a matrix will use an object that behaves like a reference, whereas a naive implementation in most other languages would have matrix objects that act like references.
Yes, right. I wanted to make the distinction clear. FYI, I'm not a great fan of cloning all of .Net, except as a way to pre-empt probable additions to the standard. In particular, I don't think turning it into some kind of WINE is a worthwhile goal. But then, it's not Miguels goal either.
[ snip: examples ]
At least three examples of perl functions that don't make much sense under Windows are chmod() and symlink(), and ioctl(), in fact the problem here is that the file functions are modelled around the UNIX filesystem.
As for myself I like the occasional magic that makes Perl work,
I actually like perl for some things, I just don't see it as an exemplar of a standard, cross-platform language. The two best aspects of Perl are CPAN and the fact that it's very easy to use if you already know how to write bourne shell scripts.
Sorry if this became offtopic, this is an old discussion anyway, but it is just nice exchanging ideas.
Yes, to all the above. Time to check "no score +1 bonus". Cheers,
I don't quite agree with this. I agree more with your later comment -- standards tend to codify existing practice.
b) Incompatibilities with the standard are generally fixed by changing the standard or referring to the 'reference implementation' (DCE, Kerberos, C++...).
I'd think that if something is defined by a "reference implementation", it isn't much of a standard. Standards codify existing practice, so if an idea is widely adopted, or there is a consensus that the idea is a good one, there is a good chance it will end up in the standard. For example, variable length arrays, and C++ comments were vendor extensions. However, since the standards body is non-partisan, extensions that are blatantly vendor-dependent do not get added. That is why we don't have POSIX, COM or Win32 or even MFC in ISO/ANSI C/C++.