struct A
{
double x, y;
(double, double) getPosition() const
{
return (x, y);
}
};
double getLength(double x, double y)
{
return std::sqrt(x*x+y*y);
}
int main()
{
A a;
a.x = 5;
a.y = 6;
double distance = GetLength(a.getPosition());
double posx, posy;
(posx, posy) = a.getPosition();
}
C++ idea: tuples in core language
Author
I've been having this C++ idea for a while, what do you think about it?
AFAIK there's no technical complications in it, the compiler can directly map intermediate results to the correct variables.
It's about tuples, allowing functions to return multiple variables and giving them to functions taking multiple variables at the input.
The notation is simple: (variable, variable, ....)
Examples:
You could of course make a simple struct instead of the tuple, but the advantage of the tuples is that it's an easier notation not requiring to define structs.
Quote:Original post by loufoque
How is that better than tuple<double, double> ?
getLength(a.getPosition());OP: the amount of things that should have been in C++ is massive. I just moved over to friendlier languages.
What's wrong with std::pair? If you need an n-tuple, you'd use an array. Personally, I use a triple<> template; beyond that, I don't see the need.
This is problematic for at least one reason I can think of. This code:
Already has a meaning (albeit a stupid one). It evaluates everything in the parenthesis list and then uses the last item. So the above code will assign the return value from a.getPosition into posy. The standards committee would never change this behavior.
Also, as the other posters pointed out, you can define tuple types yourself extremely easily, so I see it as a slight inconvenience that C++ lacks them but nothing more.
double posx, posy;(posx, posy) = a.getPosition();Already has a meaning (albeit a stupid one). It evaluates everything in the parenthesis list and then uses the last item. So the above code will assign the return value from a.getPosition into posy. The standards committee would never change this behavior.
Also, as the other posters pointed out, you can define tuple types yourself extremely easily, so I see it as a slight inconvenience that C++ lacks them but nothing more.
Author
Quote:Original post by Simian Man
Also, as the other posters pointed out, you can define tuple types yourself extremely easily, so I see it as a slight inconvenience that C++ lacks them but nothing more.
It's not entirely the same because then you also need to put tuple in the type of the function parameter taking it, and are forced to type the verbose template tuple typename instead of just having the option to.
Syntactic sugar is always nice, but I hardly see the need to specify std::pair in this case as a significant problem. Concepts such as positions, colours and whatnot are typically stored in pairs, triples or matrices anyway. Typedef it if you consider it too verbose.
To be honest I prefer structs. Named members help a lot with readability. Not a fan at all of std::pair and using it for keyed containers was a mistake in my opinion. The only advantage of tuples would be the ability to iterate over members but even that should probably be solved via reflection.
Quote:Original post by LodeQuote:Original post by Simian Man
Also, as the other posters pointed out, you can define tuple types yourself extremely easily, so I see it as a slight inconvenience that C++ lacks them but nothing more.
It's not entirely the same because then you also need to put tuple in the type of the function parameter taking it, and are forced to type the verbose template tuple typename instead of just having the option to.
The Lua solution WoW API offers is "much more readable". it looks something like this:
// not real APIbuyer,owner,id,minprice,ilevel,timeremaining,pricelevel = queryAuctionHouse(0,10,29,0,0,4,"");Now... isn't this much more readable, than the complex C++ syntax:
SearchQuery query(0,10,29); // rest are default parametersAuctionSearchResult result(queryAuctionHouse(query));AuctionSearchResult result(query);As with everything, there's benefits and disadvantages to each approach.
(Lua note): If return value signature changes in the above example - you get no warning. Script continues to work, even if types change. And then there's the most evil change of all, reordering of the returned elements.
(C++ proposal note):, if your return value changes, you need to fix all the places where your function gets called! In Lua, you will not know something is wrong until you get run-time error.
Compare this to fully type-safe and encapsulated structure in C++.
Quote:Original post by Lode
I've been having this C++ idea for a while, what do you think about it?
I think std::tr1::tuple or std::tuple from C++09 is what you're going to get. Why require a change to the compiler for Pythonesque syntactic sugar when it can be implemented in the library by contemporary compilers today, no muss no fuss no hidden subtle parsing problems?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
