User talk:Mshonle/Fork issue 2

The TOC discussion has moved to yet another page: Talk:Programming:C plus plus/Table of contents. This page can stay here as a history... --Max 00:31, 15 September 2005 (UTC)

Begin the discussions where they left off, but don't copy content from the first page. Instead, just start a new section about whatever issue you'd like to talk about.

Chapter structure
If the restructuring complete? Should we now start merging the content? If so, can we make a TODO page that has all the chapters of C -/- on it, so other people (e.g. me) can help? --Max 05:26, 13 September 2005 (UTC)


 * You should wait until the administrator joins clears or does water whatever editorial work he thinks best on the talk page, then we can start debating the editing of the resulting work--Panic 05:58, 13 September 2005 (UTC)

Authors and prev. or other base works should be next to the title not at the end of the book like other references. My name should be there and I probably made a mistake by adding others to that section, you can use all there references if you merge only the author should remove (and add) it's name (I did add all the others for historical purpose but after examining the GFDL came to the conclusion that I shouldn't.--Panic 03:32, 14 September 2005 (UTC)

Hi Max and Panic. Why don't we use this space right here for an outline of the merged book? Ideally the current structure of the existing book will be kept (but with, for example, the chapter on classes in the middle, before the references section). I would like to see the preprocessor section toward the end (although #include should be mentioned earlier; but the #string tokenizing operator and the ## token-concatenation operator, which are a large part of that section, should be mentioned later) and I would like to see the language comparison section be moved to a part of the FAQ chapter.

Here's a start:
 * 1) Hello world (the introduction to C++, setting up the compiler, and running your first program-- complex details, like buffer flushing, might be more appropriate later)
 * 2) Variables and Operators (used to be "Operators" or "Variables and Expressions")
 * 3) Data Types content
 * 4) Statements (control flow content)
 * 5) Functions
 * 6) Stream and File I/O
 * 7) Classes
 * 8) The STL and Iterators
 * 9) The Preprocessor
 * 10) The Debugger
 * 11) Reference Tables (only place lists of keywords (and other long lists) here)
 * 12) Idioms
 * 13) Singleton design pattern content (the stubs for the other patterns can be deleted for now, someone else can write them later; the Model-View-Controller pattern, the Builder pattern, and the Visitor pattern I would say should be done next, due to their imporantance (and iterator is already done earlier))
 * 14) FAQ
 * 15) Language comparison should go here

This is a large refactoring, but in the end it'll be worth it. What do you guys think? MShonle 03:40, 14 September 2005 (UTC)

Max Version of the TOC
I'll make this a different section so that readers can see both structures and compare / discuss. Please do not edit this section if you are not me. Rather add your comments to the end.

The exact order may change, but this is approx. the structure i'd like to see:

Part 0: About this book
 * Forword
 * About a wikibook (your rights and all that)
 * Authors

Part I: Introdution to C++ and Programming
 * What is a programming language?
 * Binary code
 * Assembler
 * High level languages (C++)
 * Very Short intro: 3 concepts: proc, oo, functional, C++ does all
 * What is the compilation / build process, using a sample program. e.g. Hello world.
 * Example of a build process on unix (gcc)
 * Example of a build process on Win32 (Visual studio)
 * Short intro to language features (explain the hello, world)
 * Variables and the concept of memory (use only some basic types, link -> ref. tables for all data types).
 * Constants
 * simple (!) console i/o (link -> explanation later on)
 * assignment / operators. (explain, link -> ref tables)

Part II: Procedural Programming Concepts
 * Program flow: Branching (if, if/else)
 * Logical operators
 * Program Flow: repetition (while)
 * Program Flow: repetition II (do / while)
 * Program Flow: repetition III (for)
 * Multi-way branching (switch)
 * Function basics
 * Scope
 * the main function
 * Advanced Functions (call-by-value vs. call by reference, overloading, default, etc.)
 * Recursion
 * Array basics
 * Advanced arrays (initialization, partially filled, multi-dimensional, etc.)
 * Arrays and functions

Part III: OO-Programming Concepts (This is completely unordered and probably incomplete, since I have not yet taught an OO-class. So all these should appear, but not necessarily in this order)
 * combining of data and control
 * classes
 * constructors
 * destructors
 * inhertance
 * virtual
 * abstract classes
 * pure abstract classes (interfaces) and why they make sense
 * visibility
 * see list in c -/- -/-

Part IV: C++ Language Features
 * The enum data type
 * The struct data type
 * The union data type
 * typecasting
 * namespaces
 * header files and source files / multi-file programming
 * Strings as character arrays (C-strings)
 * Memory management / Pointers / new, new[], delete, delete[]
 * Operator overloading
 * Exceptions
 * Templates
 * Intro into the praeprocessor
 * Hints for the compiler (inline, etc.)

Part V: Standard C++ Libraries
 * Intro to the STL
 * The String class (C++-Strings)
 * Input and output streams:
 * cin/cout/cerr
 * all those iomanip's
 * text file i/o
 * see list in c -/- -/-

Part VI: C++ in the Real world
 * C++ vs. other languages
 * Common programming styles
 * C++ and varios OS's
 * Win32 (short intro, then link to different section / book ?)
 * Linux / Unix / OS X (explains that there are different GUI things, link -> different section / book ?)
 * Makefiles

Maye a part on GUI in general? Or a different book?

Part VII: Common Programming idioms in c++
 * Intro to design patterns
 * Procedural Idioms:
 * See list in plus plus
 * OO-Idioms
 * some design patterns

Part VIII: Reference Tables
 * List / Table of Keywords (should link to the explaining chapter)
 * List of Standard Headers
 * Table of praeprocessor commands
 * table of compiler keywords
 * Table of Operators
 * Table of Data Types
 * internal storage of the data types (of floats, size of ints. etc)
 * links to other websites
 * links to commercial books

Please make your comments after this line. --Max 05:34, 14 September 2005 (UTC)

I would: Otherwise, it looks great. MShonle 14:39, 14 September 2005 (UTC)
 * Keep the "what is a PL?" high-level and not get into OO vs. Procedural vs. Functional yet. That kind of distinction should be made later in an introductory text. Instead, I would just describe the process of compilers turning code into programs. How it's a series of instructions, how computers work and get things done, and so on.
 * Destructors need to be talked about somewhere.
 * Inheritance and virtual need to be talked about.
 * Headers need to be described somewhere.
 * Ok, how about what is a pl shows opcodes vs. assembler vs. c++ (this explains why we need a compiler) and has only a short intro into prog. concepts.
 * For the oo-concepts: I have added them
 * Headers / multi-file sources are currently in C++ language features. (thats what i meant by headers and sourcefiles
 * --Max 16:58, 14 September 2005 (UTC)
 * Sounds good. A description of memory, the CPU, the HD, and how it fetches instructions/executes them (we're talking six paragraphs max), and then machine code versus C++ code (assembly can be more of a footnote, but that all depends on how you write it). MShonle 19:57, 14 September 2005 (UTC)
 * Agreed. --Max 20:27, 14 September 2005 (UTC)

I'll be pushing a policy about that part that should inform users (readers/writers) about theyer rights (and be portable with the work), also the request that any derivative work not only refers wikibooks but the book title (this must be dif. from wikipedia since we are not dealing with single page articles), the final result will be similar to the old foreword template but with more info and a direct link to the GNU GFDL), but it will take some time. For now the only change to that section is that about wikibooks should be included below you Foreword section, since it describes or gives an intro to the work, the next think should be a description of the medium and it's use, heck, the same way as if we were to add a verbatim GFDL license, if I'm not mistaken there is a structure described on the GFDL about it.--Panic 06:21, 14 September 2005 (UTC)
 * Switched authors and "about a wikibook". I believe thats whay you meant --Max 13:58, 14 September 2005 (UTC)

I think removing or losing any information is bad (some Is redundant, like parts of the Hello World as it is almost a stand alone work, some would probably, if extended, be able to fill other books, lets say a book on OOP or MFC and yet another on STL, but then we have a problem, STL is part of the C++ language and the other topics are needed to understand the language, even Win32 that is not part of the C++ language is important since Windows OS is the most (we hope it will change), OS on the Western world, and I don't think removing portions of a book to create another is correct in the first place (since the information is on topic, like the PL (it can also form a closed book) but it's a needed part as an introduction to C++ and leaving it "low-lever" will help C++ reach an newcomers to PL and C++ in particular, if we start using high level CS knowledge in the book it will lose the thing that I, personably was aiming to, and there are already free books that explain the language to that "elite" audience, Thinking in C++ (see ref. section) it's similar to Thinking in Java...--Panic 16:21, 14 September 2005 (UTC)
 * I believe that some parts of this book can be a book on its own once they get big enough. For example: If we have enough STL material, there could be a book on STL. Then this book would intruduce the STL very briefly, and then reference the other book. I would like to see this book as a starting point to collect material, but I would not be afraid to move some of it, as long as it's briefly introduced and the other book is GFDL and linked. --Max 16:58, 14 September 2005 (UTC)


 * I think a more brief introduction to STL is better. I think a "lots of 150-page books" approach is better than a "handful of 500-page books" approach, in terms of growing Wikibooks.


 * This might be a good opportunity to plan out a charter for the book. Basically, something that describes what the book will talk about and what it won't talk about. The way I see it, this book is:


 * An introduction to programming concepts using C++. The book covers the most essential features of the language and its standard library. It also provides a survey of important concepts, like the STL, software design, and design patterns, but only as a stepping stone for the reader to learn more from other books. The book does not cover non-standard C++ libraries, some of the more advanced or esoteric concepts, nor general computer science data-structures and algorithms. The book is not intended to be a complete reference.


 * All of the other gaps, like design patterns, should be covered in other books that would list this book (or the available books like it) as a prerequisite. MShonle 20:15, 14 September 2005 (UTC)


 * Agreed. Definitely a long-term goal --Max 20:27, 14 September 2005 (UTC)

Just thought about something: Recursion should be in another part, called "Functional programming concepts" (after procedural and before oo). However, this would be too small to be it's own part. I have no solution for that problem. --Max 17:00, 14 September 2005 (UTC)
 * Recursion would be better introduced right after loops are (even before switch is, using your current plan). But I think it's pushing it a bit to describe C++ as being functional. Perhaps after operator overloading is discussed the functor idioms can be described, which mimic some of the features in functional languages. MShonle 19:57, 14 September 2005 (UTC)
 * The problem with recursion: Recursion requires functions and scope. Functions make more sense after program flow (if / loops, etc.) With recursion introduced early, functions would have to move way up:
 * Function basics
 * Scope
 * Recursion
 * if
 * all the loops
 * More on functions...
 * However, this solution does not make me happy... I somehow think that recursion should kinda be on its own.--Max 20:34, 14 September 2005 (UTC)


 * I see. Then I think right after the call-by-name/call-by-value discussion that recursion should be covered (before arrays). A good introduction might first show an infinite loop, and describe why it's infinite, and then discuss a recursive loop that terminates (fight the temptation to use factorial). (In my opinion, students should learn recursion first and only later things like loop-constructs and side-effects, but that's more appropriate for languages like Scheme and less suited for C++.) Another note: will references be covered well before pointers then? MShonle 20:43, 14 September 2005 (UTC)
 * Agreed (for recursion). Seems to make sense. --Max 21:05, 14 September 2005 (UTC)

References: I see two types of references: call-by-reference for functions (which should be in functions II), and references as in the reference operator used for pointers (which should imo be covered with pointer). Where would you put references then? --Max 21:05, 14 September 2005 (UTC)
 * Well, references can exist outside of function formals, as in fields (if I recall correctly, they must be initialized in the initialization list of the constructors) and as local variables. There's no ideal location to place them. It's more dependant on the exposition. Since we appear to really be getting somewhere, why don't you move an updated version of your TOC to here: Talk:Programming:C plus plus/Table of contents. Thanks. MShonle 21:25, 14 September 2005 (UTC)

Single letters as variable names

 * Single letters are almost always a VERY BAD (variables), I can only understand your correction if you lack of experience on doing hard coding single name varialbes are always bad, I can agree with your changes but if a proiminent warning about scope, loops etc... in a very crowded piece of code of even if you do Extreme Coding keeping the logic of things in your mind is extremely dif. even more because it fail to observe the rule of auto documentation or verbosity in code, most actual IDEs do provide code complition of a similar function.--Panic 03:47, 14 September 2005 (UTC)
 * Panic, there is no one "right way" of doing anything, particularly when it comes to coding style. Your view is just one POV, while my view is another POV. The text of the book should be neutral to these POVs (and all other important POVs, but not the unimportant, the-moon-is-made-of-cheese POVs). MShonle 04:10, 14 September 2005 (UTC)

Hello World and other hands on examples (with comments) it's my view should be added as extras or appendices to the book, they are almost a closed work in itself, see the index of C -/- -/- I think Max was willing to create other structures to dif. audiences but I don't know his ideas on the subject the same goes to FAQ etc... If you can do fallow the Index of C -/- -/- the merge was what I was doing (part of my beef with you) so I don't see any major problem, if you fix merge the talk page of the destination location and if possible move the one on C -/- -/- keeping the recent comments of C Plus Plus we can move this talk there...--Panic 03:58, 14 September 2005 (UTC)

Cover Art
Merging does not necessarily mean changing the cover art, which is what I believe was what panic criticized. I personally don't like either one, but this issue should now be the lowest priority. Maybe, when the merge is complete there can be a cover-art contest? --Max 05:26, 13 September 2005 (UTC)


 * As the author of the prev. art work :), your comment does hurt a little but an art work contest sound like a good idea (my image is Public Domain, so I have no beef in having it replaced), the problem is getting people to vote, another problem and that was the one I stated is that since I have added it to the other book and it's part of its the cover can I be replaced or a graphical image can be considered "title", that wording of the GFDL is hard to get, and since it is not affected only by my rights on the work I don't know--Panic 05:55, 13 September 2005 (UTC)


 * Your picture can only be used with your permission (GFPL 4.A) " Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.". Now since you said your picture is Public domain, it is ok to use yours as long as you're listed as author. Also, a history page should contain the merge. --Max 06:07, 13 September 2005 (UTC)


 * I had some trouble uploading it to wikibooks, so a user/reader did me that favor, he selected the license as he tought best, I realy didn't check it nor could I re-upload it, I remeber him telling me about it but as it was used for what it wsa created... If that is a problem I give now as the author the permission to anyone to meke it as rights goes, free (I would like to be only mentioned as the author).--Panic 12:43, 13 September 2005 (UTC)


 * Just as a short explanation of what I do not like: Your picture is too full -- to many things going on at the same time. The other picture, however, has too little. But really, content should matter more than the cover art. --Max 06:07, 13 September 2005 (UTC)


 * I think I did a small analisys of the picture after some one commented on it, can't remeber were (try finf here on wikibooks) or google if you have the time for it, it did explain every single object on it, and it's relation with the subject matter.--Panic 12:43, 13 September 2005 (UTC)

I like simple images the best. If you get Gimp you can end up creating all of these metal, 3D, shadowed, shiny titles that just so happen to look like every other web page. As for Panic's image I think a lot of the buzzwords on it don't really apply today.

For example, the idea that languages would be "hybrid" or "multiparadigm" has largely dropped off of the face of the earth. C++ was one of the first major languages to be hybrid. But these days it just doesn't matter; it doesn't distinguish it in any way from the languages common today. People have found out, for example, that they can write procedural programs in any language. I would say that Java is good with OO, object-based, and procedural. And also (to a certain extent) functional decompositions that are much better in Java than in C++ (the access to final variables in lexical scope is what makes Java's anonymous innerclasses more apt to functional programming than C++, even though C++ is the language with the operator overloaded-- to find out why I make this claim, ask yourself why the anonymous innerclasses need to be anonymous, and how different they would be if they were named). MShonle 02:57, 14 September 2005 (UTC)


 * Prevision? MShonle 03:45, 14 September 2005 (UTC)


 * Expectations (those are based on you, your life, you experience), predictions (I don't think this is also the right work, prediction can be a guess, the word I'm after is on the lines of provision, pre-vision, a visualization of the solution of a problem, that would imply some careful study or some kind of knowledge base to make derivations and elaborate an hypothesis...--Panic 04:03, 14 September

2005 (UTC)


 * You want me to form a hypothesis that the term "hybrid" is a term no longer used by programming language researchers? MShonle 04:14, 14 September 2005 (UTC)


 * What I have said so far is that you should try to avoid having "expectations" when others are concerned  if dealing with medium or large audiences, or even more important, if they are directed toward unknowns (in general and not only applied to this particular case, it's a "logic" flaw that I have found you have, you tend to project your way of thinking directly to others and have problems coming to grasp with the idea that they don't behave/think like you expect, a shortcut solution should be a reversion, to an expectation that no one will do as you expect) if you need to pass a point you should be clear about it or at least try. If you do apply you "small" world KB (Knowledge base, or personal experience, if you prefer) to produce predictions they will have a high probability of being false from the beginning--Panic 06:07, 14 September 2005 (UTC)


 * KB? Previsions? MShonle 04:44, 14 September 2005 (UTC)

Oh, I think I may see what you're getting at now. You're saying that, at the time, it sounded like "mutli-paradigm" would be a good word to use on the cover, but now you see that your guess failed to be timeless. MShonle 04:48, 14 September 2005 (UTC)

I think you're mistaking the term "logical flaw" with "things you disagree with." I'm not sure if you're talking about the cover art or variable names, though. MShonle 14:15, 14 September 2005 (UTC)

Not so, the language status hasn't changed, even if it is evolving you can't say that it has ceased to be multi-paradigm avery language has a defined paradigm or defined range, even if OOP is now more active that the other facets of C++ the language is  and will have be a  "multi-paradigm" language, if that changes it will seance to be C++ (Object-C or Java) are examples of "derivations" from the concept even if similar in nature to parts of C++.

PS: I really hate that wikipedian way of using the talk page, edits can be hard to sequence and I have huge problems with the #%&# edit window...--Panic


 * But what I actually said is that it ceased to be an important distinction. MShonle 14:23, 14 September 2005 (UTC)

And I disagree with you on that point, if you want to use OOP you would be probably better using Java or Smaltalk and C for PP etc... the advantage of C++ is the capacity or the problem (depends on POV) of mixing all of those concepts freely. That can be a reason for not using C++ as the primary language to explaining OOP concepts.--Panic 16:32, 14 September 2005 (UTC)

I am sorry I have to be an a***, but I think this discussion went a little off topic. For the task of merging the book it is probably irrelevant whether multi-paradigm is still used and what languages may or may not be better. Please Focus on the task at hand, people! --Max 17:12, 14 September 2005 (UTC)
 * Yes, but aren't you glad we're not talking about the hyphen slashes -/-? MShonle 20:00, 14 September 2005 (UTC)