Printable View
Bjarne Stroustrup is visiting the University of Waterloo next week to talk about the new C++ standard, C++0x. He will be responding to questions at the end of the talk, so I am offering to ask a few questions in person for members of the CProgramming forums.
Some research links for C++0x:
http://en.wikipedia.org/wiki/C++0x
http://www.research.att.com/~bs/rules.pdf
http://www.artima.com/cppsource/cpp0x.html
This is a great idea. I've always wondered why the standard did not require all overrides in derived classes to use 'virtual.', since it requires the base to use virtual in order to make it a virtual function.Quote:
Explicit override syntax
In standard C++, derived classes override base class functions specified as virtual. Base classes must explicitly define a function as virtual in order for it to be so. However, derived classes are not required to use the keyword virtual for their overriding. Additionally, it is possible to misspell a function name, or use the wrong parameter list, which results not in overriding, but in the creation of a new function or overload by accident. Lastly, it is possible to introduce a new virtual function in a derived class, but the author of the base class introduces a new virtual function with the same name and signature in the base class at a later time, causing unusual behavior.
C++0x fixes all of these problems. The derived class can be marked with the keyword explicit, which forces the derived class to be more specific about its intensions with regard to virtual functions:
Code:class BaseClass
{
virtual void Func1();
virtual void Func2(int);
};
class DerivedClass explicit : public BaseClass
{
virtual void Func1(); //Overrides BaseClass::Func1
void Func2(int); //Illegal. Must use keyword ''virtual'' for overrides
new virtual void Func3(int); //Introduces a new virtual function.
virtual void Func4(float); //Illegal. Must use keyword ''new'' for new virtuals
virtual int Func2(int); //Illegal. Signature does not match BaseClass::Func2;
};
Not so sure I like the 'new' keyword being used as a prefix to a function declaration. That introduces some ambiguity on what it is that 'new' does. New in this instance is not truly allocating memory for a function. Even though all of us know that when we create a function the compiler must reserve memory at run time for the function using new like this is quite confusing. It is not the programmer who is actively reserving memory for a function as in the case of allocating space for an array or class object. So using new in this fashion really confuses the issue at hand and in my opinion does not follow with how new should be used. So basically we will have the same 'new' keyword but what that does will depend entirely on the context in which it is used in. If used prior to a virtual function in a derived class it will create a new virtual function. If used to allocate memory it will behave the same as 'new' has in past standards.Quote:
Code:new virtual void Func3(int); //Introduces a new virtual function.
I don't like this at all.
Smart pointers?
I did not see anything about smart pointers being a part of the new standard but I admit I did not read the all of the text so it might be in there. If not this disturbs me since boost has implemented several types of smart pointers and shared pointers. At the very least the C++ language could support it's own 'smart', 'shared', 'weak', etc, pointer types.
Should we really have to use code tags inside of quote blocks?
The TR1 library already includes smart pointers (from boost's library) and C++0x will as well.
http://en.wikipedia.org/wiki/C++0x#G...smart_pointers
Will this manifest during the youth of my life.
Given that it's actually called C++09 now, and not C++0x, yes it will, as long as you consider yourself young in 2009.Quote:
Originally Posted by indigo0086
The biggest part of C++09 is going to be the rvalue references. Those are a big big big deal. GCC 4.3 apparently has them implemented already, but 4.3 isn't released yet, and I lack the courage to try it.
New CodeWarrior versions have r-value references, too (they were the first, in fact), and I think Comeau also. And yes, they will be huge. I believe that they will fundamentally change the way we write interfaces.
So they overloaded the keyword. Big deal. "virtual" has two meanings (related but clearly distinct), depending on whether it prefixes a function or a base class. "static" has three different meanings, depending on the scope of the variable/function declaration/definition it prefixes. "throw" has two meanings. "class" and "typename" both have two meanings. "const" has two meanings. "extern" has two meanings. Several other keywords can be used with slightly differing meanings in different contexts (e.g. while in a while vs a do-while loop). Operators are overloaded until they collapse. And C++09 will introduce additional overloads for both operators and existing keywords (auto, default, delete, explicit and new are those I know have been under consideration).Quote:
Not so sure I like the 'new' keyword being used as a prefix to a function declaration. That introduces some ambiguity on what it is that 'new' does.
At least the new meaning of new has something the others don't have: there's prior use of this (or a very similar) meaning in a different language, namely C#.
So it's not like this is something exceptional.
I'm still hoping it ticks over a year so we can get C++0AQuote:
Originally Posted by AverageSoftware
The alternative would be to introduce another keyword and that's not something that they want to do. "explicit" is also used for somewhat different purposes now and we already have "static" from before. They only way they could've instroduced new keywords would've been like "_ _ keyword".Quote:
Originally Posted by Bubba
I personally have absolutely no problem with ambiguity, because when I look at a class declaration I expect to see no memory allocation. There is no problem for a human here. The exception would be if you executed grep or something to see all lines where memory was allocated.
Not true. They're introducing quite a few new keywords. concept, concept_map, various others. But they're trying to keep the number low and not use a new keyword if an existing one is sufficient. And they're trying to use keywords that won't have a big effect on existing code. Code search engines are very useful for this.Quote:
They only way they could've instroduced new keywords would've been like "_ _ keyword".
Jeff! You're on campus now? I guess I'll see you at that talk! :P
The talk was quite interesting. He clarified that it isn't yet C++09, but he hopes that it will become that (if not, C++0xA). He did mention the topic of smart pointers, but also mentioned that they do slightly worry him, given that they can cause coders to be sloppy, and think that that causes their pointers to be pretty much safe from any problems (such as race conditions, etc).
Two concepts that he introduced that I really liked were the initializer list, which functions as follows (if I recall):
And also the concept of being able to assign traits to a template, i.e. state that your function takes a parameter that must support the preincrement operator (++foo) and the unary asterisk (*a) operator, etc.Code:class foo
{
public:
foo(std::initializer_list<int> Args);
};
...
foo a {1, 2, 3};
foo b = foo{1, 2, 3};
One other thing I just remembered is a new loop syntax:
This causes e to iterate through all elements of the foo vector, and also causes the type of e to be the type associated with the foo vector (in this case, int).Code:vector<int> foo{1,2,3};
...
for(const auto& e : foo)
{
...
}
...
A couple other neat things such as regexs and threading/thread pools appear to be coming as well, but I can't remember details, as I just got back from taking Stroustrup out to a bar after his talk.
Heheh, a for each loop after we have a for_each() algorithm.Quote:
This causes e to iterate through all elements of the foo vector, and also causes the type of e to be the type associated with the foo vector (in this case, int).
But you have to admit the new for loop is so much prettier than the current for_each algorithm.
One of the things he emphasized in the talk is that they are putting effort in to making the language more accessible to novices. No, that doesn't mean we're going to have forced garbage collection and all objects are references *cringes* but we will be seing many things introduced that make sense.
Building off of what XSquared noted, we'll finally see some clarity in template errors with the introduction of "requirements" on templated functions. This essentially seems to allow the programmer to inform compiler on what kind of functionality the function will require, giving room for the compiler to serve up errors before compiling the templated function (e.g. Error: your class requires the increment operator, as opposed to the confusing template errors we're all familiar with).
He also briefly alluded to possibly cleaning up the syntax for function pointers (pointing out that even he finds them convoluted), such that returning a function pointer doesn't require the use of a typedef. This is something I think a lot of people will probably cheer about.
And XSquared: the least you could have done was invite me over for some drinks when you two were at the pub. Sheesh.
Actually, it was about 10 of us from the CSC (folks who ran the event) who ended up going out with Bjarne to the Bomber after the talk for about an hour. Really cool guy.
It's unfortunate that we won't be able to post the video of the talk like we do for the rest of the events that we run, because it was definitely a neat talk.
Why can't you guys post it?
Turns out that Texas A&M won't allow videos of their profs lectures to be posted online, and apparently this type of lecture is included in that rule.
Yeah smart pointers are mentioned in there (the wikipedia article i mean). Near the top actually:Quote:
Smart pointers?
I did not see anything about smart pointers being a part of the new standard but I admit I did not read the all of the text so it might be in there.
I had a couple of questions. Here is a quote from the Wikipedia article:Quote:
Despite this, many people insist that C++ include some mechanism for safe management of the pointer. For this reason, the new standard will provide support for smart pointers, but only through the standard library.
I understand their logic here...but if they make a high level library, the threads won't have very high priority and won't be very powerful, true?Quote:
The C++ standard committee plans to introduce some tools for multiprocessing and multithreaded programming.
At this stage, full support for multiprocessing appears too dependent on the operating system used, and too complex to be resolved only through an extension of the core language. The common understanding is that multiprocessing support shall be created via a high-level library instead of a low-level library (with potentially dangerous synchronization primitives), as the Committee's goal is not to motivate programmers to use a potentially dangerous standard library instead of a secure but non-standardized library.
Another quote:
Could this atomic key word be used in place of mutex locks and semaphores? If the thread in execution cannot be interrupted, then basically it has locked out all other threads from executing until it finishes....although it is not completely the same as a mutex lock, it can have a similar effect.Quote:
Atomic operations
Often, a thread needs to perform a task without being interrupted. For example, a thread might require exclusive access to a global variable or real-time access to a peripheral.
To perform such an atomic operation, a new keyword atomic has been proposed
ad Threads: that's news to me. Right now, the proposals to the committee are definitely headed towards low-level threading. Still library-based, but low-level.
ad Atomic: Haven't seen the proposal for this atomic keyword. If it works as described, it would simply be a single, global mutex. In other words, completely useless for most multi-threaded programs.