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 » Pick overloaded by Rvalue?
Pick overloaded by Rvalue? [message #19088] Tue, 11 November 2008 23:44 Go to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
Hi,
Will pick concept be available with new C++0x standard or it will disappear letting his place to Rvalue references?

Taking the next simple example, it behave like using pick for the returned data of the function, no copy-constructor or = op. is involved.

// rval.cpp
#include <iostream>
using namespace std;

class X
{
public:
	X()
	{
		cout << "Def ctor\n";
	}
	~X()
	{
		cout << "Def dtor\n";
	}
	X(const X& )
	{
		cout << "Def cpyctor\n";
	}
	void Msg()
	{
		cout << "Showing a message\n";
	}
	X& operator=(X& )
	{
		cout << "= op\n";
		return *this;
	}
};

X fun()
{
	cout << "In fun(), before X x;\n";
	X x;
	cout << "In fun(), after X x;\n";
	return x;
}

int main()
{
	X&& x = fun();
	x.Msg();
	return 0;
}


Quote:

g++ rval.cpp -o rval -std=c++0x


If that, have MS introduced(or will) rvalues in their compiler?
Seems g++ is ready for rvalue;

I think because rvalues references are implemented in languages they will be faster than pick concept(which still need copy constructor).

Also i don't know how utf-8 strings will be treated in new standard but if they will be then which string implementation will Upp use it's own or one provided by standard? Porting upp to "new C++" will require some effort Rolling Eyes .


cdabbd745f1234c2751ee1f932d1dd75
Re: Pick overloaded by Rvalue? [message #19089 is a reply to message #19088] Wed, 12 November 2008 00:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Unfortunately, the main disadvantage of rvalue references is that they do not compose:

struct Foo {
Vector<int> x, y;
};

- such construct would lack auto-generated pick constructor.

IMO, that is the major drawback (here it is simple, but consider nontrivial case with 20 data members... plus, adding any member, you have to check carefully that you have adjusted the constructor too).

(And yes, I have tried to persuade Howard Hinnant to change this, but has not succeeded).

Mirek
Re: Pick overloaded by Rvalue? [message #19091 is a reply to message #19089] Wed, 12 November 2008 08:01 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Well I/m more interested in this: Uniform initialization and initialization lists. Seems like GCC can handle this.
Re: Pick overloaded by Rvalue? [message #19092 is a reply to message #19091] Wed, 12 November 2008 10:48 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
cbpporter wrote on Wed, 12 November 2008 09:01

Well I/m more interested in this: Uniform initialization and initialization lists. Seems like GCC can handle this.


I've tried some examples given there but just few work with my g++(4.3.2). For example initializers for POD types work but for types from std library it doesn't work.
Work for:

int i = {1};
double du[] = {2.2, 3.3, 4.4};

Doesn't work for:

std::map<std::string,int> anim = { {"bear",4}, {"cassowary",2}, {"tiger",7} };
std::vector<std::string> vstr = {"Hello", "World", "!"};
std::complex<double> z{1,2};



Some errors:

init.cpp: In function ‘int main()’:
init.cpp:23: error: braces around scalar initializer for type ‘std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> > >’


Are these features implemented later in g++, in new versions of g++ from svn?


cdabbd745f1234c2751ee1f932d1dd75
Re: Pick overloaded by Rvalue? [message #19093 is a reply to message #19091] Wed, 12 November 2008 11:00 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 12 November 2008 02:01

Well I/m more interested in this: Uniform initialization and initialization lists. Seems like GCC can handle this.


Well, these are nice, but I really do not understand the energy put into them.

IMO, they do not significantly improve the way how we can write the C++ code.

Mirek
Re: Pick overloaded by Rvalue? [message #19095 is a reply to message #19093] Wed, 12 November 2008 12:20 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
luzr wrote on Wed, 12 November 2008 12:00


IMO, they do not significantly improve the way how we can write the C++ code.

Mirek


I think is simple to write:
Upp::Vector<Upp::String> vs = {"Header1", "Header2", "Something else", "and so on..."};

rather than:
Upp::Vector<Upp::String> vs;
vs.Add("Header1");
vs.Add("Header2");
vs.Add("Something else");
vs.Add("and so on...");


First version is typing less.

Now i'm not really happy with what C++ become...
Because new additions to the language it tend to be too "expert friendly" and still lagging behind other languages at "Standard Library" chapter. For example is simple to make programs in Java, C#, Python having unicode support, sql, etc. so we don't need to reinvent the wheel for every platform.
Now it's not enough that i have more than 10 books about C++, I'll have to buy another treating differences between C++98 and C++0x or perhaps Dr. Bjarne Stroustrup will make another 1092 pages book named "The C++ Programming Language - Special Edition 4 - C++0x" Mad Now i think i know why Linus Torvalds doesn't like C++ Laughing
It's just me or seems that C++ language is going down? Rolling Eyes
BTW, do you know that the draft C++0x standard it's just 1314 pages about? What lucky we are...


cdabbd745f1234c2751ee1f932d1dd75
Re: Pick overloaded by Rvalue? [message #19099 is a reply to message #19095] Wed, 12 November 2008 16:05 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well, I'm back with properties "a-la-Borland", which, being just a shortcut, can handle nicely the rvalue/lvalue problem AND some other stuffs.
I really don't understand why a so simple construct can't be introduced in c++.

struct MyArray<T>
{
...............

property T operator[](int i) {read = readArr, write = writeArr}

T readArr(int i) { checkbounds(i) ; return buffer[i]; }

void writeArr(int i, T d) { copy_if_needed(i); buffer[i] = d;}
};

MyArray<int> arr;

arr[10] = 2; (uses writeArr())
int i = arr[2]; (uses readArr())

Max

[Updated on: Wed, 12 November 2008 16:07]

Report message to a moderator

Re: Pick overloaded by Rvalue? [message #19100 is a reply to message #19095] Wed, 12 November 2008 19:34 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

bytefield wrote on Wed, 12 November 2008 14:20

It's just me or seems that C++ language is going down? Rolling Eyes
It`s a pity but C++ is "smallest evil". It is just still powerful and effective. Some time ago it was discussion of C++ alternatives, and it looks like it is nothing as effective and powerful. Yes, we had discussion about D, but IMO it is still no match in cases of efficiency. So for now we have no adequate alternatives... Sad

[Updated on: Wed, 12 November 2008 19:35]

Report message to a moderator

Re: Pick overloaded by Rvalue? [message #19101 is a reply to message #19095] Wed, 12 November 2008 20:27 Go to previous messageGo to next message
captainc is currently offline  captainc
Messages: 278
Registered: December 2006
Location: New Jersey, USA
Experienced Member
Upp::Vector<Upp::String> vs;
vs.Add("Header1");
vs.Add("Header2");
vs.Add("Something else");
vs.Add("and so on...");

Can be written with overloaded operator<< and operator|
Like so:
<< represents .Add() method
Upp::Vector<Upp::String> vs;
vs << "Header1" << "Header2" << "Something else" << "and so on...";

or
| represents .AddPick() method
Upp::Vector<Upp::String> vs;
String hello("hello"), world("world");
vs | hello | world;


So we could probably do something like this for a one-liner:
Upp::Vector<Upp::String> vs = Upp::Vector<Upp::String>() << "Header1" << "Header2" << "Something else" << "and so on...";
though I haven't tested this yet.
Re: Pick overloaded by Rvalue? [message #19102 is a reply to message #19100] Wed, 12 November 2008 20:33 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
Mindtraveller wrote on Wed, 12 November 2008 20:34

bytefield wrote on Wed, 12 November 2008 14:20

It's just me or seems that C++ language is going down? Rolling Eyes
It`s a pity but C++ is "smallest evil". It is just still powerful and effective. Some time ago it was discussion of C++ alternatives, and it looks like it is nothing as effective and powerful. Yes, we had discussion about D, but IMO it is still no match in cases of efficiency. So for now we have no adequate alternatives... Sad


Well, it's still in top and that's matter. 3rd position is quite good for a language with such complexity and i think it will remain there(in top 3) for some years from now on.
I was talking with a colleague about C++ complexity and for those who know C++ new improvements added by new standardization aren't difficult to learn but just think at amount of information which have a beginner to learn, one who is starting with C++ from the ground up.

Quote:

Some time ago it was discussion of C++ alternatives, and it looks like it is nothing as effective and powerful.

Have you tried OOP with C? Razz I've read some papers that doing OOP is accessible also to C programmers but i wouldn't recommend doing that - take for example gtk+, it's object oriented but it's very hard to create a new widget in it without doing something wrong.


cdabbd745f1234c2751ee1f932d1dd75
Re: Pick overloaded by Rvalue? [message #19104 is a reply to message #19101] Wed, 12 November 2008 20:37 Go to previous messageGo to next message
bytefield is currently offline  bytefield
Messages: 210
Registered: December 2007
Experienced Member
captainc wrote on Wed, 12 November 2008 21:27


<< represents .Add() method
Upp::Vector<Upp::String> vs;
vs << "Header1" << "Header2" << "Something else" << "and so on...";



Ok, that's fine but think that you have to overload operator << for every container you have. Having initialization as in example specified by cbpporter let you using it with any type possible so we don't have to code for it.


cdabbd745f1234c2751ee1f932d1dd75
Re: Pick overloaded by Rvalue? [message #19107 is a reply to message #19095] Wed, 12 November 2008 21:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
bytefield wrote on Wed, 12 November 2008 06:20

luzr wrote on Wed, 12 November 2008 12:00


IMO, they do not significantly improve the way how we can write the C++ code.

Mirek


I think is simple to write:
Upp::Vector<Upp::String> vs = {"Header1", "Header2", "Something else", "and so on..."};

rather than:
Upp::Vector<Upp::String> vs;
vs.Add("Header1");
vs.Add("Header2");
vs.Add("Something else");
vs.Add("and so on...");


First version is typing less.



Sure, that is true, however, how often do you have to write this?

Mirek
Re: Pick overloaded by Rvalue? [message #19108 is a reply to message #19104] Wed, 12 November 2008 22:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
bytefield wrote on Wed, 12 November 2008 14:37

captainc wrote on Wed, 12 November 2008 21:27


<< represents .Add() method
Upp::Vector<Upp::String> vs;
vs << "Header1" << "Header2" << "Something else" << "and so on...";



Ok, that's fine but think that you have to overload operator << for every container you have. Having initialization as in example specified by cbpporter let you using it with any type possible so we don't have to code for it.


Well, AFAIK, you need to add specific methods as well.

BTW, you can write it even shorter:

Vector<String> vs = Vector<String>() << "Header1" << "Header2" << "Something else" << "and so on...";

As for C++ being evil/good/bad etc... I like C++ because

- there is no other language covering all areas from HW up to highest levels of abstraction

- this is the only language with destructors

- many alternatives lack efficient operator overloading

- templates are hard to learn, but are the most powerful, esp. w.r.t. efficiency

but there are some downsides too

- as it is pretty complex language, it is hard to get compiler right (fortunately, this mostly seems to be resolved now). Also, with preprocessor, it is hard to get development tools like Intellisense working well (but we have managed, right? Smile

- dynamic library APIs are difficult to maintain if you wish to use the real power of language

Mirek
Re: Pick overloaded by Rvalue? [message #19113 is a reply to message #19108] Wed, 12 November 2008 23:46 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

luzr wrote on Wed, 12 November 2008 16:04

Intellisense working well (but we have managed, right?


It's quite good, but there are some problems and regression bugs. I'll post a list of my problems soon.

BTW: Qt created QtCreator ide. It also has intelisense, but I didn't test it too hard yet. Link http://labs.trolltech.com/blogs/2008/10/31/qt-creator-tech-p review-released/
Re: Pick overloaded by Rvalue? [message #19114 is a reply to message #19113] Thu, 13 November 2008 00:20 Go to previous messageGo to next message
captainc is currently offline  captainc
Messages: 278
Registered: December 2006
Location: New Jersey, USA
Experienced Member
Quote:

- there is no other language covering all areas from HW up to highest levels of abstraction

- many alternatives lack efficient operator overloading

These 2 reasons are both good and bad. Much confusion comes from having operators do completely different things among different classes. In order to understand C++ code you didn't write yourself, you will have to read the entire codebase before you get a really good handle on what is going on. I think C++ code is the most difficult to maintain for this reason. Someone could have overloaded a simple operator globally and you are stuck looking at code expecting it to do one thing and not understanding why it is doing something else. If C++ code is not well documented, people will give up and write from scratch!

Quote:

- templates are hard to learn, but are the most powerful, esp. w.r.t. efficiency

Conceptually, templates are easy. But in implementation, there are so many rules surrounding them, especially the differences between compilers and how they handle templates, that it is difficult to master them.

I compare C++ to the English language; there are so many exceptions to the rules, that mastering the language cannot be accomplished in a short period of time.
Re: Pick overloaded by Rvalue? [message #19123 is a reply to message #19114] Thu, 13 November 2008 14:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
captainc wrote on Wed, 12 November 2008 18:20

Quote:

- there is no other language covering all areas from HW up to highest levels of abstraction

- many alternatives lack efficient operator overloading

These 2 reasons are both good and bad. Much confusion comes from having operators do completely different things among different classes. In order to understand C++ code you didn't write yourself, you will have to read the entire codebase before you get a really good handle on what is going on. I think C++ code is the most difficult to maintain for this reason. Someone could have overloaded a simple operator globally and you are stuck looking at code expecting it to do one thing and not understanding why it is doing something else.



I keep hearing this operator overloading argument all over again, but I am still unconvinced.

IMO, you can give wrong names to methods in Java and have the exactly same problem.

E.g. if you see something like

x.Put(y);

in Java, you have as much info as seeing

x << y;

Quote:


If C++ code is not well documented, people will give up and write from scratch!



No pun intended, right? ... RIGHT? Smile

Quote:


Conceptually, templates are easy. But in implementation, there are so many rules surrounding them, especially the differences between compilers and how they handle templates, that it is difficult to master them.



Well, but that is the compiler problem I have mentianed too, is not it?

Mirek
Re: Pick overloaded by Rvalue? [message #19124 is a reply to message #19113] Thu, 13 November 2008 14:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Quote:


It's quite good, but there are some problems and regression bugs. I'll post a list of my problems soon.



Check uppdev/Parser1-3 - there is where I store all "A++ bugs". Check the 'format' and try to prepare something similar if possible (e.g. uppdev/ParserUno1).

Thanks

Mirek

[Updated on: Thu, 13 November 2008 14:39]

Report message to a moderator

Re: Pick overloaded by Rvalue? [message #19223 is a reply to message #19124] Fri, 21 November 2008 14:17 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Here is a quick video overview of C++0x features: YouTube. The most important part is that that it won't be fully ready by 2011 as an ISO standard Laughing.
Re: Pick overloaded by Rvalue? [message #19227 is a reply to message #19223] Fri, 21 November 2008 19:48 Go to previous messageGo to next message
captainc is currently offline  captainc
Messages: 278
Registered: December 2006
Location: New Jersey, USA
Experienced Member
Yeah, I saw the date and was amazed that it would take till then. I thought they were not going to get features in because the release date was earlier. I don't know how I feel about that late date. I was excited to see C++ take its next step sooner.

In all, this just validates the need right now for a library like U++; Especially with its alternative approaches in the core libraries.

Though, some thought should be put in to how U++ will change when the new standard comes out.
Re: Pick overloaded by Rvalue? [message #19233 is a reply to message #19227] Sat, 22 November 2008 10:04 Go to previous messageGo to previous message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
captainc wrote on Fri, 21 November 2008 20:48

Yeah, I saw the date and was amazed that it would take till then. I thought they were not going to get features in because the release date was earlier. I don't know how I feel about that late date. I was excited to see C++ take its next step sooner.

In all, this just validates the need right now for a library like U++; Especially with its alternative approaches in the core libraries.

Though, some thought should be put in to how U++ will change when the new standard comes out.

Yes, this is not how the situation was presented to the public. After jocking for years "C++0x, where x will be decimal we hope, not hexadecimal", and with the added requirement of submiting the draft in 2008 so it can be acepted by 2009, you would think that since they are on schedule, we would have the draft in 2009. But no, after 2009 there are going two be two years to work out the bugs. So we will get the final standard pretty late.

And until we get compiler support much time will pass. Good news is that we will probably get to play around with some features sooner. By 2009 the quite limited list of C++0x features supported by GCC should have an addition or two. And by 2010, 2011 we should have some support for the uncorrected draft. Question is how portable is that going to be. I think MSC will not experiment the same way GCC does and will try to bring out a mostly complete C++0x compiler somewhere in the future, which personally I hope it doesn't. I sure love MSC, not because it is from MS or anything,just because it's good and fast (and IMO a whole lot better than GCC performance wise; it's not just like MSC is 5% faster or some small number like this), so a C++0x MSC compiler would be a good thing. But I would like them to not give attention to anything else except .NET. I'm hoping even for a Windows version which has a .NET with fewer limitations and without WinAPI. On the other hand, GCC is still great for a production tool (especially when you don't have comparison). If they provide a compiler with uniform initialization, auto, concepts and rvalues, I will be sure to use it, even if is not 100% stable, and I'm sure others will use it too.

But I personally consider C++ doomed. And the final stab that killed it is C++0x. Not that C++0x is not good. It is actually so good that I wish it would have been brought out as C++03. But it's not. And with all those new good features plus good features from previous standards, if you don't have compatibility problems with older software, I'm sure you will be able to use C++ for some time now. But with the rest of the more ugly features, C++ is extremely bloated. What is going to happen after C++0x? TR1? Sure. Add modules to C++ and I'll shut up and probably be able to use happily C++ until I retire if I so desire. Add transparent GC and prove to the world that the performance penalty is not worth getting excited over. Add a really rich MT library (C++0x's is not that rich, only standardized)? Great!!! All these great feature, what could go wrong. Well the bloat can go wrong. Even if you use only the new features, you are going to have to have working knowledge of all features and this is where the amount of bloat will show it's ugly face. And TR1 is as far as you can go. You can't really bring out a new standard later, because of the bloat. A new programmer will have to learn C++ for years without end, and if the programmer hopes to reach the level of knowledge of C++ veteran switch have gone through each iteration of the language, than a time investment equivalent to their's will be necessary. You will probably have problems with hiring a graduate to work on a C++ project which uses a lot of features. That is true Today. I know a lot of programmers, but few can handle C++ and even less desire to. On the other hand, if you use C++ as C with classes, only use references as const & parameters, anybody can handle C++ and bring a project from start to finish. And that is happening a lot around me.

As for how this will affect U++, it is very hard to tell. First let's consider how much will U++ evolve until then. Personally I think it will remain pretty much the same. I hope will have a moment where we clean it up a little, make it even more modular and remove deprecated stuff. I think we should embrace a 3 level/release approach for deprecation. In the current release we find something that must be deprecated, we move it to level one and we keep it there in next release. Once we have reached that release, we move it to level 2, and keep it there for the next release. Level 2 is not activated by default,so you have to add a flag. To give an example, we find deprecated stuff in 2008.1. While working on the between release versions, we mark it as level one. So in 2008.1 and in 2009.1 we still have the deprecated features and can only be removed by an explicit flag if a user desires. This gives two years for the feature: one of pre-releases, dev versions,and one real release. From the moment 2009.1 is out, level1 items move to level 2, which is not activated by default and new deprecated items move to level one. This leaves you in the situation that a dev after a release removes deprecated items, but that's what dev should do: they can break compatibility. And level two items can always be turned on by a simple flag. And with 2010.1, new items come to level 1, level 1 becomes 2, and level 2 becomes level 3. Level3items are removed.

There are alot of variations on this scheme if it seems to complicated.

Also new packages are sure to surface. Also, I except a larger user base. Not large compared with other toolkits, but large enough that we will have troubles resolving all the requests and support on this forum. The problem could be easily solved with a couple of additional Mireks Razz.
Previous Topic: Looking for someone to convert a ulimate++ project to Microsoft Visual C++ project
Next Topic: Fantastic work!!
Goto Forum:
  


Current Time: Thu Mar 28 22:40:22 CET 2024

Total time taken to generate the page: 0.02246 seconds