|
|
Home » Community » Coffee corner » C++11
|
Re: C++11 [message #34072 is a reply to message #34034] |
Fri, 14 October 2011 12:18 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
Mindtraveller wrote on Wed, 12 October 2011 05:20 | http://en.wikipedia.org/wiki/C%2B%2B11
New version of C++ is finally out.
What do you think about it?
Will it change anything in how we use U++?
|
Unlikely. The closest thing that might have been useful for us is r-value references, which has the potential of replacing pick_. Unfortunately it does not compose, so directly replacing pick_ with && would break existing code. I do not know, MAYBE it would be worth it, after all there is only a couple of places where composition of pick is really used, OTOH fixing them would be pretty annoying.
What I mean by composition:
struct Foo {
int a;
Vector<int> foo;
};
in U++, this struct has well defined computer generated pick constructor and pick assignment.
Would pick_ be replaced by &&, it would have neither. Programmer would have to define special Foo(&&) constructor and operator=(&&). With some structs with dozen members, it would be tedious and error-prone.
Mirek
|
|
|
|
Re: C++11 [message #36652 is a reply to message #34034] |
Sun, 24 June 2012 09:51 |
|
Hi everyone,
Allan McRae (one of the major devs of Arch Linux) wrote a series of nice and short articles about C++11 features. They're written for average joe programmer and I learned quite some new thing from them about the new standard. I really recommend them to anyone who haven't yet had the time yet to study C++11 changelist
From the features discussed in the first 5 articles, two would be IMHO useful for U++:
Initializer lists would be definitely a neat feature to have in U++ containers. We could than write things like "Vector v {10,3,12,8};" instead of "Vector v; v.Add(10); v.Add(3); v.Add(12); v.Add(8);". And if I understand correctly, we could also add some methods to do stuff like "v.Add({10,3,12,8});". The initializer_list works little bit similar to tuple, but it is syntactically much simpler and readable. It should be pretty easy to implement in U++, with backward compatibility assured by a flag.
Extern templates could speed up U++ compilation. The speedup should be significant for non-BLITZ case and probably noticeable even with BLITZ on. There might be however problems to implement a backward compatible usage of the extern templates...
As for the compiler support: GCC and Clang support is very good. I don't know about MSVC...
Best regards,
Honza
|
|
|
Re: C++11 [message #36661 is a reply to message #36652] |
Sun, 24 June 2012 12:50 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
dolik.rce wrote on Sun, 24 June 2012 03:51 | We could than write things like "Vector v {10,3,12,8};" instead of "Vector v; v.Add(10); v.Add(3); v.Add(12); v.Add(8);". And if I understand correctly, we could
|
Well, you can also write, in "old" C++ and current U++
Vector v<int> = Vector<int>() << 10 << 3 << 12 << 8;
or
Vector v<int>;
v << 10 << 3 << 12 << 8;
which really is just a tiny bit more verbose (but right, it would run a bit slower than best C++11 implementation).
For me, the C++11 feature I like the most is 'auto'. Anyway, generally, I still have feeling that "polluting" U++ code with C++11 is not worth it for now. Perhaps in another 5 years...
|
|
|
Re: C++11 [message #36662 is a reply to message #36661] |
Sun, 24 June 2012 13:02 |
|
[quote title=mirek wrote on Sun, 24 June 2012 06:50]dolik.rce wrote on Sun, 24 June 2012 03:51 |
For me, the C++11 feature I like the most is 'auto'. Anyway, generally, I still have feeling that "polluting" U++ code with C++11 is not worth it for now. Perhaps in another 5 years...
|
I would also adjust u++ containers to work with C++11 foreach.
|
|
|
|
|
Re: C++11 [message #36671 is a reply to message #36664] |
Sun, 24 June 2012 16:24 |
|
mirek wrote on Sun, 24 June 2012 13:13 |
GUI_APP_MAIN
{
Vector<int> v;
v << 1 << 2 << 3;
for(int& x: v)
LOG(x);
}
|
Or even with auto:
GUI_APP_MAIN
{
Vector<int> v;
v << 1 << 2 << 3;
for(auto& x: v)
LOG(x);
}
I agree that the intializer list syntax provides the same functionality as already existing code. The performance gain is not important because initialization shouldn't happen much in performance oriented code (where one should generaly reuse existing containers as much as possible). OTOH it is easy to read and I think the simplicity of it fits nice into U++. Also, the sooner people start encountering c++11 code in real world examples, the sooner it gets widely adopted, so maybe we could give a good example to the world It can't hurt, even if it stays semi-hidden under flag USECXX11 (or similar) for a first few years. This is just my opinion, and I don't force it to anyone... but I will probably starte experiment in this direction soon, and I will most probably try to show here what I can come up with
Honza
|
|
|
Re: C++11 [message #36703 is a reply to message #36671] |
Wed, 27 June 2012 01:29 |
lectus
Messages: 329 Registered: September 2006 Location: Brazil
|
Senior Member |
|
|
Interesting.
I was testing this stuff and I had to add -std=c++0x to the compiler options
Looks like a very clean way to iterate through a container.
Very handy indeed. I can say things like:
Vector<int> range(int x, int y) {
Vector<int> v;
for(int i=x; i<=y; i++)
v.Add(i);
return v;
}
...
for(auto x: range(0, 10))
arrayCtrl1.Add(x);
[Updated on: Wed, 27 June 2012 01:54] Report message to a moderator
|
|
|
|
|
|
|
Re: C++11 [message #38134 is a reply to message #38131] |
Sun, 02 December 2012 16:04 |
|
Lance wrote on Sun, 02 December 2012 15:08 | I think eventually U++ should get rid of pick_ and make use of rvalue reference instead. rvalue reference solves the same problem pick_ saught to solve and is standard compliant, and behaves more consistent across compilers: I believe pick_ is #define'd to different things on MSVC from on g++, and to avoid conflicts, U++ has to introduce a dummy parameter for deep copy semantics.
|
Hi Lance,
If I understand both picking and rvalue references correctly, there is still a very valid reason to keep using picking: Rvalue references work ONLY on temporary objects. In U++, you can use picking on any object and even reuse it, assuming you clean it up after it has been picked, typically by calling Clear() or by assigning content from another object. I think this can not be done simply with rvalues.
Also, I believe that introduction of move semantics to C++11 standard will actually make it easier to explain U++ pick to new programmers, because they will already be familiar with the concept. We should just adapt the introductory documentation to explain how pick constructor is similar to move constructor, what is different and how U++ further extends this concept.
Honza
EDIT: After bit more reading, I found you can actually make it work with any object, using std::move... Right now, that seems downright ugly and hackish to me I guess I need to read even more before I can make my mind whether the switch to move semantics is a good or bad idea.
[Updated on: Sun, 02 December 2012 16:13] Report message to a moderator
|
|
|
|
|
|
Re: C++11 [message #38149 is a reply to message #38147] |
Sun, 02 December 2012 20:12 |
|
Lance wrote on Sun, 02 December 2012 19:30 | If U++ will adopt rvalue references, will it create the possibility of getting rid of Vector and many other containers/algorithms? Mirek will know better. My feeling is that in many a situation, the answer probably is 'yes'. If that is true, moving code into and out of U++ could be greatly simplified.
| Actually many of the containers are already compatibly with STL (search for STL_*_COMPATIBILITY in Core). So things wouldn't get much easier than they are now. Another thing is that there are not only differences in move semantics, but also in algorithms used, interfaces and possibly other, so there are still reasons to keep the U++ containers. Not even to mention that you have to think about backwards compatibility
Honza
|
|
|
|
Goto Forum:
Current Time: Fri Nov 01 00:09:51 CET 2024
Total time taken to generate the page: 0.03083 seconds
|
|
|