1. Some Syntax
First of all the new function definition syntax! Now I can write something like*:
using PF [](double) -> void;along the lines of lambda function definition! Well, that's definitely a treat, what a relief from
typedef void (*PF) (double);
To be honest, I don't know if I've got the last one right, I have always to look thes syntax up or copy and paste from my other code! The [] notation can be generally used to say to the compiler that "the function type will be specified later"! Thusly we can write the following when usign embedded type like List::Link
[] List::erase(Link* l) -> Link* { ... } ;We postpone the return type definition utill we have entered the scope of List, and thus no scope specifier is needed!I liked this notation (it makes the code look a little Groovy-like), but alas, it seems that not everyone does so, as the related "auto arrow" notation proposal was rejected recently**! What is auto-arrow? Look at that***:
auto f() -> int;the first one is a function from void to int, and the second one is a function type definition for the same signature. Looks good enough, but consider this one:
typedef auto PF() -> int;
auto *pf(auto *p() -> int) -> auto *()->int;I don't even want to discuss what it means, if you are curious look it up in ***! So after that proposal was justly rejected, I'm a little afraid of the fate of the [] notation - is it the next one to be scrutinized? I hope not!
2. Initalization and initializers
I though I've understood the new initalizer notation, but I was surprized how ubiquitous it became! At first I though it would be only used in assignment like
vector<int> xs = {1, 2, 3 };Not so, nowadays you can use it (i.e. the new {} notation) everywhere, even instead of classic parentheses! X x{a};
f({a}); // initializes a temporary
X* p = new X{a};This all does look pretty strange to me, and to be honest I don't like it that much, but on the other side you can use it to avoid verbosity with pretty good results: map1.insert({a, b}); // sic!The other improvement with initialization is that we can initialize the string and integer class members directly in the definition of the class!class XI can only say AT LAST and amen!!!
{
int a = 7;
string s{"abcd"}; // new syntax!
};
Belonging to the "initialization" block of features, we must mention the access to the inherited constructors (in addition to the also new feature of delegating constructors, i.e. constructors which can be invoked of another constructors of the same class):
class A { public: A(){} };
class B : public A
{
using A::A; // imports all the A's constructors into current scope!
};// now this is possible:At this place I'd like to mention another related feature: disallowing copy and assignment operators. You can write for example:
B b;
X& operator= (const& X) = delete;to disallow it! Well, if I consider that Google even has a macro exaclty for that reason (DISALLOW_COPY_AND_ASSIGN(), see here) and that I used an UML tool to generate the private version of it for my every class I think that the default-generating them was a bad language design idea! If we want a copy semantics we'd better tell the compiler so! Hindsight is 20/20.
3. Threading etc.
Of course thread, mutex, condition variables and atomics are there as basic support (as expected). On the higher level we have futures and a packaged_task class, which wraps features for simpler usage. Moreover, Bjarne does promise that an async task launcher (logically named async) will be included in C++0x as well. Then we could launch tasks simply like that:
auto f1{async(funcX(100))};
auto f2{async(funcX(200))}; return f1.get() + f2.get(); // waits on both futuresIf he's right it would be very nice!As GC is connected to multithreading in an intimate way (at least in my eyes, sholud blog about it some time soon!), I must state here that the GC is still missing!
But not entirely, we've got some minimal support for third party garbage collectors in there (20.8.13.7 Pointer safety). It defines what a "safely drived" (i.e reacheable) or an "disgused" pointer is (3.7.4.3 Safely-derived pointers) and lets the programmer specify where such pointers can/cannot be found with declare_reachable()/declare_no_pointers() functions.
One thing that struck me however in the threading library classes is the flexibility of interfaces. Take the std::thread's constructor for example. You can use it like that ****:
void hello_func() { ... }
// say hello
std::thread t{hello_func};or like that, using a functor: class Greetingor currying the thread function with std::bind:
{
public:
explicit Greeting(std::string const& message) { ... }
void operator()() const { ... }
void greet(std::string const& message) const { ... }
};
// say goodbye
std::thread t(Greeting("goodbye"));
void greeting_func(std::string const& message) { ... }
std::thread t(std::bind(greeting_func, "hi!"));or without std::bind:std::thread t(greeting_func, "hi!");or without std::bind and with more arguments:
void write_sum(int x, int y){ ... }
std::thread t(write_sum, 123, 456);or using the member function pointerGreeting x;See, you don't need to worry about the initalization, the new constructs will just take anything you throw at it!
std::thread t(&Greeting::greet, &x, "greet");
// or by a smart pointer
std::shared_ptr<Greeting> ptr(new Greeting);
std::thread t1(&Greeting::greet, ptr, "hello");
// or by reference
std::thread t2(std::ref(x));
// or directly!
std::thread t2(x);
4. Miscellanea
First the variadic templates. What a name for templates with viariable number of arguments! I guess it's an interpolation of the "dyadic" concept which just means "of two arguments" :-). But seriously, we can writhe things like
template<typename Head, typename... Tail>doing recursion and typematching like in Clojure or Haskell ;-) Well a kind of, but it looks like that at least. Look at the n-tuple definition using variadic templates in Bjarne's FAQ*.
Further, the new and improved enums (which are class based now) can be now forward defined ! But I'm doing this all the time with C++ Visual Studio 2005! Ouch...
No for the geeky ones: we have user defined literals! You can define new literal types using the following new operator type: operator""() (plus constexpr!), for example
"abc"s; // s: string literalFor details have a look at Bjarne's FAQ*. NIce feature, but will I use it? It is readable for the maintainer? We'll see.
2i; // i: imaginary literal
The next 2 features look to me as if they came straight from Python. First the raw strings:
string s = R"[ahjh/?=(%/$§%§%\w\\w///]";Why not just R"..."? Dunno. Next the foreach variant of the old for() loop.Together with initilizers we can now have some Python feeling in C++:
vector<string> xs = {"aba", "bab", "aab" };
for(auto x:xs) cout << x; // x:xs looks even a little Haskell-like ;-))So there are many new things, some of them making C++ look like entirely another language. No I wonder - will the C++ programmers use it, or will they stuck to the old, but known evil (like the old function definition syntax)?
---
*Bjarne's "C++0x - the next ISO C++ standard", http://www2.research.att.com/~bs/C++0xFAQ.html
** Danny Kalev: "The Rejection of the Unified Function Syntax Proposal", http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=460
*** Daveed Vandevoorde: "The Syntax of auto Declarations", http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2337.pdf
**** for completness' sake, the examples are partially taken from: http://www.justsoftwaresolutions.co.uk/threading/multithreading-in-c++0x-part-1-starting-threads.html
Just popping in to say nice site.
ReplyDelete