- See also: Talk:C++ Programming/Conventions and Talk:C++ Programming/Q&A
- This space is for contents planning and to provide a direction for continued contributions.
This page's content shouldn't be archived/removed if no solution or closure was given to it. Topics that were addressed and will not be target for a re-visitation can be deleted if 30 days have passed. In doubt ask and give 7 days for anyone to object.
Items needing work (Editor's TOC)
Linker - Complete Internal linkage and External linkage information (remember to mention extern, unnamed namespaces and link to the relevant sections).
Orphans needing attention
[ edit list above ]
Please add here pages that are not linked to from anywhere in this book (but have to be merged or marked for deletion).
Procedural idioms in C++
[ edit list above ]
friend functions/member functions
Random number generators
From 32 to 64 bits
[ edit list above ]
Content Mining (some content that can be mined into the book, remember to look into the copyright guidelines in the talk page...)
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".
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?184.108.40.206 (talk) 11:45, 20 November 2008 (UTC)
(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)
- 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
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.
- Done . I changed the text of C++ Programming/RTTI as you suggested. --DavidCary (talk) 22:15, 28 June 2010 (UTC)
- The situation/examples are weak for the intended demonstration as there was no previous contextualization. I've added a bit on top and reworded it to conform to the above. See if you agree, I think that there is some content duplication occurring here will check on that... --Panic (talk) 23:50, 28 June 2010 (UTC)
I propose a change to the chapter names: Renaming chapter "Getting Started" as "C++ a multi-paradigm language" and "Fundamentals" as "Getting Started" for starters would resolve most of the issue people have raised and relate better to the content provided there. "Advanced Features" is also a problematic issue but I haven't come up with a viable alternative, something like "Extended Features" would be an advance does anyone have a better idea ? --Panic (talk) 05:29, 22 March 2010 (UTC)
- Done. I've also taken the chance to improve the navigation and clear some of the book's category chaos. The second chapter is still pending moves and renames. Now a change is also in order to the "Object-Oriented Programming" since it is a to generic chapter title, something on the lines of "Using the power of object-oriented constructs and features".
- I also detected inconsistency on the headings case and page names I will attempt to fix it. Page names will have the first letter upper cased (if possible, for instance keywords shouldn't be changed)...
- Objection and ideas for improving the title are welcomed to facilitate later changes on the chapter name I was thinking in reducing the page name to "Objects" (like the first chapter uses "C++"). --Panic (talk) 04:13, 8 May 2010 (UTC)