Dead book?

I Have to say, this book seems to have gone horribly wrong. There are plenty of mentions of how the editing locks will be removed, yet the lock on the main page is still there. That fails in comparison to the actual text. It's written more closely to what you would find in the reference sections at the end of the book. A programming book covers concepts, while this one just covers the details of the language. I'm thinking about making massive changes to fix this, but considering the message that hasn't left the front page it will be useless.--V2os (talk) 05:45, 15 November 2008 (UTC)

Please reply here since the above post was more or less replicated on the more public Reading room/General, I will probably copy the discussion here for archival when it ends. --Panic (talk) 07:27, 15 November 2008 (UTC)

C I/O and C++ I/O

This conversation moved from Talk:C++ Programming.

"Standard C style I/O" looks like

    printf("%s", "Hello, world!\n");

"C++ style I/O" looks like

    cout << "Hello, world!" << endl;

Currently this book discusses "Standard C style I/O" in the C++ Programming/Chapters/Fundamentals chapter, and then later discusses "C++ style I/O" in the C++ Programming/Chapter Advanced Features chapter. I think that's exactly backwards.

So today I did this: Moved the following links from the "Advanced Features" chapter to the "Fundamentals" chapter:

• C++ Programming/Code/IO
• C++ Programming/Code/IO/Streams/string
• C++ Programming/Code/IO/Streams

Moved the following links from the "Fundamentals" chapter to the "Advanced Features" chapter:

• C++ Programming/Code/Standard C Library
• C++ Programming/Code/Standard C Library/IO
• C++ Programming/Code/Standard C Library/String & Character
• C++ Programming/Code/Standard C Library/Math
• C++ Programming/Code/Standard C Library/Time&Date
• C++ Programming/Code/Standard C Library/Memory
• C++ Programming/Code/Standard C Library/Other

--DavidCary (talk) 03:00, 10 March 2009 (UTC)

I also updated C++ Programming/Chapter Fundamentals Summary and C++ Programming/Chapter Advanced Features Summary to reflect this change. --DavidCary (talk) 04:01, 10 March 2009 (UTC)

I'm considering going even further:

• Old C style stuff in the Standard C Library that has been made obsolete by newer, better C++ stuff -- printf(), malloc(), etc. has been obsoleted by "cout <<", "new", etc. -- tear those pages out of this book and stick them into the the C Programming book; let this C++ book pretend they never existed.
• Stuff in the Standard C library that is still useful to C++ programmers -- sin(), cos(), difftime(), etc. -- stick them into the C Programming book also, but leave behind a short summary with links to the more detailed information in that other book.

Do you think that's going too far? --DavidCary (talk) 03:00, 10 March 2009 (UTC)

I would wish you had made this post in the right discussion area...

In any case the change you made is "political" and cosmetic (and only partially complete) not about content or defending your view/approach next to the reader.

I think I understand your view point, but don't feel that the move at this time is productive and that it has no informative value, it even breaks the existing structure since the place holders or qualifiers were also changed in a similar way before calling the Standard C Library as Advanced or placing it after the STL to me is detrimental to the work, you could have done it by explaining the approach and relevance on how to handle the concepts in the book itself that would be informative to the reader.

The C part of C++ is as relevant as discussing the unique concepts of the language, hiding or banning it to the back pages will in no way promote the understanding of the language, you are in fact enforcing your "understanding" of the language on others going about it this way, especially if the user/reader cant get hold (or doesn't need) to use the new features of the language, like if he is working on embedded systems, but that is another discussion, sadly you made the change before explaining your ideas (I did spend some time looking for the post mentioned in the edit comment).

Old C style stuff in the Standard C Library that has been made obsolete by newer, better C++ stuff this statement makes the last changes really objectionable, there is no old or new stuff in the terms you are putting it, even less better C++ stuff, there is the C++ language, the point of how one should go about learning it is debatable and I think you could, with better arguments behind it, explain and promote it to the reader, granting him the choice to select one approach without moving the pages around on the table of content. I would like you to think about how the changes did improve the book and see if you can live with restoring it as it was and approach the reader in the text.

You are ultimately going about it the wrong way, similar to some people that impose the OOP approach to the language, there is space for all approaches, there is no specific "right way", it all depends on the objective one is attempting to archive . --Panic (talk) 03:33, 10 March 2009 (UTC)

Is there a better place to discuss this? I spent some time trying to find the "right" place to talk about them.

Since I was editing the "C++ Programming/Chapter Fundamentals" module, one might think that Talk:C++ Programming/Chapter Fundamentals would be the appropriate place for me to talk about this change. --DavidCary (talk) 04:02, 10 March 2009 (UTC)

Talk:C++ Programming/Content there is a link on the top of this page and a request to use the appropriated location, just before your post. Feel free to make it as visible as possible if you had problems locating it others may also have. As for single pages talks, I don't feel that it they are really applicable and useful to book projects, people are already too fragmented to fallow any given discussion let alone hope that all interested have a watch on each page of a book. (I generally place redirects on page talks to this page) --Panic (talk) 04:08, 10 March 2009 (UTC)

I am sorry you feel "sadly" about the changes I made. Is there a better way to inform our Gentle Reader about "C++ style I/O" such as "string name; cin >> name" before we tell him about the obsolescent and strongly discouraged "char name[80]; gets(name)"? --DavidCary (talk) 06:04, 10 March 2009 (UTC)

The best way to inform people is not to push for ones viewpoint, it is to be agnostic and as close as as possible to the true value of things. In this case your understanding that something is obsolescent is wrong mostly because you refuse to admit that at certain and specific instances it is still valid and as important as the rest, this an absolutely unshakable fact until the standard suppresses something. It is not your place to dictate that something is old, bad, outdated or wrong and suppress or hide that information. You should only provide the information as it is stated in the standard in the best way possible (ie: write function members in place of methods, even these small things are important for consistency, I have been called on it and did change my habits to be as close to the standard as possible), you can and we have done annotations about best solutions, approaches and practices, it is in this way that you can inform the reader how and what to use in an attempt to transmit all the information, not only the parts you prefer (you are free to work toward what you like, but enable other people to complement it with the rest).

Whatever you like about C++ there is no denying that it evolved from C, and even if the STL is now part of the standard some compilers have still no support to it, some people do not have a need for it and some implementations have bugs, the C Standard Library is the basis of C++, and as you stated before it has been present in the standard for a long time, it is not only there to maintain compatibility with C but to provide the same basic functions (a minimum of functionality), if you want to point out the issues you should add that information were it is relevant not move things around and prevent people from understanding all or use a subset of the language. --Panic (talk) 06:35, 10 March 2009 (UTC)

I agree that the Standard C library includes many functions that are still useful to C++ programmers -- sin(), cos(), difftime(), frexp(), etc.

However, I hear that ISO/IEC9899:TC3, 7.26.9 says "The gets function is obsolescent, and is deprecated.". Therefore, the gets() function is not as valid nor as important as the rest. If this C++ programming book gives our readers a correct understanding of C++, those people will write C++ code using a subset of C++ that does not include gets().

In my opinion, it serves our reader better if I "move things around" so this book explains "cin" and ">>" -- functions that are useful in writing C++ code -- before mentioning "gets()" -- a function that is deprecated. --DavidCary (talk) 22:11, 10 March 2009 (UTC)

• reset

Then we are in agreement when it deals with the standard all should be shown, nothing added or striped down, as you first proposed. We also agree that if possible all warnings and information should be put on the table for the reader, I think we are in agreement on this so the moving of the pages should be secondary and based on the natural order of the concepts (that is the C standard library should be after the introduction to functions and before the introduction to objects, do you disagree if so why? (remember that the text has no special information that raises it section above the rest, it is even more structured as a reference source.)
The next issue is the benefit of moving things about, shuffling thins is great to confuse or hide information even more since this is a book and the people working on it need a fixed structure to evolve the content, more your shuffles so far have broken several items, we have now the std:: namespace classes and other constructs introduced outside of were it was, out of order, culminating in placing the C standard library after the STL in a section named as advanced, all this makes the changes objectionable even if we agree that warnings and more information could and should be placed on the moved sections, moving them around was premature you would have been more productive in providing first the needed content and then thinking if the placement could be improved you even unbalanced the chapters (most had 7 top sections), at least I as the more prolific editor of the book am annoyed by these changes but see them as not worth fighting against (that is why only expressed my sadness and am attempting to rationalize it with you), since those pages would probably suffer some shifts on location at a later date.
I am mostly improving structure and content of the first chapter of the book, unless you start deleting content you can have it as you like, I was just pointing out the issues with the moves, to what you haven't as yet add a good reason for them, and why I labeled them premature... --Panic (talk) 00:45, 11 March 2009 (UTC)

I want this book to tell us how to use "cin" and ">>" -- things that people writing C++ code use quite often -- before mentioning "gets()" -- a function that is deprecated. In my opinion, that serves our reader better. At one time I thought that was a good reason for moving things around. :-).

I agree that "gets()" is not a particularly "advanced" function and so seems a little out of place in a section titled "Advanced Features". But it seemed even more out of place where it was, in the section titled "Fundamentals", since I fail to see how a function could ever be a "fundamental" part of C++, when that function isn't ever used in any C++ program -- except for programs with an obvious buffer overflow bug. Perhaps it would fit better in yet other section?

On the other hand, I think getting input from the user is a pretty fundamental part of programming.

So I think at least a brief mention of "cin" and ">>" fits well into the "Fundamentals" section.

This is the first I've heard about "balance". I am confused -- if "balanced" means "has 7 top sections", how does swapping one top section in one chapter with a different top section in a different chapter makes things less balanced?

Are the chapter supposed to be balanced? If so, should this be mentioned in the C++ Programming/Conventions?

--DavidCary (talk) 04:52, 16 March 2009 (UTC)

You can get what you want without shuffling pages about as I already told you. Put the information on were you think it is relevant, and avoid presenting the reader concepts out of band (that weren't introduced yet) that is all I was asking and what irked me. Add links to the pages of the book and indicate that there are other options and explain why...

Well the sections as they are were the result of a compromise with Darklama (some of the names I don't particularly like but are ok for now until we need to refactor something), the balancing is just a reason to have the sections.

I think you can agree with me that if a section has to many topics it can best be retitled and split so to include only the things around the label that describes it, and removing a section (or making it so thin that I serves no purpose) will create some problems with not only the structure/flow of the book but also on the other sections reason to be (having a basic something section creates the "need" for a advanced something section). --Panic (talk) 06:39, 16 March 2009 (UTC)

sharing common tables

The point of Engineering Tables is to list tables that are transcluded among many books -- such as the Engineering Tables/ASCII Table - Printable Characters. Using transclusion, when a person fixes a typo or improves the formatting once, it gets improved in every book automatically (transclusion discussion).

I would like to do the same thing with all the books that list the "C standard library". I've been told that it is polite to give people from both books a heads-up warning before transcluding from one book into another. So here's your head's up!

Currently the C++ Programming/Code/Standard C Library/Math and nearby pages look like the nicest description of the "C standard library" I've seen on Wikibooks.

There's at least a dozen books that might want the functions of the "C standard library" in their appendices. In addition to the C and C++ books (Subject:C++ programming language and Subject:C programming language), books about other languages that need to use the "C standard library" might also transclude that list in an appendix -- such as D Programming#Interaction with other systems. --DavidCary (talk) 22:14, 14 July 2010 (UTC)

In place of a transclusion that I oppose (we can discuss the reasons in depth if you wish), can't a redirect work or a simple link. My primary opposition to the transclusion is that the pages are still in flux (regarding location) and that a trasclusion is mostly transparent to the editors another issue is of attribution, the C++ Programming has specific attribution requirements that would also need to be duplicated on the other works. --Panic (talk) 23:01, 14 July 2010 (UTC)

I'm surprised that it sounds like Panic2k4 is opposed to something intended to save editors time and effort.

Is "transclusion considered evil" in general?

Are there more reasons that haven't been discussed before at the old transclusion discussion?

A redirect from a "module" in one book to a module in another book? I don't see how that would work, but maybe I'm missing something.

OK, I'll stick with links for now. --DavidCary (talk) 03:20, 16 July 2010 (UTC)

The C++ Programming/About the Book claims that Panic and other authors have licensed this C++ book under the CC-BY-SA license. Does this C++ Programming book have additional "specific attribution requirements" I need to be aware of, and if so, what are they? --DavidCary (talk) 03:21, 16 July 2010 (UTC)

I'll have to take a look again on what was said as I can't remember, but I don't think that I ever supported trasnclusions across books namespaces. One solution would be to use the template namespace as a independent holder for tables (my understanding is that simple tables aren't copyrightable) as in teh Engineering Tables/ASCII Table - Printable Characters. But in the particular case of C++ Programming/Code/Standard C Library/Math that content as I said has attributions requirements specific to this work.

Regarding the content of the C++ Programming book the requirements of attribution regarding textual content is stated in the C++ Programming/About_the_Book in the acknowledgment list. --Panic (talk) 03:33, 16 July 2010 (UTC)

examples and exercises

The C++ Programming/Examples begins by saying

"This Appendix to the C++ Programming book will attempt to provide users a complementary practical understanding of the C++ programming language.

It will be interconnected and dependent on the lessons and theoretical content already presented on the C++ Programming book but ..."

The C++ Programming/Exercises begins by saying

"This Appendix to the C++ Programming book will attempt to provide users a complementary understanding of the C++ programming language.

It will be interconnected and dependent on the lessons and theoretical content already presented on the C++ Programming book but ..."

Those two descriptions sound like they are describing the same thing to me. Is there a better way to inform our readers of the distinct purpose of these two different sections? Many programming books have a few exercises at the end of each chapter. Is there a reason all(?) the exercises are separated from the chapters and put in the Exercises appendix? --DavidCary (talk) 17:12, 26 July 2010 (UTC)

That is the purpose, to separate the examples and exercises in a way that they provide a function by themselves, are easier to manage (to the reader and editor). They are what you would expect as books appendix but shaped to our wiki reality. Do you disagree with the concept ?

I'm not placing great priority on them as yet, was doing work today because of your merge proposal, since some of the main book is still missing and the exercises for instance will require great work, pruning some of the solutions and finding chapters that will fit them, and creating new ones.

I would appreciate help in the Examples appendix, from chapter 2, most of the pages are still in flux but if you have the time, examining the chapters and putting any missing compilable examples in pages (as subpages of C++ Programming/Examples) would be a step to help the book structure (this implies using the colorization of the examples and putting them on the right category for exercises pages as examining the code. The initial example (that serves as an introduction) also requires some pruning/merges/referencing to the book (there is some duplication) and it goes into details that in chapter 1 aren't needed and go beyond making the code understandable to the reader). --Panic (talk) 17:40, 26 July 2010 (UTC)

"Do you disagree with the concept ?" How can I disagree with something I don't even understand?

"They are what you would expect as books appendix" I expected exercises at the end of each chapter, like practically all my school textbooks in every class. Also, I do not expect two different appendices to be word-for-word identical for the first few sentences. --DavidCary (talk) 08:41, 22 September 2010 (UTC)

Fixed, I did use copy-paste. See if you can improve the wording on the exercise. In regards to the exercises that is the idea, to add them at the end of each chapter.

Sorry I took so long to take care of that. --Panic (talk) 11:51, 22 September 2010 (UTC)