|
|
Home » Community » Coffee corner » Pick overloaded by Rvalue?
Pick overloaded by Rvalue? [message #19088] |
Tue, 11 November 2008 23:44  |
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 .
cdabbd745f1234c2751ee1f932d1dd75
|
|
|
|
|
Re: Pick overloaded by Rvalue? [message #19092 is a reply to message #19091] |
Wed, 12 November 2008 10:48   |
bytefield
Messages: 210 Registered: December 2007
|
Experienced Member |
|
|
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 #19095 is a reply to message #19093] |
Wed, 12 November 2008 12:20   |
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" Now i think i know why Linus Torvalds doesn't like C++
It's just me or seems that C++ language is going down?
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   |
mdelfede
Messages: 1308 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 #19102 is a reply to message #19100] |
Wed, 12 November 2008 20:33   |
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?
| 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...
|
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? 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   |
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   |
 |
mirek
Messages: 14255 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   |
 |
mirek
Messages: 14255 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? 
- dynamic library APIs are difficult to maintain if you wish to use the real power of language
Mirek
|
|
|
|
Re: Pick overloaded by Rvalue? [message #19114 is a reply to message #19113] |
Thu, 13 November 2008 00:20   |
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   |
 |
mirek
Messages: 14255 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? 
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   |
 |
mirek
Messages: 14255 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 #19233 is a reply to message #19227] |
Sat, 22 November 2008 10:04   |
cbpporter
Messages: 1427 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 .
|
|
|
Goto Forum:
Current Time: Sun Apr 27 01:34:19 CEST 2025
Total time taken to generate the page: 0.01266 seconds
|
|
|