From Wikibooks, the open-content textbooks collection

.

This space is for contents planning and to provide a direction for continued contributions.

[edit] TO ADD to TOC

[edit] Items needing work (Editor's TOC)

[edit] Type Casting

There are various kinds of casts in C++: C-style casts like (type)value, functional-style casts like type(value), and keyword casts (reinterpret_cast, const_cast, static_cast, dynamic_cast). That's all the casts there are. Some conversions are caused by casts, some are not. There's no such thing as an "automatic cast".

[moved from Talk:C++ Programming/Type Casting]--Panic 19:36, 8 December 2006 (UTC)

I've now explained to James Dennett the presumable author of the post that, type casting and type conversion are synonyms, to say that there is no such thing as "automatic cast" is the same as "automatic type conversion" (which there is). "automatic type conversion" is the conversion of one type to another without an instruction from the coder, like by using some construct or an abstraction layer one can perform an "automatic type conversion". (must check the text if this is explained there) --Panic 21:01, 9 December 2006 (UTC)

At this time I think I've helped Panic to understand that type conversion and type casting are not synonyms, and explained in particular how some type casts do not result in conversions, while other conversions occur without casts being present. -- James Dennett 07:01, 1 March 2007 (UTC)

This discussion is more or less finished User:James Dennett has corrected my assertion. It is still here and not archived because a check must be made if the correct information is now on the book, before archiving this... --Panic 15:43, 12 September 2007 (UTC)

The example of dynamic_cast on this page is flawed at the moment in that neither of those classes are polymorphic. User:anon 16:38, 2 October 2007 (GMT+0)

In reference to the part on Automatic Type conversions (any reason why "conversions" is not capitalized btw?), I thought 5.6 would be a double converted to an int?220.255.7.243 (talk) 11:45, 20 November 2008 (UTC)

[edit] pointers

(moved from the Q&A page as an unsigned post about content) --Panic 17:26, 3 January 2007 (UTC)

I would like to have a bit more of how pointers work and what their function(s) are.Also i would like to know what Data Structure can be used to write a function that returns an Array of elements.Your help will be highly appreciated.

The answer to (a) is (b). The answer to (b) is (a).

A bit less snarky: Pointers do many things. We use pointers to implement most forms of indirection; and "All problems in computer science can be solved by another level of indirection" according to wikipedia: abstraction layer :-). One way to return an array of elements involves a pointer to (the first element of) that array.

Today I added an example of passing arrays to a function and returning an array from a function at C++ Programming/STL. I have one example using the older "C style arrays", the other example uses the newer "C++ STL vectors". Does this answer your question? Would it be more useful to move that example to C++ Programming/Operators/Arrays or perhaps C++ Programming/Memory Management ? --DavidCary (talk) 00:20, 5 March 2009 (UTC)

[edit] Inheritance, Polymorphism

Can anyone explain why there need to be two different modules on inheritance and two different modules on polymorphism in this book? --xixtas ^talk 13:50, 26 March 2007 (UTC)

Results of the restructuring of Darklama. Darklama advanced the concept of named structure to support even better the page names navigation scheme, specific sections were aggregated (see class / stl /api ), works ok and was an improvement to the navigation. The specific pages were restructured not only to accommodate to that but also due to the extensive changes of the text and order. I'm saving the original pages to state only the concept and class/xpto to the applications of it (like a page to state what is a plug and another to show how to install a plug on a wall), and as it seems there is duplication with the page Darklama created merging other 3 pages (the one with history logs problems), but that one will require very careful work to see what was done there. --Panic 15:36, 26 March 2007 (UTC)

I would prefer to have only one section which starts from basic and advances gradually. Wish we could come up with a bible kind of book. Jayaram Ganapathy

That was how it was structured in the beginning of the book (on the introduction to programming paradigms) but that information was reduced (some of the historic part was removed) and there is a problem for a single part that addresses it all, that is a bit difficult as several concepts have a general definition but implications in several parts of the language, take a look for instance on the Editor's ToC at the memory management and see if you can merge it properly with the book (it's a hard task to make the book not only usable to for people that only will use it for consultation and people that like to read a book from cover to cover), I personalty prefer the first concept for technical books but I have not imposed that view on my edits if you have a better solution give it a try with that page. --Panic 16:55, 11 April 2007 (UTC)

What I would suggest is to add a chapter before inheritance with title resource management. There we have to discuss everything related to object creation including the usage of placement new, delete[], auto pointers , smart pointers etc. Before knowing OOPS a person should know memory management in C++. Then only he will be able to understand properly virtual functions, multiple inheritance with a common ancestor etc... Also I would say add one error management in C++ before we dive into OOPS. Once these are done, discuss inheritance. At this point a reader will be able to understand descent code which contains memory management and exception handling code. We also will be able to throw good examples of inheritance. Then move to generics/templates. Regarding the Editor's ToC at procedural idioms, it contanins boost specific examples. I would prefer to take out boost specif things to the beyond the basics section of TOC 2. There an exhaustive boost chapter is welcome. After all we don't have a company like SUN who will provide JDK like API. So we should encourage all third party tools usage and anybody interested let them add one chater about usge of a specific tool there. Jayaram Ganapathy

[edit] RTTI

This conversation moved from Talk:C++ Programming/RTTI.

This discussion is not so much about the page or the content itself but about RTTI; in particular its misuses of it and comparing it to goto. If you are going to compare it to goto you might as well say never ever use it. A page here http://www.asingh.net/technical/rtti.html talks about up-casting a pointer back to a derived pointer : perhaps to access specific methods of that object ... wouldn't this be a valid use of RTTI ? at some point (because all objects aren't the same) you will have to access a object specific member right ... ? even if those classes are in a hierarchy. --Gravisan 04:18, 11 September 2007 (UTC)

To tell you the truth I never used RTTI intentionally, and you must keep in mind that the book isn't only written by a single person (you may edit any information you object to). I will check the edit and see if something is inaccurate and who provided the content. As for stating "never ever use it" we don't do this here :) we try to substitute must by should in general. Even in the goto information we only provide the facts, we don't specify that it should never be used (there are proper, even if rare, cases for its use).
I will examine the provided information and will reply to you later (and add/correct any content) on this subject.
Txs for the input. --Panic 16:35, 12 September 2007 (UTC)

But suppose that we know for sure that this pointer points to an object of type 'SpecificClass' and we would like to call the member SpecificOp() of that class. To dynamically convert to a derived type we can use dynamic_cast, like so:

If we know this for sure, there's no need to use dynamic_cast. The whole point of dynamic_cast is that it can be used when the object's dynamic type is unknown, and the results will indicate whether it has the correct type. Also, type_info::name() does not in general return the class name as shown, but returns a compiler-dependent string. I hate to dump on other people's efforts, but it is better to have nothing than something incorrect.

[edit] review of C++_Programming

There is another part of repeated text on the operators page, but it fits, so I'm just making sure that you think this is right

at C++_Programming/Operators#Operators and C++_Programming/Operators#Arithmetic Operators

sum = a + b;

is repeated. It works because the first one was giving an example of operators, and the second one is talking about arithmetic operators, and they are a third of a page away, but I just wanted to make sure =) rawrawrer (talk) 11:00, 22 April 2008 (UTC)

in C++_Programming/Operators/Pointers#Dereferencing operators it has

struct A { int num; };
 
A a;
int i;
A * p;
 
p = &a;
a.num = 2;
 
i = *p.a; // Error! "p" isn't a class, so you can't use "."
i = (*p).a;

[edit] 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)

[edit] C++ wikibook

(moved from the Wikibooks:Reading room/General page)

What do I do? This is all wrong for a programming book because it just covers references to C++. It doesn't even start out with a "Hello World" program. Any other programming book would cover a general programming concept in each chapter, and the actual language itself is sort of secondary. My problem is that the main page has been locked for years (even though some comments say a solution was found). Based on that, if I make the massive edits they will most likely be reverted.--V2os (talk) 06:06, 15 November 2008 (UTC)

I'm going to bite it. As one of the major contributors to that particular book I take very personally any critiques made against it, especially in such a public fashion, since they reflect on the effort I've put in the work I've done so far.

I don't get your "just covers references" reference, the C++ programming book at least what is present on TOC1 was the result of evolution and compromise with other editors, first TOC - present day TOC even there we can see the similitude. The content structure is very similar with other works like Java Programming and other book on the programming category, even Ada Programming, and over the time I've seen C Programming evolve in very similar lines (I've kept my contributions to the C book at a minimum so I don't share any of the "blame").

My estimates make the C++ Programming book if not the biggest programming book on Wikibooks at least one of the more extensive and in depth and much is still missing...

I've taken the chance to check were you are coming from, so to put things in perspective you are a registered Wikibookian since 15 July 2005 and have less than 250 edits, you seem to be a serious user of Wikibooks, but not an specially active content contributor, so I take that your intension to "make the massive edits" you are probably thinking in restructuring or reformatting some of the content already present, is that it? Have you checked the other Subject:C++ books also? --Panic (talk) 07:20, 15 November 2008 (UTC)

Alright, I have two books here: C++ Programming from Problem Analysis to Program Design Third Edition by D.S. Malik (1300+ pages) and C++ for Dummies 5th edition. A mere glance at the index indicates a more proper way to organize them, For example Malik:

1. An overview of Computers and Programing Languages

2. Basic Elements of C++

3. Input/Output

4. Control Structures 1 (selection)

5. Control Structures 2 (repetition)

5. User-Defined Functions 1

etc.

19. Stacks and Queues

Dumies Part 1

1. Writing Your first C++ program

2. Declaring variables constantly

3. Performing mathematical operations

4. Performing logical operations

5. Controlling Program Flow

That should pretty much say it all. It's hard to describe in words, but they get the point in that they need to get the reader programming immediately and slowly introduce concepts at a rate that anyone can understand. Yes, I mainly plan to restructure it. The other C++ subject books around are the same (even the other languages are too), it's because were a community that researches material online, and online material is just basic references.--V2os (talk) 07:47, 15 November 2008 (UTC)

Well, the two books you have reflect different approaches with district goals. I don't know the first but from the title it should be somewhat what we are going for in general terms even if with more low level information added in (so to enable any person to get into programming without any further help) as for the for Dummies book (I do know it) I wouldn't call it a great model to fallow, it's objective is a introductory book to C++, and no more, we are attempting to be that but going a bit further.

As you have only pointed out the first sections of each book book I think you don't agree with that part of the C++ Programming book but if you take a closer look to the structure, it's very similar to what you have written above, if you check if C++ Programming/Chapter Getting Started does cover the above point 1 to 3 but even more in a deeper and extensive way (covering every requirement for the newcomer). C++ Programming/Chapter Fundamentals covers the rest up to object oriented programming constructs, that is on the next one, C++ Programming/Chapter Object Oriented Programming that finishes introducing all the basic knowledge of C++ and so on.

The book is not very hands-on at the moment, we do cover the practical side, even in the Introducing C++ section, just in the beginning, we give the standard "Hello World" example with an extensive step by step guide for those that are already able to fallow it Hello World: Writing, Compiling and Running a C++ Program, the practical side is still in the beginning, with C++ Programming/Examples and Exercises Section the now covers Variables and types, Iterations, Static arrays,Functions, The Standard IO Stream, it still needs some reorganization but at least my focus for now is on finishing up the theoretical part first.

The format is not written on stone, and we can compromise, but please refrain from doing a major overall on the structure without careful consideration for what is already there and other editors opinions. See C++ Programming/Conventions.

Take a look into the C++ Programming/Editor's TOC to see what is missing if you like to contribute, or see if the Understanding C++ project (almost a clean slate) is more in line with your favorite approach to the subject (check the scopes of each project). --Panic (talk) 18:38, 15 November 2008 (UTC)

The problem with C++ Programming/Chapter Getting Started is that it can't really get anyone started that doesn't already program. Other books spend hundreds of pages talking about pure procedural programming, and topics like inheritance and polymorphism get their own chapters after classes are introduced. classes themselves get their own chapters, assembly language and java have no reason to be in the books, so they aren't, etc... It's nice and all, but I think it's turned into a mess that can't be fixed.

Yes I've lost interest in fixing it, and will work on the understanding C++ wikibook;--V2os (talk) 20:49, 15 November 2008 (UTC)

I'm sorry you think that. In any case that section was a pruned out (not by me, and with my stated opposition) removing some of the more basic level introduction, things as basic as what programs are etc so I grant you that it could be improved in that regard but I can't agree that removing the references that you can use ASM inside the C++ compiler or pointing out that C and Java are closely related (and highlighting the differences) would improve the book. In any case I will take your comments and see what can be done to improve the situation, I will keep an eye on what you will be doing in the other project, maybe I'll understand it better... --Panic (talk) 21:34, 15 November 2008 (UTC)

[edit] 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/Chapter 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[1] and strongly discouraged[2] "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."[3]. 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)