Computing B‑class Top‑importance

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing B This article has been rated as B-class on Wikipedia's content assessment scale. Top This article has been rated as Top-importance on the project's importance scale.

C/C++ Unassessed

This article is within the scope of WikiProject C/C++, a collaborative effort to improve the coverage of C and C++ topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.C/C++Wikipedia:WikiProject C/C++Template:WikiProject C/C++C/C++ ??? This article has not yet received a rating on Wikipedia's content assessment scale. ??? This article has not yet received a rating on the importance scale.

This article talks about yet to be defined proposals for certain features. the commitee does not accept any proposals other than those outsources from current proposals (as they are better handled as single proposals). therefore some of these features mentioned here are definetly not to be added to C++09. Also some of the features mentioned here will (if at all) only go into TR2 which will be *after* C++09.

The article is riddled with typoes and strange terminology. I fixed a few, but the task is daunting as many of the sentences are difficult for me to undestand what they were meant to say (although I can guess a few, My knowledge in the subject is limited, so I won't even try). --M.A. 21:02, 24 November 2006 (UTC)[reply]

Yes, I'm sorry for my bad English. If you take my some examples of incomprehensible text, we could try to fix it. NOTE: bernoulli_distribution and poisson_distribution are lowercase, as they are been defined by "ISO/IEC DTR 19768 (June 24, 2005) Doc No: N1836 Draft Technical Report on C++ Library Extensions".--Gildos 19:13, 26 November 2006 (UTC)[reply]

Your contribution is appreciated and the article does treat much (everything?) of the proposal as of now! I applaud the effort you've put into it! Still, though, Acolyte of Discord's comments remains valid: the article is in need of thorough copy-editing since the language is partially only semi-grammatical resulting in ambiguous propositions, unnecessarily convolute constructions, statements reading as POV, and an often awkward read. Unfortunately, I too dare not touch it since I'm not familiar enough with the topic and fear that I might introduce untruths, which would be worse than problematic language. Mikademus 18:17, 27 November 2006 (UTC)[reply]

The article doesn't treat everything of the proposal but only principal features, as you can see here and in the Technical Report 1 --Gildos 19:28, 27 November 2006 (UTC)[reply]

I have done quite a bit of copyediting of the article today to clean up some of the awkward wording. However, there were some sentences I simply couldn't parse. In particular, in the "Extensible random number facility" section, I have no idea what "Apparent casualness is due only from limited perception of users" means. If anyone can figure that out and reword it, it would be a help. Julesd 03:41, 8 July 2007 (UTC)

Maybe they meant "causality" not "casualness"? Alternately, maybe they meant that rand() seems simple (and good enough) to users only because users don't fully understand the complicated nature of RNG/distributions? I also find it hard to understand the original meaning 24.17.110.123 11:26, 18 August 2007 (UTC)[reply]

Won't the new version of C++ include AOS (Aspect Oriented Software)? (This is more a wish than a discussion).

Not according to this document, but I'm not close enough to the topic to say for certain. --Gabriel "Jarl" Sjoberg 07:38, 2 January 2007 (UTC)[reply]

This concerns a paragraph which I (EatMyShortz) deleted:

I have referenced now the piece of article you have deleted. The document is The Design of C++0x: Reinforcing C++’s proven strengths, while moving into the future at the paragraph of Design and Evolution. If you find unreferenced parts use comments or the discussion page like the other user please. I am available to clarify all your doubts about this article. --Gildos 19:41, 8 January 2007 (UTC)[reply]

Hi Gildos. Well I found the paragraph which was paraphrased in the above article. However, just because it's referenced doesn't give it a neutral point of view. This article is an opinion piece, written by the language's author. The statement (and the paraphrased version of it here) is basically a sweeping opinion of one language designer, about language design in general, as well as a prediction of what "will" provide the greatest benefits. It has no specific relevance to C++, and is non-encyclopedic. Therefore, I am removing it again. Please don't add it back unless you have a specific reason for it to be here. (And if you must revert, please do so to my previous version, where I added a link in the reference). —EatMyShortz 11:34, 10 January 2007 (UTC)[reply]

You can trust or don't trust it, but it is not the point of view of one language designer, it is a line guide of the C++ Language Committee. If you don't like the way it was writed,rewrite it please. Deletion is a bad solution. --Gildos 14:53, 10 January 2007 (UTC)[reply]

Do you prefer this way?

The designers of a language can be obsessed with notation problems of small relevance, neglecting more meaningful language features that may allow new programming styles to develop. The C++ Language Committee believe that a good feature provides a direct response to a problem; it does not significantly interact with other features of the language and typically has a reduced logical expression, leading to concise portions of code. The greatest benefits will come from solutions that allow the programmer to resolve a problem and to better organize the code, as happened with the introduction of object-oriented programming and generic programming (templates).

I'm waiting the opinion of other users. --Gildos 14:53, 10 January 2007 (UTC)[reply]

"It has no specific relevance to C++, and is non-encyclopedic."

You must be joking, sir. Either that, or you really have no idea how the committee works. BS's opinion is extremely respected. Of course it's not just his "baby", he can't decide anything alone.

But throwing away BS's text like that is silly. It's obviously relevant to C++ and obviously encyclopedic.

I think you are just trolling. Find another game, please.

--212.27.60.48 (talk) 07:44, 11 February 2009 (UTC)[reply]

I did what I could to rewrite the section about smart pointers, but I wasn't sure what to say about the weak_ptr template, since I can't figure out why that would be used instead of a regular pointer, if what I googled about the topic was any use. Using my own judgement, the only purposes of a weak_ptr would be to prevent the implicit/automatic destruction of objects, or have a reference that would be automatically nulled when the owner was destroyed, but I couldn't find any evidence for either theory.--Prgrmr@wrk 07:22, 23 January 2007 (UTC)[reply]

The main goal of the weak pointer is to reference an object without influence its cicle of life. Garbage Collection is not provided in the proposal of General Purpose Smart Pointers as you can see in A Proposal to Add General Purpose Smart Pointers to the Library Technical Report (Revision 1).--Gildos 11:40, 23 January 2007 (UTC)[reply]

A regular pointer is just a pointer to an area of memory - after the object it is pointing to has been deleted, the regular pointer will still seem fine to the naive user, but will be pointing to god-knows-what. A weak_ptr has no effect on the existence of the object it is referring to, but it does know when the object has been deleted, and prevents the user from accessing it thereafter.

Indeed, they are very few uses for weak_ptr. And for the few cases where they can be used, it's usually suboptimal.

Most people who pretend weak_ptr is extremely useful simply don't understand anything about smart pointers; they confuse them with gc (as in Boehm gc) where every normal pointer (T*) is followed by the gc system and is thus a strong pointer.

Most examples of use of weak_ptr are totally bogus. It's frighting! I have been (almost) kicked of a forum for saying that weak_ptr wasn't that useful! --212.27.60.48 (talk) 07:38, 11 February 2009 (UTC)[reply]

The Portland meeting in October 2006 established what will be the main additions to C++0x. Many items that were originally considered for inclusion (and mentioned in the current article) are now no longer so considered. A good overview of the Portland decision was written up by Herb Sutter here.

Daveed V. 22:12, 15 February 2007 (UTC)[reply]

I've replaced the dispute template with {{update}}, which is more specific and looks better. Hairy Dude 17:59, 24 April 2007 (UTC)[reply]

yeah okay this does not change that 80% of that article is entirely made up see also http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2228.html

I've read much of the stuff in from the n228.html webpage, and I have a pretty good handle on what C++0x is shaping up to be. I'm willing to take some time to rewrite the article, but I have a few questions about how to do it (with appropriate citations).

Should I make any attempts to specify how likely one feature is to be added to the final C++0x spec? Should I make some effort to categorize the new features, or should I just list them one (perhaps alphabetically)? Korval 01:58, 30 May 2007 (UTC)[reply]

Be bold! Do what you feel would be best for the article. However as a suggestion, the more details (with app cite) you can provide the better, avoid just a list of items. KTC 09:03, 12 June 2007 (UTC)[reply]

It says that "As a shortcut, closure variables refering to local variables can be defined as:" and then comes the following code:

int total = 0;
<>(x: &total) {total += x}

Which should be equal to

int total = 0;
<>(x: auto &total = total) {total += x}

I was wondering if not the ":" should be a comma (","), so the code should be

int total = 0;
<>(x, &total) {total += x}

and

int total = 0;
<>(auto x, auto &total = total) {total += x}

81.233.131.203 19:57, 10 September 2007 (UTC)[reply]

No, the ':' is there to separate parameters to the lambda from references to variables outside the lambda. 'x' is a parameter, 'total' is a local variable that is referenced by the lambda code. The '&' means that the lambda closure will contain a reference to the local variable 'total', it could be done without the '&' as well in which case the closure would have it's own copy of the variable (and the whole lambda would be a no-op).

213.100.20.12 02:21, 12 October 2007 (UTC)[reply]

The article has been flagged as too long. Granted, this is probably meaningless because most people who might be inclined to shorten it can't understand and properly summarize the material. So there isn't much worry about the lay person coming along and ransacking it. However, it is very long. Should we make some of the sections smaller, turning some of the detailed explanations into summaries? Korval (talk) 19:11, 27 December 2007 (UTC)[reply]

When I start to write this article, I planned that in 2009, at the release of new C++ standard, it will be split in many sub article one for every utilty like other existing utilities of actual C++. I think this is the right way to split this article. At now every new article should be an upcoming software and the article C++0x will be a summarise of all the modifications. It's no so simple, because references may be split for every article. If the community like this way of splitting I start to do that, with the hope that no new article will be deleted. --Gildos (talk) 02:38, 29 December 2007 (UTC)[reply]

The example used to motivate the introduction of wrapper references is:

// This function will obtain a reference to the parameter 'r' and increase it.
void f( int &r )  { r++ ; }

// Template function.
template<class F, class P>void g( F f, P t )  { f(t) ; }

int main()
{
  int i = 0 ;
  g( f, i ) ;  // 'g<void ( int &r ), int>' is instantiated
               // then 'i' will not be modified.
  cout << i << endl ;  // Output -> 0

  g( f, ref(i) ) ;  // 'g<void(int &r),reference_wrapper<int>>' is instanced
                    // then 'i' will be modified.
  cout << i << endl ;  // Output -> 1
}

Won't we achieve the same effect by simply defining g with the second argument as a reference, like this:

template<class F, class P>void g( F f, P& t )  { f(t) ; }

Jorram (talk) 12:07, 16 January 2008 (UTC)[reply]

You 're in right but with

template< class F, class P > void g( F f, P& t )  { f(t) ; }

you cannot decide if parameter t will be modified or not. Every intallation of template g will modify the parameter. Remember, it's only a stupid example. Bye. --Gildos (talk) 12:39, 19 January 2008 (UTC)[reply]

Equally importantly, what if you don't have control over g's definition? For example, Boost.Bind/TR1.Bind can't take references as parameters to be bound to functions, because that's how it is defined. It has to take reference wrappers if you want to pass a reference. In many ways, it exists for the same reason that something like TR1.Bind does: so that you can do something with someone elses code that would otherwise be syntactically impossible. Bind can turn a multi-parameter function into a function of 1 parameter suitable for use in a standard algorithm. Reference wrappers turn a copy-style template parameter into a reference-style parameter. All without having to change the actual interface itself.Korval (talk) 02:51, 22 January 2008 (UTC)[reply]

It would be useful to add an icon or a color tag or something else to easily see what will be available in C++0x, what would be available for the next revision (TR2?) and what is abandoned (if any in this page). As I'm not a specialist (about the subject and about wiki edition standards), I'll do it myself now, but maybe will try in some weeks if i found time and energy to parse the last reports. Klaim (talk) 00:26, 20 February 2008 (UTC)[reply]

Nothing on this page should be anything that has been specifically remanded to a future TR or language revision. Everything on the page should be exactly what is expected to be in C++0x. If, as standardization approaches, something is remanded to later revisions, then it should be removed from this page, not color coded. Korval (talk) 00:46, 20 February 2008 (UTC)[reply]

Then i guess the garabage collector part should be removed? MJKlaim (talk) 01:08, 20 February 2008 (UTC)[reply]

This paragraph in the initializer list part suggest that a container like a std::vector cannot be initialized by an initializer list:

Standard C++ allows this on structs and classes, except that these objects must conform to the Plain Old Data (POD) definition; non-POD classes cannot use initializer lists, nor can useful C++-style containers like std::vector and boost::array.

For example:

std::vector<int> v = { 1, 2, 3, 4 };

I think that this is wrong. A non-pod can be initialized, but cannot be part of an initializer list, eg:

std::vector< std::vector<int> > v = { std::vector<int>({10, 11, 12}), std::vector<int>({13, 14, 15}) };

So the first would be correct in C++0x, the second code ill-formed. Should the paragraph be changed to make that clear?

213.196.194.249 (talk) 22:08, 4 May 2008 (UTC)[reply]

Technically, both the first and second would be valid C++0x (there's still some dispute with regard to uniform initialization). However, the paragraph wasn't talking about C++0x yet; references to "Standard C++" mean "C++03". Korval (talk) 05:38, 5 May 2008 (UTC)[reply]

My doubt is the concept version of inheriting from two classes which have a common member name.

Suppose I write a template with one type as parameter, and which requires that type to satisfy two concepts (hence using the generalized notation):

template<typename T> requires Concept1<T>, Concept2<T>
  void f(T x) {
    ...
  }

Now imagine both concepts consist, e.g., on having a typename defined:

concept Concept1<typename T>
{
  typename pointer;
  //...
}

concept Concept2<typename T>
{
  typename pointer;
  //...
}

And as none of the concepts is "auto", they must be satisfied by explicit concept_maps. Now both concept_maps may have to define different things for the typename "pointer":

concept_map Concept1<MyClass>
{
  typedef char* pointer ;
};

concept_map Concept2<MyClass>
{
  typedef int* pointer ;
};

If inside of my template function (f) I try to use T::pointer, and I have specialized T to MyClass, the compiler won't be able to resolve which one I want (either char* or int*). Is there a way to specify to which concept I refer when writing ::pointer? (IIRC, when faced with the analogous problem on inheriting from two classes, one could use the sintax base1::member and base2::member to distinguish between them.) -- User:Euyyn —Preceding unsigned comment added by 212.0.110.2 (talk) 18:23, 17 July 2008 (UTC)[reply]

That's an interesting issue. However, this is not a discussion forum for how C++0x will work in specific detail. Please see the PDF article on concepts for further details.

That being said, I'm guessing that it would be erronous to do what you say. That is, if concept mapping is to be used, each constraint on the template must resolve to the same concept map. Korval (talk) 02:20, 18 July 2008 (UTC)[reply]

In private correspondence with an influential member of the standards committee I'm told that "the 'uniform function syntax' is not part of C++0x and IMO is unlikely to become one." 24.5.238.80 (talk) 21:11, 27 July 2008 (UTC) Jon Kalb[reply]

Hi, I read this part of the article:

struct OnlyInt
{
  void f(int i);
  template<class T> void f(T) = delete;
};

and that made me wonder if this would work:

template<class T>
struct OnlyInt
{
  void f(T) = delete;
  void f(int i);
};

OnlyInt<int> x;

x.f( 5 ); // Valid?

I guess the question is whether f(int) or f(T) will get called, and if f(T) is called, maybe that should be noted. I tried to test this, but void f(T) = delete wouldn't compile with GCC (as expected).

Thanks in advance. Posted by SoC (talk) -- Posted at: 20:31, 11 August 2008 (UTC)[reply]

This isn't valid, because the specialization OnlyInt<int> contains two identical function declarations. Note that in the example, OnlyInt is a class, not a template, and the deleted function is a member function template. In this case OnlyInt().f(5); is valid, and that's the entire point of the example (that a normal function is a better function than a function template specialization when there is no conversion involved). decltype 09:39, 2 February 2009 (UTC)[reply]

User-defined literals were last described in N2378 (8/1/2007) but were not included in the draft N2606 (5/19/08). They are also not listed on GCC's C++0x features to implement, which, while it shouldn't be taken as authoritative, is probably a good indication that its not considered a feature that's likely to go into the final standard. Since there is supposed to be a new working draft coming in October, if that draft should include user-defined literals, the section can be reinstated, but to me right now it looks like they've been turned down.

--98.232.203.240 (talk) 06:12, 26 August 2008 (UTC)[reply]

That logic is not sufficient to remove that section of the page. The GCC status update only includes functionality that has been voted into the working draft. Concepts are not on that list, despite the fact that WG21 is adamant about getting concepts in C++0x. Concepts are also not in the working paper, which will happen fairly soon. So just because something isn't in the working draft yet doesn't mean it shouldn't be presented on this page. The next meeting should tell us whether extensible literals make it or not, so keeping it around for a month won't hurt anyone. Korval (talk) 02:08, 27 August 2008 (UTC)[reply]

Is there any estimate of a release date? Are we looking at 2009 or 2010? Or later? Might be good to include if there's a source. 71.244.5.124 (talk) 23:02, 31 October 2008 (UTC)[reply]

Nice stuff but why we don't have anything to define properties????

There are many very significant and sadly common errors in this section. This is shows a superficial understanding of C++.

A null pointer is a possible value of a pointer:

int *p = 0;

if (!p) 
  std::cout << "p is null pointer\n";

A null pointer constant is an expression (used to set pointers to the null pointer value). It is not a value. (An expression is a part of the program source, while a value exist at runtime - except for some compile-time values of integral or pointer type.)

In C++98, a null pointer constant cannot have pointer type.

The whole section is about null pointer constants not null pointers. There is no change in C++ with null pointers.

The statement foo(NULL); will call foo(int), which is almost certainly not what the programmer intended.

Since the dawn of C in 1972, the constant 0 has the double role of constant integer and null pointer.

No. 0 is not a null pointer, it isn't a pointer; it's integral constant expression.

It's very important not to confuse programmers about the fundamental fact that: The expression 0 never has a pointer type in either C or C++.

In either language, any expression (given a set of declarations of course) has only one type. For the expression 0 the type is always int, end of story.

That you can write :

void foo (int*);

foo (0);

doesn't mean the expression 0 suddenly has type int*, just as 1 doesn't has type float in the following:

void foo (float);

foo (1);

the preprocessor macro NULL, which expands to either ((void*)0) or 0.

...or OL or ((short)0) or (2*2-4) or ((void*)(2*2-4)) or any integral constant expression (compile-time computed expression with type char, short, int, long, unsigned char...) with value 0, or any such expression casted to void*.

However, the only two common choices in C are 0 or ((void*)0).

When C++ adopted this behavior, additional ambiguities were created due to other design decisions in C++. Implicit conversion from type void* to other pointer types is not permitted, so NULL must be defined as 0 in order for statements like char* c = NULL; to compile.

No, this is unrelated and a deep mistake (and BS made confused statements about it).

In either C or C++, an integer (an arbitrary expression with integral type) isn't convertible to a pointer :

int i = 0;
int *p = i; /* error in both C and C++ */
int *q = 0; /* ok */

but the expression 0 is convertible to a pointer, because it's a null pointer constant.

So it's only a matter of how null pointer constants are defined. Had C++ (BS) defined ((void*)0) as a null pointer constant, the following would be valid:

int *p = (void*)0;

BS didn't made this choice, the committee didn't revisit his decision, but to say this was about converting void* to T* is dishonest. It was and is only about the definition of null pointer constants.

void foo(char *);
void foo(int);

The statement foo(NULL); will call foo(int), which is almost certainly not what the programmer intended.

Not so fast! Only true if NULL is defined as 0 or (2*2-4) or ((short)0).

If NULL is defined as 0L, for example, the first function will match with a pointer conversion (long -> char*), and the second with an integer conversion (long -> int); both implicit conversion sequences have conversion rank, and none is better than the other. As no match is better than all others, the call is ambiguous.

C++ compilers usually simply define NULL as 0 but they don't have to according to C++98 or C++03, so the statement needs to be qualified properly.

If the new syntax is a success, the C++ committee could declare deprecated the usage of 0 and NULL as null pointers, and eventually abolish this double role.