Talk:C++ Programming/Archive 4

Adds & Community building
I've started posting some adds on the newsgroups and as an addon to my signature in many places, it seemed to work as for the new number of contributors I'll try to contact some other sources... If you find a guide, faq etc. try sending the author a email maybe he would like to port it over here or contributing... --Panic 02:50, 9 Nov 2004 (UTC)

Move protection
Why is this page protected from moves? Gerard Foley 17:14, 15 February 2006 (UTC)

I meen the module page not this this page. Gerard Foley 17:15, 15 February 2006 (UTC)

The page may have been protected by MShonle, I can't remember a reason but probably as result of the merge the book went trough. If you can move this section to the "proper" "Book Rename" section on the Conventions page or archive it if the "problem" is solved... txs--Panic 03:18, 17 February 2006 (UTC)

new presentation
What about changing the look of the book to have something like this Programmation C or Programmation C++ (débutant) in french sorry. Merrheim 19:52, 3 March 2006 (UTC)

Looks great, I think you can do it with no need for a vote on the subject, just add the link to the new display/order on the top next to the single page version of the book or make a selection/entry point menu to the dif. ways a user can access the content and substitute the "cover" page with it. As of using a single finished "look" as the main entry to the book that is another thing (and will probably be voted on as soon as the book "seems" complete, still, we have to remember that this is an ever evolving framework), every reader is a potential contributor to the book, "hiding" the structure/modules and working pages may do more harm than good, the final objective is to have the GFDL content, the visualization or order can have many implementations as we make the content more modular.--Panic 03:15, 4 March 2006 (UTC)

C++ Exercises book
I try to write an exercise book for C++ programming for beginners C++ Exercises for beginners. I thought the C++ books was too big an i had prefered writing a new book this a link to this one of course. Merrheim 15:11, 5 March 2006 (UTC)

Why not using a redirect from that page to an addendum to the C++ book and use the same name place of the actual book for all the content and have a cross reference to each part on the book to the exercises (the solution should not be on the same page as the proposed task) ie: C++ programming/exercises/topic/ C++ programming/exercises/topic/solution/ --Panic 17:12, 5 March 2006 (UTC)

Why not. It is possible too. Merrheim 17:21, 5 March 2006 (UTC)
 * 1)When the name C++ programming will be voted (march 14) I will transfer the exercises Book.

2) I think it is possible to have 2 versions with the same text of a wiki books (not duplicated text): one with a standard gui and one with beautiful menu template. I will do some tests ! 3) I want to participate to the C++ book 4) You don't like the solution template ? you can see the solution of the exercise if you want ! 5) I made a big mistake : EXERCISES takes a S in English ! 6) I am sorry but my english is not very good. tell me if you dont understand what i mean. see you soon Merrheim 15:17, 6 March 2006 (UTC)

No problem, I also do not have English as my main language, I've started working on this book in English so to get as many contributors/readers as possible (there are other versions of the book, see bottom of main page) the content should be the top most priority, translations can be done after the book gets to a comfortable stage. Do you use firefox? there are a couple of extensions that could help you in editing: SpellBound, gTranslate and Resizable Textarea to name a few you can get links and more from del.icio.us bookmarks (firefox+inuse), see my user page.--Panic 07:12, 15 March 2006 (UTC)

Is this dead? If no reply in 3 days I will try to contact Merrheim if it seems impossible I'll try to check --Panic 16:50, 28 September 2006 (UTC)
 * 1) If the content can be used on the C++ book
 * 2) If the author statement that it was willing to bring it's book content to the C++ book is still valid.

Merging into the book should be initiate ASAP, provide a stand alone TOC to the exercises, extract the completed examples and add them to the proper subject matter, also indexing them as examples and complete all examples extraction from C++ Programming and provide a example TOC (not exercises but only with the example source codes)--Panic 22:11, 20 October 2006 (UTC)

What do you have in mind for organizing it into the book? I think for now, it should all be its own chapter on the form "C++ Programming/Exercises/exercise-name" and maybe "C++ Programming/Exercises/exercise-name/solution" if theres solutions to the exercises. --darklama 22:48, 20 October 2006 (UTC)

Yup, but using transclusion and posting the examples in the proper chapter under exercises (see variables/exercise) this will make it easier in the future to check all the code and add boxes.--Panic 23:13, 20 October 2006 (UTC)

Transclusion to where? I'm against transinclude the exercises into the chapters, they should be there own seperate part only placed in whole book view after the chapter, if you want to have it orginized that way. --darklama 23:33, 20 October 2006 (UTC)

Ok just to go ahead with this, do you agree to move the book to a Chapter Exercises at the end of the actual book, humm, maybe after the STL and before Beyond the Standard ?, Or a Volume if you are adamant in preserving it's structure after the Appendixes (will have to rename the first Volume I, (preserve the visualization and add it to the Volume Title and next to the whole book view) don't add to the whole book view and add a note on that. We can then decide how to organize it, this will preserve it's structure as is and enable us to link to sections of it) I think at the end of each chapter adding an exercise list (related to it) would be productive.--Panic 05:32, 30 October 2006 (UTC)

I agree with moving the book into its own chapter if there are no objections from anyone else. I suggest using the mergeto/mergefrom tags both on the main page and the main page here, to see if anyone has any objections with its merger. If noboby objections, then where its located in the Table of Contents or full/print book view doesn't really matter, since we're both presenting different views of the book. Preserving its structure may be a good idea for now. For example if/when moving the main page of the book move it to "C++ Programming/Exercises" and move its chapters to "C++ Programming/Exercises/chapter". My only objections is transcluding to existing chapters of the C++ Programming book, since that would effect multiple views, but changing Table of Contents and full/print views isn't as big a deal, since different perspectives on this can still be maintained. So for now if you wish to get it done, do the mergeto/mergefrom tags, give it a week or so, then move into here if nobody objects, preserving its structure and make changes to the Table of Contents and full/print view as you wish.

BTW I still think the TOC thats the main page seen when going to this book needs to be moved to something like "C++ Programming/TOC1" and instead present a different main/front page that shows the current cover image, chapters needing work and list of different views along with a link to the print/full page view and if you wish an edit link for the print/full page view. I've looked at how another book makes use of the front page that looks promising for ideas of what might work for this one, so I think I may do some more editing of my test page. --darklama 13:02, 30 October 2006 (UTC)

Book Reorganization
There seems to be a few remaining issues with some chapters overlaping one another that I think should be addressed.


 * There are multiple chapters that try to do an overview of basic programming related concepts, that I think should be merged into one chapter, after some editing to cut down on details. I think instead of giving too much details the chapter could also act as a guide to where more details on the relevant information can be found in the book. The chapters are:


 * 1) Introduction
 * 2) What is a programming language?
 * 3) What is a program?
 * 4) Understanding the Source Files
 * 5) Programming Paradigms

The new chapter could cover the history of programming briefly leading up to the creation of C++, somewhat expanding on whats already in Introduction and possibly explaining the rest of the concepts in terms of when they were introduced. This chapter could then end with a summary of basic C++ programming concepts that are explained fully in later chapters along with what those chapter names are as wiki links. This chapter would be for readers not familar with C++'s history or with the most basic programming terms and concepts.


 * There is some overlap between what are variables and what are operators that needs to be addressed as well as two chapters on operators that should be merged. There is also the statements chapter which I think should be part of whatever chapter describes these concepts. This chapter would also describe chaining operators together and how C++ evaluates expressions. My idea is to have one chapter that talks about statements, expressions and operators. This would probably require rewriting the chapter once merged together. Arrays should be be part of the chapter on variables because arrays are out of place anywhere else. References and pointers I think should either be in the chapter on variables or described in a chapter on memory management. The varies operators used for arrays, references, pointers I think should only be described in terms of their binding order in whatever chapter describes expressions, states and operators instead of fully explaining what arrays, references and pointers are as seems to be the purpose now.


 * There should be a chapter on memory management which discusses using new, new[], delete and delete[] operators and describes basic concepts of how memory works. Since references and pointers are typically related to memory this may also be a better place to discuss them in detail rather then a chapter on operators where I think they are a bit out of place. This would also involve merging the contents of "Internal storage of data types" into this new chapter.


 * The two chapters "Abstract classes" and "Pure abstract classes (abstract types)" I think should be merged into the "Polymorphism" chapter, because abstraction is one of the key concepts of polymorphism and shouldn't be separated into different chapters.

I would be willing to try to do all this if there's no objections. I think all these changes would improve this book a lot and then I should be able to concentrate more on correcting errors and expanding on concepts. --darklama 20:01, 7 November 2006 (UTC)

If you intention is extend The Introduction chapter, clean it up and move parts to a sub chapter that would cover the history of programming languages and C++ in particular, that I think is a fantastic idea.

As for moving the *The two chapters "Abstract classes" and "Pure abstract classes (abstract types)", this are C++ topic that must be easy to find and read for a users and Polymorphism is a concept that can be learned or skipped as it is independent of the only C++ content and should be introduced in Programming Paradigms under the OOP information.--Panic 01:08, 13 November 2006 (UTC)

No my intention is to combine "Introduction", "What is a programming language?", "What is a program?", "Understanding the Source Files" and "Programming Paradigms" into one chapter and clean it up. Whether its split up into sub chapters or not depends on the results after the merging, cleanup and extending happens.

As for the "Abstract class" and "Pure abstract classes (abstract types)" bits being combined with Polymorphism being hard to find. Part of the reorginization plan with the above combined chapter is to describe what each chapter covers in more detail then whats provided in the table of contents description, as is sometimes found in the first chapter of a book. This should make it very easy to find what a reader is looking for.

To give an example:


 * Variables : Variables store or hold information that a program needs to know about. This chapter covers the concept of variables in more detail along with the various kinds of variables you need to know about.

...but the information for the chapters would be a bit longer than that.

This first chapter would become a quick walkthrough of important Historical events that lead to the creation of the C++ Programming language and then what new concepts C++ introduced. Along with explaining what a programming language is and what events lead to the concepts of divided a program up into logical units such as source files. This would also effectively cover different programming paradigms from there historical 	significance. Followed lastly by what this book covers and how the chapters are layed out. Whether this ends up being a single page or spreed out over multiple pages depends on how big it becomes. All I got to say is we should start with just one page and go from there. If it needs to be split up over multiple pages so be it, but transclude all the subchapters into a chapter page for those readers who wish to read it all at once. This was my motivation for trasncluding those chapters into one, to begin this process. Really it needed to be copy and pasted into one chapter rather then trasncluded, but I was trying to start off slow for you. I really rather see the first chapter be an overview chapter and leave later chapters as "closer look" at what was just covered in the first chapter, then readers who need or want to know can read the first chapter and those readers who want to dive right in can skip ahead without losing out on any important information. I believe this is what you want too, even if we don't exactly agree with how much or how little information should be given. If you can agree that certain stuff like how C++ implements data abstraction is held off until later chapters like Polymorphism with this reorganization then all the better. The first chapter becomes an overview what it is all about, and the later chapters the why and how. --darklama 02:41, 13 November 2006 (UTC)

I don't see a need in reducing the books parts (unless it has some duplicated content) as for merging "Introduction", "What is a programming language?", "What is a program?", "Understanding the Source Files" and "Programming Paradigms" into one chapter (if you mean more that under the single section), I don't like the idea as the subjects are independent of each other and "Understanding the Source Files" is the only one that deals directly with C++ concepts, if the intention was to set them on the same section/chapter what would you name it? (ultra-basic ?), the only problem with that is "Understanding the Source Files" doesn't belong on the same section. --Panic 17:15, 13 November 2006 (UTC)

Well I think those parts need to be cleaned up a lot and tied together as one chapter. My idea to try to take a slightly different approach to the topics covered in those pages so that it is easier to follow and understand and those who know already something about it can skip ahead. Source files are not concepts strictly new to C++. My intention is to set them up as part of the same chapter and the name could be Introduction. To give a general idea of what could happen if it gets long enough after merging and cleaning it all up is:

Introduction (actual chapter name, transclusion of all subpages) Introduction/History (includes history of OOP, procederal programming, structural programming, early history of C++, etc.) Introduction/About (description of what this book covers, description of what each chapter covers)

It would be basically like what you did to Inheritance and Polymorphism in a way in which you made them subpages of the Class chapter. The only difference is they would be one page for now while I cleaned it all up, possibly make major changes to it and expand on it. Its a bit hard to explain it without doing it. Think of a "dead tree" book, books have chapters in them that try to be self contained, generally with the exception of the first chapter which covers what the book is about, who is meant to read the book, possibly a bit of a history of the topic and sometimes a overview of what the chapters contain so readers can skip to the chapter they are most interested in. If you look even at other well-written wikibooks that have a big contribution base they follow the same guiding principals as a "dead tree" book.

These last steps that I proposed are what I think are the finishing touches of my "this doesn't flow very well, needs more flow to it" theme that I've been raving about. I think its truly needed to turn a major tide of the book from "difficult to read" to "easy to read" and I think everything else I've worked on so far has been working up to this. I think your decision to hold off on discussion of my other suggested until this is completed is a good idea. I think this major change is a must. Oh and I'm not trying to reduce the contents with this move, just trying to get it in better shape, in the contrary I think it will actually end up increasing the size of the contents of this book.

To give you some more example here's a generalized approach I have in mind:

In, introduced which contained variables that allowed programmers to store information temporarily in memory, the idea is said to have been borrowed from algebra and in the early days of programming only single letters were allowed to be used to present numbers.

In, introduced functions with his/her creation of the programming language...This was the beginning of functional programming.

Maybe that will give you an idea of how I plan to combine it all together into one chapter. Right now sure it may not make since, but thats part of the reorganization and clean up process I have in mind. :) --darklama 18:36, 13 November 2006 (UTC)

Well in the part of extending the introduction and adding more history we are in agreement, please don't remove the Wikipedia links, if possible link to this book if a section exists (or if it should exist, leave the link to Wikipedia), if it shouldn't and another Wikibook has the information use Wikibooks as the reference. Ok this will get you go ahead with the work.

As for the section name moving all under an introduction chapter seems acceptable but remember that as I said "Understanding the Source Files" is not generic like the others it introduces the idea of C++ file extension (with limitation on the OS) and naming conventions that are not and should not be part of the style conventions. --Panic 18:49, 13 November 2006 (UTC)

Well perhaps then the Understanding Source files page needs to be split up into seperate parts, with the parts that deal with understanding source files being within this new introductory chapter and the bits about file extensions and naming conventions in some sort of guide to getting and setting up a compiler. Of course I think such a chapter would need to be general enough and not cover how to do every little thing in the compiler. Just how "do I compile this thing?" basically. --darklama 19:10, 13 November 2006 (UTC)

Ok well talk about that when you get to that part (Understanding Source files), a introductions to the OS would be welcomed and the file extension/names part could be used there. Humm the Hello World example has a little introduction on how to use GCC a more complete one is still missing. A introduction to Make tools is also missing.

As for what a compiler is and how to use (in general) should be kept separated, but all the information would be welcomed. You probably can't write a "how do I compile this thing?" with general orientations in several compilers without needing to introduce more evolved concepts, it can only be done in simple and basic examples (like it is done in the hello world)--Panic 17:07, 20 November 2006 (UTC)

Actually the simple and basic examples like is used in the hello world page is what I had in mind for any chapter on getting a program compiled and any naming conventions with maybe a note template added to suggest readers read their compiler documentations and maybe also refer readers to the weblinks page in the book for any online documentation that may be available or tutorials or other wikibooks that might be helpful. Something like a 1 to 5 minute guide to compiling with g++, visual studios, etc. is all I had in mind. I don't think we need to cover Make tools, I believe there is already a wikibook that covers Make tools and other common tools found in a Linux/BSD environment. Anyways I guess I can just get started and whatever isn't needed any more from Understanding Source files can be deleted and we can deal with whatever is left of it then. --dark lama  17:48, 20 November 2006 (UTC)

Terminology
James Dennett makes a good point (I must confess that I have the updated C++ Standard but use it only for consultation) I didn't read it from cover to cover, but his point in the nomenclature used should be followed...

I will start changing:
 * methods to member functions
 * functions arguments to function parameters

And will try to find a way of introducing this concepts at the beginning since I agree that "Sticking to the terminology used by the C++ standard, where possible, ensures consistency and helps people to adapt to C++ instead of being confused by more general Computer Science terminology or terms from other languages." --Panic 21:11, 9 December 2006 (UTC)

I've changes all references to methods to member functions, txs to Darklama for spotting some mistakes, another point that should be checked is the distinction of parameters (aka formal arguments) vs arguments that James Dennett pointed out.--Panic 02:49, 10 December 2006 (UTC)

I've done one better and changed virtual member function to virtual function as its what the standard uses. I agree we should use the proper C++ standard terminologies. So I think its safe to call this a required style in this book. "Use standard C++ terminology when available". --dark lama  03:43, 10 December 2006 (UTC)

Scope, Standards and Sequence
It seems clear that we want to mostly focus on standard C++, currently meaning C++ as specified in ISO/IEC 14882:2003. However, as I come to write some more material on memory management, it's very tempting to include some material on shared_ptr, either as boost::shared_ptr, as std::tr1::shared_ptr (from TR1), or as std::shared_ptr (as is likely to be in C++0x). If we choose to cover material that's not in the 2003 standard, we should at the very least be careful to make it clear that it is not yet standard. The bigger question is: to what extent, if any, should we cover TR1 or C++0x material? An argument could be made for having separate chapters for each of TR1 and C++0x, and then referring to them from other chapters as seems helpful, but I'm not sure that's the best approach. Ideas/opinions? -- James Dennett 05:45, 12 December 2006 (UTC)

From previous discussions and from becoming more familar with attitudes on Wikibooks, I'm of the opinion that material that might be in a future standard of C++ shouldn't be covered until they become standard. There is probably very little way to cite references that something is going to be in the next standard, not to mention could be qualified as orginal research. We got a chapter on Boost however, so I think boost:shared_ptr would be best served by being covered in that chapter.

I'm of the opinion also that parts of the C++ standard that deals with the library should be covered in its own chapter and for the most part that seems to be the way its been going, as we have a chapter on String and a chapter on Streams. The memory chapter I think should deal with using new, new[], delete and delete[] since they are considered operators rather then part of the standard library. I also think it might make sense to have C++ Programming/Data Type Storage part of that chapter and to cover references and pointers there as well.

Ok one last point to make, is I think that each chapter should try not to refer to other chapters too much. As you probably can tell there are two different table of contents and print versions available. This reflects differences in view in what order different concepts should be learned. So each chapter should probably not make any assumptions about whats already been covered or not, in order to try to remain neutral in favoring one view over another. It also has the advantage of making no assumption that on what readers have or haven't read yet.

To summarize my opinion:
 * Future Standards shouldn't be covered until they are accepted as current standards.
 * Standard C++ should be covered separately from the standard C++ library.
 * Each chapter should more or less stand alone and not assume other chapters have been read first.

--dark lama  21:08, 12 December 2006 (UTC)

That position on standards is reasonable (material on C++'s TR1, which has been published, might usefully be covered in a separate book).

As for having a section on memory management that doesn't document that RAII is the canonical C++ approach, with references to ready-made memory management classes, I'd be opposed to it. I do agree that covering the lower-level facilities should be done, but too many sources cover them without noting the better tools that exist for most uses. This does get into issues about neutrality, but a book on programming should try to mention best practices, which is non-neutral.

Incidentally, new/delete etc. are interesting in that they are part of the intersection of language and library: they are language features that rely on library features, and can be affected by user-defined replacements for operator new etc. It's not entirely possible to cover language and library separately -- nor, in my opinion, is it desirable. Separation should be based on subjects according to what they achieve, not implementation details.

It might be worth having a hierarchy: have a Memory Management chapter with an overview, a section on manual memory management, and a section on RAII. I'd have to think about a good way to organize that. Then again, that's pretty much the angle I was coming from already, and you seem uncomfortable at covering both manual memory management and automation of memory management in the same chapter.

-- James Dennett 00:31, 13 December 2006 (UTC)

You're somewhat correct. It's not so much uncomfortable with the idea of having manual and automation of memory management in the same chapter, as I do with the POV that automation of memory management is the way to go. I think the chapter's main focus should be on how a programmer can allocate and deallocate memory and gives tips on how to make it easier to do so, through the use of class constructors and destructions to minimize the need to keep track of it oneself and near the end possibly mention things like garbage collection, using tools that help to debug memory leaks, and using automated tools.

I agree there is no real way to separate memory management as provided by the language itself and provided through the standard library. I don't have much of an issue with combining that information in some chapter since it makes sense. Referring to memory management in other chapters is probably not a good idea though and that was mainly what I was referring to. That and suggesting discussing the boost memory management in that chapter, since it already has a chapter and isn't really part of the standard.

I see this book as being divided into three parts:
 * the first part teaches how to use C++ as defined by the current standard.
 * the second part teaches about the use of the C++ library as defined by the current standard.
 * the third part descriptions any non standard extentions and any additional libraries that might be useful.

To sort of tie the first and second parts together I think the memory management chapter falls as the dividing point, since its a little bit of both. --dark lama  00:55, 13 December 2006 (UTC)


 * Interesting; I think your last point exposes the core issue here. C++ can be taught bottom-up (in which case you'd want to cover the "language" aspects before the "library" aspects) or top-down (in which case you'd introduce some of the key pieces of the standard library from the very beginning).  Originally pretty much all C++ texts were bottom-up, and that has caused many problems.  More recently the best C++ texts have been top-down, and that's an approach I'd prefer if we can find a way to make it work.  Is it fair to say that your preference is for what I'm calling a bottom-up approach?  (Would you have a better term for it?) -- James Dennett 04:46, 13 December 2006 (UTC)


 * This isn't really my approach, rather how it already was before I started contributing. I don't really have much preference on it, but I do agree the approach this book uses does seem to not work too well. The only preference I really have is based on my own preferences in programming books which are ones that can be used both for reading from cover to cover to learn from and can be used later on as a quick reference. This usually means that each chapter is relatively independent of the others, and cases where it is not, it gives an exact reference to the page and section title to make locating the information a breeze and it contains appendexes in the back, which in the example of C++, has all the keywords, library functions, classes, etc that are available to a C++ programmer. I also believe in teaching good habits like not assuming just because X works in compiler Z that its going to work everywhere if its not standard, by not discussing non-standard things until later on the book when everything that is standard has already been covered. Using this method I believe removes clutter from books, since it can focus on just one core concept at a time.


 * So if your willing to help take this book into a completely different direction and have a lot of time on your hands to do so, then I'm all for it. The reason I say if you got the time, is I hate to see it only get half done, it would be better to try to make the current approach work if you don't have time to invest in making some other approach work. In some ways my attempts to change the first chapter may reflect inversing the book from a bottom-up approach to a top-down approach, so we may not be as far off in our thinking. --dark [[Image:Yin yang.svg|12px]] lama 05:34, 13 December 2006 (UTC)


 * Another way may be to take it one step at a time, working from the first chapter then moving onto the second chapter, etc. That way may allow for slow adjustments over a longer period of time without the issue of looking inconsistent. I've been working on trying to provide more consistency to the book without trying to change its approach too much, since it doesn't require as much time investment to do so as changing its approach would require. That is really my only concern with changing it from bottom-up to top-down, causing inconsistencies that in the time may make it hard to use for reading. --dark [[Image:Yin yang.svg|12px]] lama 15:38, 13 December 2006 (UTC)

Hmmmm (comments from a reader v. 1.1)
Well, while the new front page looks nice, there's no "introduction". Maybe someone could answer a few questions for me:


 * What is C++? What does it do? What is it used for? Why would you use C++ rather than another language?
 * Where do I start? What's a compiler? And how do I see if the things I've compiled work?

Them's my first questions :). -- SB_Johnny | talk 22:27, 12 December 2006 (UTC)


 * Thanks for the feedback. So many trees around, they're obscuring... something...
 * There are plans for some kind of talk of some of this, but I think you've done a good job of capturing concretely some of what's needed. Unfortunately the "how do I do..." all depends very much on which C++ compiler you're using, on which system... but there's another Wikibook I think that covers some of that. -- James Dennett 00:16, 13 December 2006 (UTC)


 * Interesting... I added a placeholder entry for an "Introduction" chapter, and found that such a chapter already exists, and answers some of the questions posed above (such as "What is C++"?) -- James Dennett


 * Ya, C++ Programming/Programming Basics is a combination of several chapters. You'll notice its almost identical. The main difference is trasnclusion vs copy and pasting in. As said in a section above, the introduction needs work. Maybe not the best of names, but used it sense Introduction was already taken and there was some differences in opinion by Panic, on how best to accomplish the rewrite. I hate having a duplicate, but I felt it was the only way to work around, Panic's issue with it. --dark [[Image:Yin yang.svg|12px]] lama 00:32, 13 December 2006 (UTC)


 * Do you guys have any recommendations for compilers using various operating systems? Some discussion of the differences might be nice too. -- SB_Johnny | talk 15:25, 13 December 2006 (UTC)


 * I'm answering here for now, as I'm not sure where this would fit into the book content (or even if it should be part of a different book). For most platforms, for a compiler, one of the GCC ports (http://gcc.gnu.org/) is a decent choice, and can be obtained at no cost except time.  Many Open Source platforms include a recent gcc version.  Version 4.0 or later gives fairly good conformance to the C++ standard.  Various IDEs are available to support GCC.  For Windows, Microsoft Visual Studio Express is currently available free of charge with a C++ compiler that can be used from the command line or from the supplied IDE.  Earlier versions of Visual C++ are rather buggier than I would like to recommend for learning C++.  For most platforms Comeau's C++ compiler (http://www.comeaucomputing.com/) is about the best in terms of standards conformance and gives excellent warning/error messages, which can save a pile of time; it costs $50, but does rely on your system already having a working C compiler.  (In case it's not clear, an IDE is a (generally graphical) environment which integrates functionality like editing, compiling, linking, and usually a help system etc.) -- James Dennett 22:21, 13 December 2006 (UTC)

Arbitration regarding this Wikibooks and User:Panic2k4
I've started an arbitration situation for Panic and those who might have been involved with editing this Wikibook.

Note that this is to air out all of the issues that apparently led to having this user's account blocked from editing here on Wikibooks. If you are interested in getting involved, the arbitration will take place on this page and sub pages:

Arbitration/Panic2k4 vs. SBJohnny

I'd like to push this through as rapidly as possible, but if you feel that this user has wronged you in any way, please make note on the appropriate page. Defenders of Panic will have their chance to offer up rebuttals once those who have aired their side of the issue first.

Please, let's try to be civil and cool down the problems that existed in the past. --Rob Horning 20:06, 4 January 2007 (UTC)