User talk:James Dennett

Some kind soul left me these references...

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.

C++ Programming
I see you've started contributing to this book again. I just wish to say thanks for your corrections to errors and am glade to see you've decided to start contributing to this book again and hope you will continue to do so. --dark lama  00:29, 6 December 2006 (UTC)

Thanks for the encouragement; I don't know how much time I'll have to contribute. It rather depends on how worthwhile (or, to look at it differently, how futile) it seems. Last time I tried to work on the predecessor of the C++ wikibook, I found that mistakes were being added faster than they could be corrected, and re-added after being corrected; there were some contributors with more time than (correct) knowledge. (On the other hand: if I do get something wrong, please fix it, and ideally tell me.  I like it when I learn I was wrong about something, even more than I hate the fact that I was wrong in the first place.)  James Dennett 05:27, 6 December 2006 (UTC)

My hat's off to folk including User:SBJohnny and User:Swift who invest so much in trying to make wikibooks work. -- James Dennett 10 December 2006

It seems appropriate to acknowledge their work by giving this one more try; I've added some new material to the C++ Programming book, and saw somewhere that dark  lama  might have persuaded someone else to contribute. In a cooperative environment it shouldn't take a lot of people to make good progress.

Let's hope that past troubles can stay in the past. There are plenty of people here who care passionately about doing good work, and it can be tough to yield to others in the community, and to truly accept that once we write something on Wikibooks it is, in a very real sense, no longer our private property, but rather a common good.

(And if it doesn't work out, I hope I can disappear as quickly as I came in, leaving small ripples that soon die out!) -- James Dennett 00:24, 11 December 2006 (UTC)

Glad to see you decided not to leave after all. Completely true, all we can do is try to work together to make great books. --dark lama  01:32, 11 December 2006 (UTC)

I'm afraid it'll have to be other books that I help with after all; the C++ Programming situation is still not viable, for me at least, in spite of the efforts of various admins and others. I wish those who continue the best of luck; as I've noted elsewhere, the release of the next C++ standard (hopefully in 2009) might be a good time for me to try again, perhaps with a separate book if The Powers That Be find that appropriate. -- James Dennett 23:34, 25 April 2007 (UTC)

C++ Programming/Classes/Polymorphism
I'm curious about your motivation behind making a distinction behind dynamic and static polymorphism, as far as I know, C++ doesn't make any distinction.

I'd also be curious to know what you think about combining the bits within Abstract Classes and Pure Abstract Classes into the chapter on Inheritance. C++ AFAIK, doesn't really make a distinction between classes and other sorts of classes, but it does related to inheritance in the sense that an abstract class is typically used as a base or parent class for a derived or child class. I'm not entirely sure what to do about the "nice class" information. I was thinking maybe it makes more sense in the general Classes chapter, but then the Classes chapter seems to be missing information on operator overloading and probably shouldn't be introduced until operator overloading has, so I've though maybe it makes since in the operator overloading chapter instead. --dark lama  03:03, 11 December 2006 (UTC)

The distinction between static and dynamic polymorphism is applicable to C++; alternative terms are compile-time and run-time polymorphism. Various kinds of polymorphism are supported in C++; templates provide one or two kinds of static polymorphism, overloading provides a form of static polymorphism, and runtime/dynamic polymorphism (which is commonly, if loosely, often just called "polymorphism") is of course based on the virtual dispatch mechanism. Having thought about this a little though, I think this might be best covered as a small diversion for context, and then the book could state that it will use the term polymorphism only in the context of dynamic/runtime polymorphism, specifically the features supported by virtual functions in C++. Presentation could be too awkward if the term "polymorphism" is qualified every time it is used, and there is occasion to speak of polymorphic classes (such as if we get around to saying what typeid does in detail).

It would seem to me that it does make sense to include discussion of abstract classes with the material on inheritance.

Off the top of my head, it might be good to cover classes in a number of phases; first introduce concrete classes (without any operator overloading), then introduce inheritance, then virtual functions, and then operator overloading. Alternatively operator overloading could be covered before inheritance; I can imagine a good case can be made for either order. There might even be room for another "advanced" chapter on classes to cover things like class-specific operator new/operator delete, techniques to restrict inheritance (and why they're a bad idea), the "pimpl" idiom, and more.

The term "polymorphism" is indeed not used much (if at all) in the C++ standard, but then the standard isn't trying to be a tutorial. It might make sense for us to link to Wikipedia material on different types of polymorphism rather than trying to rewrite it all here -- it's a CS notion much broader than C++, and I figure we might want to give only a brief overview of the general idea and focus on the C++ aspects.

No idea on "nice classes". I'd have to take a look. Might do that sometime. -- James Dennett 06:08, 11 December 2006 (UTC)

Generally I understand polymorphism in C++ to refer to classes such that transparently one class may be treated as another through the use of virtual functions and multiple inheritance. I think it may be confusing to refer to function overloading and the use of templates as forms of polymorphism. I admit I'm of the opinion that a book on C++ should compliment the C++ standard. I don't think its necessary to cover the broader CS notion to explain polymorphism as it applies to C++. I agree that a brief overview of the general concept makes sense, but I think it should focus on what it means in terms of its usage in C++.

There's a difference here with regard to using links from how it is on Wikipedia. Books are for the most part suppose to be self contained so that any information needed to learn the subject is available in the book, rather then relying on outside information to provide it. So while linking to Wikipedia material sounds like an easy solution, I don't think it makes sense.

A nice class in summary is basically one with copy constructors and provides operators with the expected operations of that operator and does so safely. For example overloading = is expected to involve assignment of one class instant to another and check to make sure that both aren't the same class when doing so which if failed to do can lead to memory leaks if assignment involves allocating memory with new. --dark lama  07:20, 11 December 2006 (UTC)

I think our viewpoints on the use of the term "polymorphism" here aren't far apart. We shouldn't get too bogged down in generalities; it would be nice to at least mention that there *are* more general notions that apply. I still feel that a link to Wikipedia would be helpful as a supplement, but I'm not all that concerned either way.

The only thing that seems to set a "nice" class apart from other working classes are that it allows copying, and it allows comparisons for (in-)equality. Fair enough. I've done some minor fixes in that section recently (as it said that the default copy operations are binary, which seems untrue).

Time for me to sleep; happy editing. The new front page is great, incidentally.

-- James

I think the broader meaning of polymorphism could be discussed earlier in the book where general programming concepts are introduced with as you said a note regarding thhe use of polymorphism as it applies to C++. The entire introduction chapter is in need of a rewrite, and thats the main part of this book that I'm going to be concentrating on for now. If you want to pitch in I'm all for it. To get an idea of what I have in mind you might wish to read (if you haven't already) the discussion that took place in regarding to doing just this. I've already begun the first steps twards this aim in C++ Programming/Programming Basics if you want to take a look.

I agree with your ordering for teaching classes. I think this book could use a chapter on advance classes as well. Both to cover mixing everything thats been taught previous about classes, and to introduce things like overloading the new and delete operator. Might even be the best place to discuss "nice" classes and other good tips for using classes effectively. So maybe all that needs to be done for the nice class page is to change the name and expand its focus. --dark lama  17:44, 11 December 2006 (UTC)

Essences
I noticed you changed the TOC2 Print version to say Essentials instead of Essences. Any reason for that?

Essences (n): The intrinsic or indispensable properties that serve to characterize or identify something.

Essentials (adj): Constituting or being part of the essence of something; inherent. --dark lama  22:39, 13 December 2006 (UTC)


 * Sure, but if you have a strong preference, change it back; it seems an odd place to use the term "essences". It's a question of the "feel" of a word, if I can be vague (and it seems that I can, for better or worse).  "Essences" struck me as seeming non-idiomatic in this context, something that would most likely be written by a non-native speaker.  Not that you seem to be one (nor is there anything amiss about the majority of the world's population who don't speak English as their first language, come to that).  I guess in the end I just feel it's more readable to most people as "Essentials".  If you'd like to challenge people to "think differently" then "Essences" will quite possibly do so.  (Or maybe this is a US/UK English thing; I'm British, though living in the US.  I've noticed that some fraction of things that strike me as poor English are just poor English by British conventions, and are idiomatic elsewhere.  Similarly the other way around.)  Incidentally, I'm assuming you're watching this page, having left notes here... -- James Dennett 23:26, 13 December 2006 (UTC)


 * I am a native US English speaker (but my spelling and grammer tends to end up bad anyways, without comparing color to colour), however I was actually going for a word similar in meaning to essential, so I ended up going with essences in order to avoid using the word essentials twice. I think its going to be a mute point anyways, as I was thinking of combing the two sections together and renaming it to maybe "The Essentials", soon anyways. I was just wondering if there was more to it, like in preperation for futher changes, so as not to step on your toes if you were in the middle of doing something. I'm somewhat watching this page. I don't have it on my watchlist, but I am checking it maybe once or twice a day, if I see any activity from you. I don't have it in my watchlist, because it seemed to me, like you don't really look at this page much yourself. --dark [[Image:Yin yang.svg|12px]] lama 00:43, 14 December 2006 (UTC)


 * Nice of you to include "grammer", "mute" (for "moot"), "preperation" ;-) but luckily one thing Wikipedia and Wikibooks are good at is having people who know things write them down, and then wikignomes can come along and fix the trivial things. (Yup, I'm some kind of spelling/grammar freak.)  As for me watching this page; when I'm active on Wikibooks, I'll watch it.  "Free" time comes and goes.  One of my writing flaws, getting back to the subject at hand, is a tendency to repeat words when it might be better to use a synonym or to rephrase.  So maybe one of us should revert my change.  It's a pretty minor issue, sure, but I suggest you just do whatever you feel is best; I'm not going to "fight" about such a thing, now that I know it was a deliberate choice.  Today I've been working mostly on the memory management section.  It's maybe 35% done, to give a ridiculously over-precise and under-accurate estimate. -- James Dennett 04:21, 14 December 2006 (UTC)

C++ functions
Now that you mentioned malloc/free, I'd like to mention that I was of the opinion that we should be calling these std::malloc</tt>, <tt>std::free</tt> in the text, and we should not be using the <tt>using namespace</tt> construct, so the readers will get a better grasp of the correct way to use namespaces earlier in the book (that would just be a few simple "find-&-replace"s but could go a long way in ensuring we teach namespaces correctly). -- Paddu 20:44, 15 December 2006 (UTC)


 * I'd like to go the way, certainly (indeed, I recently removed the "using namespace std;" directives from a moderately sized commercial project). You might notice that examples I've added use std:: qualifications.  (And in my own code I'm sometimes, just sometimes, crazy enough to write ::std for the namespace name!) I'll mention the idea on the Talk:C++ Programming page and if nobody objects I'll do some of the "busy work" soon. -- James Dennett 20:49, 15 December 2006 (UTC)


 * Sounds good to me. I think "using namespace std;" teaches bad habits. I think we even should explain why its a bad idea to make use of it in the chapter on Namespaces (eg because its clobbers/pollutes the namespace). --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark [[Image:Yin yang.svg|12px]] lama 00:43, 16 December 2006 (UTC)


 * I've started to change bits and pieces of the code to this style, as I see them. Probably there are better ways.  Tips are welcomed. -- James Dennett 03:26, 17 December 2006 (UTC)

casting without type conversions
Txs for the input, now I know a little more. --Panic 05:24, 29 December 2006 (UTC)

Arbitration Decision
I have stepped in to deliver a decision for the arbitration which I believe has gone on long enough. Please see my decision page and write on my talk page if you have a response. Thanks. -<font color="#000000">within <font color="#7A7A7A">focus 23:03, 31 January 2007 (UTC)


 * I see no need for further comment. Enough has been said.  Thank you for your contributions. -- James Dennett 23:09, 31 January 2007 (UTC)

Where's this all going?
Now the "Dispute Resolution" page has gone, and redirects to Panic's talk page? That seems odd to me. Also, large fractions of the text that were there are no longer present (they are, of course, in the histories for those who go and look). Seems that we're going backwards again. We need this discussion to happen in one place, that won't move around, with some clearly defined goals and a visible, updated current status being prominent. I do appreciate your willingness to help -- just trying to avoid repeating history (as recent history in this case has not been good for the community). -- James Dennett 04:17, 28 February 2007 (UTC)
 * I was asked to 'perhaps' move the discussion to Panic2k4's talk page so he can edit even when blocked. Since he removed the page I have restored it on the original location. -- Cat out 15:51, 28 February 2007 (UTC)

I was going to use TOC2...
But I suppose I will take a look at TOC1 and see what would be the best course of action. --Remi 21:02, 2 March 2007 (UTC)


 * I rather like TOC2 myself! -- James Dennett 22:03, 2 March 2007 (UTC)

Passing array through reference
Now I know that it is possible. Thanks for your response. I didn't note that when I studied template. -- Ron Lau 07:15, 28 March 2007 (UTC)

Re:C++/TOC
Hello James. I certainly feel your frustration on the matter, sometimes it seems that people would rather argue then come to any sort of compromise. When this happens, I agree that it's usually best to find a new project to work on. There are certainly plenty of books available, especially programming language books. I am even planning to create a few new books, once I have the time to do it. What other kinds of things are you interested in? what other programming languages? I've got a book right now on Microprocessor Design that i'm putting some serious effort into, and there are several books that i've worked on in the Assembly Language realm, if any of that is your cup of tea. Also, I know that the C Programming book is in lousy shape (comparatively) and could use some helping hands.

I've thrown around the idea of creating two C++ books before, but that idea met with the usual resistance, as you can imagine. The people who don't want a second C++ book are generally the same people who stay far away from the problems in the first book, however. It's never ending, and you are a saint for putting up with it all for this long. --Whiteknight (talk) (projects) 00:46, 26 April 2007 (UTC)


 * I don't think canonization is likely in the near future... ;)


 * I've worked fairly extensively with only a couple of assemblers (ARM, 6502), moderately with a couple (POWER/PowerPC and MIPS), and less with others. x86 is largely a mystery to me.  I'm competent to contribute usefully on C and various other languages in that family, or on Perl, and can brush up on my Smalltalk, Haskell, Python, Modula-2, Ada, and some others easily enough.  I'll have a look at the C book in a little more details (I've briefly glanced at it in the past) to get a feel for it and its community, and see if there's anything useful I can do there; thanks for the pointers. -- James Dennett 03:37, 26 April 2007 (UTC)


 * I've decided to start a new C++ book, in response to the problems with the existing one, since it is very unlikely to ever be resolved. The book is directed at readers who have no experience in programming, but who have enough knowledge about using the operating environment of their choice, to be able to install and use a compiler without needing to explain it to them in this book. This book is only going to cover standard C++ and common programming constructs that are portable, like creating linked lists, hash tables, trees, etc. Things like graphic libraries aren't going to be covered. I would also like to emphases throughout the book, good habits to have and things to watch out for or to avoid, in order to avoid making bad assumptions or writing non-portable code. Of course having fun writing about it is also a must. If your interested you can take a look at Understanding C++.
 * I haven't done much yet, the first chapter Introduction is trying to take the approach of discussing the basics of programming starting from general and ending in more detailed information with an emphases on a C++ perspective throughout. I'm hoping to give enough information for readers to have insight into what programming is all about and what this book is going to cover with links to chapters for more information. For myself I would prefer to have this more or less done first, before any other chapters are added, sine I think it will provide a good guide or roadmap of what to cover in each chapter. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  17:38, 2 May 2007 (UTC)
 * I've also started a style guideline for the book under Understanding C++/LMOS, to have some of my ideas for providing consistent style for the book written down. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  17:45, 2 May 2007 (UTC)

Understanding C++
I haven't really decided on a single approach yet. One approach that comes to mind though is mixing both high level and low level together. For example teaching both the basic variables types as well as the ones provided through the standard library in the same chapter, side by side. Making little distinction between high level and low level, since part of C++ is about abstraction. I'm also thinking about maybe covering pointers and references in the same chapter, and touching a little bit on new, delete, unions, structs and classes. Maybe in a later chapter covering new, delete, unions, structs and classes in more detail, and point out how some of the standard types that have been used so far like string are implemented using classes. I don't think the approach of separating based on a specific aspect of C++ is going to be used, like seems to be done in a lot of books. Hopefully better emphasizing the importance of learning all aspects of C++ and providing a better insight of both the whole picture and C++'s parts. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  21:20, 2 May 2007 (UTC)


 * Interesting. The key thing, to me, is to have a coherent way of getting the first few chapters to lead people to feel that they're achieving something.  Which suggests leaving new/delete and pointers until later, as they don't add new capabilities for a while, from a beginner's perspective.  But maybe we can work awhile on sketching some plausible outlines and documenting their rationales, so choose one we would wish to pursue.  And maybe we should discuss this on a more public place than our talk pages? ;) -- James Dennett 23:20, 2 May 2007 (UTC)


 * We can discuss this on Talk:Understanding C++ if you wish, it doesn't really mater to me, whichever you would prefer. I agree a plausible outline is needed, which is why I've been holding off adding the book to a bookshelf and making its existent more prominent. I figure a small group of people working out the details would be better for the book in the beginning then a large crowd, if such a crowd exists. I would love for readers to come away from every chapter feeling like they've achieved something. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  00:35, 3 May 2007 (UTC)


 * Agreed, I'll move my thoughts there. (And it's true that design-by-small-group works better than design-by-committee, aka design-by-large-crowd/mob.) -- James Dennett 05:07, 3 May 2007 (UTC)


 * Alright. I wasn't initially going to reply to this, because I thought you would go ahead and begin discussion there, but thought after 2 days maybe you were waiting on some sort of response from me first. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  18:25, 5 May 2007 (UTC)


 * No, just dealing with The Real World. I'll be back when time permits. -- James Dennett 22:58, 5 May 2007 (UTC)

It has been awhile and I have found myself stuck on how to move forward, I still don't have a decent outline/plan/notion for tackling the subject. I know every aspect of C++ that needs to be covered, but maybe my lack of teaching experience on the topic is blocking me from seeing any easy way to teach C++. I could use your creative inspiration on this. You have mentioned using a top/down model for teaching C++. When I think of a top/down or bottom/up model I always think of a pyramid. Is a pyramid the wrong way to think about this? What do you consider to be the rough/top of the pyramid? What do you consider to be the foundation/bottom of the pyramid? How would you teach C++ using a top/down model? Can you provide some examples? I think figuring that out has turned out to be the hardest part for me. Once I have a decent idea of how to teach C++ using a top/down model, the rest in theory should come easily. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  12:14, 9 March 2010 (UTC)

About manual memory management with new, delete etc.
James,

Could you clarify what you're basing the you finding in this section on?

"Modern C++ code tends to use new quite rarely, and delete very rarely."

Wouldn't code use delete precisely the same amount as new, in order to avoid memory leaks?

"Heap allocation times are much slower than allocations off the stack."

Isn't this completely negligent considering the real bottlenecks of modern software systems on modern hardware?

"However, there are still times when it's appropriate to do so"

I would say that there are many more times than you lead people to believe, where it makes no sense from a design standpoint to allocate your memory off the stack, as far as object lifetime or object size is concerned.

You also make no mention of stack size limitations.

--Shomron 09:21, 13 June 2007 (UTC)


 * When I note that delete is "used" less often than "new", I mean that it appears in fewer places in source code. Obviously it must be executed the same number of times.


 * In some kinds of work, heap allocation times may be negligible; in many fields, it's simply untrue that it doesn't matter. Busy servers, embedded systems, high-performance computing, games, and more, still need to care about performance, and dynamic allocation in tight loops can be a killer.  Much of the optimization work I've done in the past has come down to reducing the amount of dynamic allocation performed (in C++, Java, C and others).  The other big bottleneck I see these days tends to be excessive synchronization between threads, or poor use of parallelism in databases, but that's an aside.


 * Obviously we cannot cover every factor in choosing memory allocation patterns in a book that's intended to teach C++, otherwise we would end up teaching every related aspect of software engineering. My note about times when it's appropriate to use heap allocation is intended to acknowledge situations such as limited stack sizes (which are common in embedded or multi-threaded applications) and others, without getting into too much distracting depth.


 * Naturally, if you think you can make the text better... it's a wiki. Go ahead and contribute.  I'm no longer actively working on this book. -- James Dennett 22:18, 13 June 2007 (UTC)

Thankyou
I appreciate all the work you've done with this book. I have been reading through it (I'm just up to dynamic memory allocation), and I should of seen those mistakes that you fixed on the preprocessor section, but awell you fixed it =) Hope you can keep making this book better, rawrawrer (talk) 07:15, 23 April 2008 (UTC)

C++ Programming/TOC2
A VFD on the TOC2 page was initiated (27 July 2008) and then closed (30 July 2008) by Mike.lifeguard, if Wikibookians wish to express concerns about the speedy action they can use this page, You may restate your points (or post part of the your discussion there). --Panic (talk) 23:54, 30 July 2008 (UTC)

"garbage collected implementations of C++"
Is this what you intended ? I see it as a contradiction, to include a default garbage collection into the C++ language we would not have a C++ implementation, but something else, I also attempted to locate something that validated you change and came out empty were you referring to D ? I don't think the new wording and referring other languages on that section is an improvement to clarify the point. A better place to advance that issue, if we must, would be here C++ Programming/Programming Languages/Comparisons, see if you agree... --Panic (talk) 00:26, 2 January 2009 (UTC)


 * Yes, that's what I intended, and I was talking about C++ (certainly not D -- nothing against D, but it isn't very close to C++). Some implementations of C++ include garbage collectors, i.e., they are "garbage collected implementations of C++".  The next version of C++ is more explicit in allowing for such implementations, but they've existed for a long time. -- James Dennett (talk) 07:40, 2 January 2009 (UTC)


 * But if C++ is defined by the standard and the standard doesn't include any such default capabilities any deviant implementation will not be C++, right ?
 * Can you point me to one of those implementations, as I said I searched for them and came up empty I'm curious to see if they are really labeled as C++, if so it can have a detrimental effect on the language. For what I know "C++" is not a trademark (brand) like "Java" is and so open to be abused, but I would like to think that they would clearly make a distinction that it was not an implementation of C++ but an extension to it (as defined and permitted on the standard, not everything can be added as a library), even Microsoft has done so in the past. --Panic (talk) 18:50, 2 January 2009 (UTC)


 * Nothing in the C++ standard forbids garbage collection, though C++0x makes it clearer that GC is permitted (and provides some more control for it). C++ permits garbage collection, but does not require it.  "CC -library=gc" is an option from Sun (see http://developers.sun.com/solaris/articles/libgc.html) but it's also somewhat common to use the Boehm collector  -- James Dennett (talk) 03:57, 3 January 2009 (UTC)


 * Humm I think we have crossed wires somewhere. What I'm attempting to understand and to what I disagree is the wording of "implementations of C++" (notice that you last edit to the page added also C++ to the phrase), I don't think I'm getting the definition of garbage collecting wrong with you, from the above url "Garbage collection deals with the automatic management of dynamic memory." this so far I know is excluded from the standard, that is the C++ languages doesn't define or implement it, but does support external (to the language) implementations. In the example above that compiler uses the libgc and they clearly state "The library takes care of freeing memory that is not in use.".
 * I agree with all the rest you have said on the above post. I'll retrace the steps to see were I (or you) got lost. I claim that "a garbage collected implementations of C++" is not a good statement, first the use of the adjective "collected" indicate that the actions is finished/done, literally can be read as indicating an implementation of C++ that was generated using garbage collection, this can be true but that is not very relevant to the paragraph and can be confusing, and from the argumentation above this is not what you were attempting to say, since you stated «Some implementations of C++ include garbage collectors, i.e., they are "garbage collected implementations of C++"», and this is incorrect, any garbage collecting mechanism incorporated into the language would by default generate a new language (or at least a new version of the language) and any external inclusion of garbage collecting capabilities would be extensions (and are permitted and defined as such in the standard), and so, the previous statement on that page "C++ does allow for garbage collection, and garbage collection implementations (often based on the so-called Boehm collector) do exist" seem clearer and with only a correct interpretation.
 * Since we clearly understands the concepts and agree on the theory behind it, can you state where my rational as explained above is wrong and the downside of the statement before your last edit ? --Panic (talk) 07:24, 3 January 2009 (UTC)
 * It is idiomatic to speak of "garbage-collected implementations of C++", and doesn't imply anything more than that they are (a) implementations of the C++ language and (b) they offer facilities for garbage collection. For example, see http://en.wikipedia.org/wiki/Garbage_collection_(computer_science) which says "Other languages were designed for use with manual memory management, but have garbage collected implementations (e.g., C, C++)."  There's a difference between saying that "garbage collection implementations" (i.e., implementations of garbage collection) exist and noting that "garbage-collected implementation of C++" (i.e., implementations of the C++ programming language that offer garbage collection support) exist.  The very fact that people mistakenly think that a C++ implementation cannot include garbage collection is why we should not write the former.   Note also: the C++ standard defines "implementations" which cover both language and library, as well as any underlying platform; a feature may well be implemented by a library and yet still be very much a part of the associated "implementation" of C++.  The original phrase used, "garbage collected implementations" meant "implementations [of C++]" implicitly, but your edit shows that it was not clear enough. -- James Dennett (talk) 20:50, 3 January 2009 (UTC)
 * Ha, yup that was it, now we identified the problem (my native language is not English), I did some searches (and looked on that Wikipedia link content), it a bit disconcerting that I've never noticed this, my education on the subjects was mostly based in English (US) literature, and have read some paper since then and never noted the wording "garbage collected languages" was used, and as I pointed above it doesn't seem correct English. I've learned OOP and about GC with Smalltalk, I've looked into the literature I have and it isn't never used, not even on the C++ literature, it is proper to say garbage-collected heap or class but stating that a language is garbage collected never appears and it still seems wrong, but now I understand that we were referring to the same thing. I will think in a way to extend that section in a way that this issue is made clearer, I strongly doubt that I'm alone on the literal interpretation I gave to the wording, even if your wording is commonly used (4,190-5,590 hits on google, not hugely common, but well above my option)...
 * Just to understand how common it is I asked some people, most responded with a third option "language with garbage collection".  --Panic (talk) 00:54, 4 January 2009 (UTC)
 * In google books we get 61 hits on "garbage collected language", mostly in "recent" books the oldest being from 1993 (that would explain how I never came across it) and coincidentally dealing with C++, The Evolution of C++ by Jim Waldo from MIT Press, where it shares my interpretation that a garbage collected C++ would be a new implementation of the language (a new language or a new version of the language), and casts a dark picture in that if such evolution occurs C++ will lose the low-level capacity people tend to select C++ for.  --Panic (talk) 02:04, 4 January 2009 (UTC)
 * C++ already has optional support for garbage collection. The key is that it is optional, so C++ does not lose any low-level capability as code does not have to use GC at all.  The author of "The Design and Evolution of C++" is a strong supporter of garbage collection for C++ ;-) but if you can find a way to phrase things that is clearer while also being informative and correct, that would be great. -- James Dennett (talk) 03:29, 4 January 2009 (UTC)

In The Design and Evolution of C++, page 68, "...I suspect that since the fundamental design choices from C++ were made assuming the absence of garbage collection, a C++ garbage collector would be less efficient than, say, a good Lisp or Clu garbage collector. Worse, I suspect that a garbage collected C++ would fail to deliver the low-level performance people have come to expect from C++." not what I would call a strong supporter for a "garbage collected C++" at least at the time he wrote the book, since then his work on Java (at Sun Microsystems Laboratories) may have changed his view but couldn't find any info on that. Waldo is also known for his opinion on C++'s multiple inheritance and work on distributed computing. --Panic (talk) 04:30, 4 January 2009 (UTC) I've reworded the section a bit incorporating some of what we said here and I was strongly motivated to remove the "strangely named idiom" bit but will let you decide if we should keep that in, see if you have any problem with it now. --Panic (talk) 05:30, 4 January 2009 (UTC)
 * ident reset
 * The point from D&E is that C++ would have failed if it had *mandatory* garbage collection. The world has moved on, and people including BS recognize that better support for *optional* garbage collection is important for C++ (see also discussions on "litter collection"). See also http://www.research.att.com/~bs/bs_faq.html#garbage-collection (I don't know if I have enough motivation to review the text again). -- James Dennett (talk) 09:37, 4 January 2009 (UTC)
 * OK, I motivated myself a little, and reviewed it. Unfortunately I find the latest version rather unreadable, in spite of a lot of work we seem to be making the book worse rather than better.  Hopefully someone else can work on this to better effect.  -- James Dennett (talk) 09:45, 4 January 2009 (UTC)
 * And one note: I expect you didn't really mean to suggest that Bjarne Stroustrup worked at Sun (or on Java)! -- James Dennett (talk) 09:56, 4 January 2009 (UTC)

C++ Programming/Half open
Can I tag this for deletion or were you going somewhere with it? I attempted to figure out where to make use of it on the book but came up empty. Probably in an exercise ? If no reply in 7 days I'll tag it for speedy deletion (only a single "real" edit in 20 November 2004). --Panic (talk) 19:33, 12 April 2009 (UTC)


 * Do what you will.  Half-open ranges are fundamental to C++'s library, but this content doesn't seem very well suited to a C++ book. -- James Dennett (talk) 22:21, 12 April 2009 (UTC)


 * Done. --Panic (talk) 23:15, 12 April 2009 (UTC)