Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » C++11
C++11 [message #34034] Wed, 12 October 2011 11:20 Go to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

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++?
Re: C++11 [message #34072 is a reply to message #34034] Fri, 14 October 2011 12:18 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 13442
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 #34647 is a reply to message #34034] Sat, 03 December 2011 12:03 Go to previous messageGo to next message
lectus is currently offline  lectus
Messages: 329
Registered: September 2006
Location: Brazil
Senior Member
Interesting.
What compilers already support C++11?
Re: C++11 [message #36652 is a reply to message #34034] Sun, 24 June 2012 09:51 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1781
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Wink

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 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 13442
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 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1363
Registered: November 2005
Location: Poland
Ultimate Contributor

[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 #36664 is a reply to message #36662] Sun, 24 June 2012 13:13 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 13442
Registered: November 2005
Ultimate Member
[quote title=unodgs wrote on Sun, 24 June 2012 07:02]
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.


Should not it work without adjusting? We do have begin/end defined already...

Mirek

Update: Confirmed

GUI_APP_MAIN
{
	Vector<int> v;
	v << 1 << 2 << 3;
	for(int& x: v)
		LOG(x);
}
Re: C++11 [message #36665 is a reply to message #36664] Sun, 24 June 2012 13:21 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1363
Registered: November 2005
Location: Poland
Ultimate Contributor

Excellent! (I thought some kind of new interface must be implemented)
Re: C++11 [message #36671 is a reply to message #36664] Sun, 24 June 2012 16:24 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1781
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Wink 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 Wink

Honza
Re: C++11 [message #36703 is a reply to message #36671] Wed, 27 June 2012 01:29 Go to previous messageGo to next message
lectus is currently offline  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 #36712 is a reply to message #36703] Thu, 28 June 2012 08:16 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 13442
Registered: November 2005
Ultimate Member
BTW:

http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a spx

Re: C++11 [message #38120 is a reply to message #36712] Sun, 02 December 2012 06:18 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 380
Registered: March 2007
Senior Member
For people who are interested in C++11, here is a pretty good book:

https://www.dropbox.com/s/pwpinrlme0hzhxp/%28Overview.of.the .New.C.%EF%BC%9AC.0x%29.Scott.Meyers.pdf
Re: C++11 [message #38123 is a reply to message #34647] Sun, 02 December 2012 08:35 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
lectus wrote on Sat, 03 December 2011 03:03

Interesting.
What compilers already support C++11?


MSVC 2012 compilers support C++11/c++0x

Having the auto setup for those compilers would be good.
Re: C++11 [message #38131 is a reply to message #38123] Sun, 02 December 2012 15:08 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 380
Registered: March 2007
Senior Member
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.

Last time when I mentioned this, Mirek said something like pick_ had more degree of automation; for the same purpose rvalue reference might involve more coding. But the benefit of switching might overwhelm the cost. C++ programmers turning to U++ will appreciate the effort saved for learning pick_ and will find the code easier to understand. U++ programmers don't have to speak a special dialect when there is no compelling reason for that.

The only problem IMHO is the resources needed to implement the switch. It's bound to take a lot of time and break a lot of user codes, unless somebody can write a parser to automate the process.
Re: C++11 [message #38134 is a reply to message #38131] Sun, 02 December 2012 16:04 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1781
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Smile 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 #38143 is a reply to message #38134] Sun, 02 December 2012 18:05 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 380
Registered: March 2007
Senior Member
Honza, you are right. A named object has to be std:move()'ed to communicate its moveable (temporary) status to the compiler, even when it's declared as temporary (using &&). std::move will appear a lot in new library code and user code as well, so people will get use to it soon.

You can do in move assignments or move constructors the same thing you used to do in pick constructor and pick assignment, eg, mark the right hand object as picked.

Now we can do
Vector<int> b=std:move(anotherVectorIntInstance); // move construction;

//or
Vector<int> b=anotherVectorIntInstance; //copy construction or deep copy, instead of
Vector<int> b(anotherVectorIntInstance, 0); // using dummy param to signal the intention of deep copy.

provide the underlying U++ facilities are modified using the rvalue reference language feature.

Re: C++11 [message #38144 is a reply to message #38143] Sun, 02 December 2012 18:47 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 380
Registered: March 2007
Senior Member
And any object can be std::move()'ed to become moveable, no matter it's a temporary or not.

#include <iostream>
#include <string>
#include <algorithm>
#include <new>

using namespace std;

struct S
{
	S(){}
	S(const S& rhs) : text(rhs.text){}
	S(S&& rhs){
		struct T{ char _[sizeof(S)]; };
		std::swap(reinterpret_cast<T&>(*this), 
			reinterpret_cast<T&>(rhs)
		);
	}

	S& operator=(const S& rhs)
	{
		this->~S();
		return *new(this)S(rhs);
	}

	S& operator=(S&& rhs)
	{
		this->~S();
		// std::move() is necessary even when rhs is declared as temoprary
		return *new(this)S(move(rhs));
	}
	
	string text;
		
};
ostream& operator<<(ostream& os, const S& s)
{
	return os<<s.text<<endl;
}



S global;



int main()
{
	global.text="This is the global text";
	cout<<global;
	
	S a;
	a.text="This is object a";
	
	// 
	//
	S b(a);
	cout<<"after S b(a), now <b> is:"<<b<<"and <a> is:"<<a;
	
	S c(std::move(global)); // use move constructor
	cout<<"after S c=std::move(global), now <c> is:"<<c<<"and <global> is:"<<global;
	
}
Re: C++11 [message #38147 is a reply to message #38144] Sun, 02 December 2012 19:30 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 380
Registered: March 2007
Senior Member
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.
Re: C++11 [message #38149 is a reply to message #38147] Sun, 02 December 2012 20:12 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1781
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Wink

Honza
Re: C++11 [message #38150 is a reply to message #38149] Sun, 02 December 2012 21:00 Go to previous messageGo to previous message
Lance is currently offline  Lance
Messages: 380
Registered: March 2007
Senior Member
Hi Honza:

Thanks. I didn't know that.

It's probably better not to touch it at all, or add some additional interfaces to incorporate rvalue reference so that existing code doesn't break. But in that way copy construction/assignment still means pick_, and for deep copy, so that a class moving into U++ may have to revise its related constructors/= to behave correctly in U++.

A class not written with pick_ in mind will(or may?) not work correctly with Upp::Vector<>, even if it meets all the interface requirements superficially.

I agree benefit gain doesn't seem to justify the work involved and problems it may created.
Previous Topic: live session Prague 8.3.2013
Next Topic: Have Visual Studio? Looking for prebuilt SDL 2.0
Goto Forum:
  


Current Time: Tue Oct 19 20:25:32 CEST 2021

Total time taken to generate the page: 0.01690 seconds