Difference between revisions of "Talk:cpp"

Revision as of 15:18, 12 December 2011

The templates here are insane.

I've been wanting a site like this, and I'm sure many people, including myself, would absolutely love to contribute. But the templates used make the job really difficult. Would anybody be upset If I just started adding stuff in non-template form, and someone else could come along later and templatize it? Or myself if I care to learn it more in depth.

The templates here are a bit complex. (The idea was that the content of this site has a fair amount of repetition and hierarchy, and templates allow that stuff to be specified in one place rather than repeated in multiple locations. But it does make for a steep learning curve.)

I think it would be fine if you added non-templated content. After you've made changes, others can come along and apply formatting and refactoring as needed.

If there are any specific parts of the templating scheme that don't make sense, please mention them. It might make sense to put together a short tutorial describing how the templates work, and it would be useful to know what the overview should cover.

First question. Is this how discussions are done, by just continuously editing the Talk:cpp page? Then I suppose we click the signature button to indicate we're done talking.

Some of the things that are confusing are things like dcl and tdcl. I guess they are used to make lists, but I have no idea what those acronyms stand for, or what the difference between the two is. There are other things I saw, I can't remember where, something like ltt. I would like an explanation for any acronyms like that. Thanks.

--Benjamin Lindley 21:05, 30 June 2011 (PDT)

Hi all,

I'm the original contributor of the content in this wiki. Previously I have extensively edited the content in the old wiki that was based on Dokuwiki CMS. During that time I had a lot of discomfort with repetitive modifications to the stuff that was duplicated across several places. It was quite time consuming too, as, for example, some function descriptions are used in 20+ places. So I decided to pass all the iterative work to the templates. The resulting system is quite complex, I agree. However, the formatting capabilities are far, far higher when using templates, and since the content is created once, but consumed many times, I think that the improved usability is worth the additional cost writing the material.

All templates have their documentation at Template:<template name>, e.g. Template:tdcl list item. There is no page that summarizes all templates though, however since there is demand for one, I will create it soon at Help:Templates.

Regarding the discussions, I think it's a good idea to write signature below each comment. Alternatively, one can just write ~~~~ which is automatically translated to signature.

P12 05:00, 1 July 2011 (PDT)

As C++ programmers, I'm sure everybody can appreciate the power afforded by templates. I didn't know about the documentation for the individual templates. That's helpful, thanks. --Benjamin Lindley 09:17, 1 July 2011 (PDT)

What's the hierarchy here?

This site seems to be laid out in the categories documented in the standard library, sort of. But it's not entirely consistent in that. Should effort be made to that effect? So, we would have 13 broad categories, starting with the Language Support Library, and ending with the Thread Support Library. In that same vein, I think should be done to disambiguate the General Utilities Library from the utility header. For example, vector is part of the Containers Library, and this is reflected in it's page's name cpp/container/vector. But the memory header is part of the General Utilities Library, and that is not reflected in it's page's name cpp/memory. However, I think that cpp/utility/memory would not be good as that would cause people to confuse it with the utility header. I think cpp/general_utilities/memory would be the appropriate name for it. Thoughts? --Benjamin Lindley 23:24, 1 July 2011 (PDT)

The problem is that the Standard groups its components into libraries based only on their functionality. It works well for most of the components that serve very specific purpose. However, for the most generic libraries, components with similar objective are placed into different libraries. This decreases the usability a lot, so we chose not to mirror the structure of the Standard in these cases. It turned out, that the problematic libraries are the [18] Language Support library, [19] Diagnostics library and [20] General Utilities library. So for these libraries, different partitioning scheme is used (the component numbers are based on doc no. N3291):

• Memory management (cpp/memory). Contains:

• [18.6] Dynamic memory management
• [20.6] Memory
• [20.7] Smart pointers
• [20.12] Class template scoped_allocator_adaptor

• Errors (cpp/error). Contains:

• [18.8] Exception handling
• [19] Diagnostics library

• Date and time (cpp/chrono). Contains:

• [18.10] Other runtime support (some components)
• [20.11] Time utilities

• Function objects (cpp/functional). Contains:

• [20.8] Function objects

• Program management (cpp/utility/program). Contains:

• [18.5] Start and termination
• [18.10] Other runtime support (some components)

• Basic types (cpp/utility/types). Contains:

• [18.2] Types
• [18.3] Implementation properties
• [18.4] Integer types

• Runtime type information (cpp/utility/rtti). Contains:

• [18.7] Type identification
• [20.13] Class type_index

• The remaining bits go to cpp/utility/**

• [20.3] Pairs (cpp/utility/pair)
• [20.4] Tuples (cpp/utility/tuple)
• [20.5] bitset (cpp/utility/bitset)
• [20.9] Metaprogramming and type traits - ?????
• [20.10] Compile-time rational arithmetic (cpp/utility/ratio)

Hierarchically, all these components are in cpp/utility (sidebars should reflect that too). However, some of them are not in cpp/utility URL-wise because that would be confusing as some components are, well, not general utilities (e.g. cpp/memory, cpp/error, cpp/chrono). I don't know why function objects are at cpp/functional. They should be moved to cpp/utility/functional.

One thing that I'm thinking about is to group Basic types, Runtime type information and Metaprogramming/type traits together as they are all about type properties. Then the category could be placed at cpp/types.

By the way, the section names memory, utility, etc. are named after the headers only because it is easier to remember the paths then. They have little to do with the actual content that is placed into these categories. E.g. cpp/memory hosts contents of the new header at cpp/memory/new.P12 12:55, 2 July 2011 (PDT)

Could we promote pair and tuple to front page under Utility? I think they should be listed similar to how bitset is listed now. --Cubbi

That's a good idea. P12 15:26, 31 August 2011 (PDT)

notification box location (for downloading an archive)

I feel that having a big notification at the top of the main page could be a bit distracting for most users. It would certainly be appropriate to announce system-wide messages, like planned downtime or the like. But having it announce something that is of lesser importance (like the location of the archived version of the site) seems like it could be more distracting than useful, at least to the majority of users. To that end, I moved the notification to the bottom of the page. Thoughts? Nate 14:38, 24 September 2011 (PDT)

Seems fine to me. P12 12:47, 25 September 2011 (PDT)

Code exemple

Should we add exemple and usage of different functions? could be helpfull for users and new C++ programmer, what do you think?

I'm definitely a fan of having examples, at least on "leaf" pages. Were there any pages in particular that you were thinking of? Nate 13:25, 4 December 2011 (PST)

As you say, "leaf" pages should all have their own exemple IMO.Drahakar 16:40, 4 December 2011

C++11 feature vs. since C++11

Which of the "C++11 feature" and "since C++11" is better to mark functionality added only in C++11? It seems to me that the second one presents the intent in a clearer way. Any opinions? P12 06:45, 12 December 2011 (PST)

Would that affect Template:mark c++11 version / Template:mark pre c++11 version, and if so, how? Going with shorter text, they could become (since C++11)/(until C++11) or even simply (C++98)/(C++11). --Cubbi 07:52, 12 December 2011 (PST)

"since C++11" isn't bad, but I kinda like (C++11) too...