Thought about programming
-
The tuple itself is a type, so it must be expressible as one as well. I'm not sure about Nice, but i know from programming language theory that tuples are generally thought of as types (composed types - much like a struct).
(int, int) a = FooBar();
printf("a = (%d, %d)\n", a.1, a.2); // Assuming tuples are orderedis one possible syntax. Is your example from above how you do it in Nice? -- This space for rent.
The only problem with using a struct is that 1. you need to make a struct and give it a name. 2. you may want to do this: (a.member, b.member) = fn(); but how do we pass one of the returned parameters into another fn, without using a local variable? My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
-
No, the difference is that you have the over head of creating the STL objects. Yes, STL is a fairly tight library, but an STL pair is still an object. Let's say you wanted to return two 'int's. Using an STL pair, the program must first instatiate the pair object, then set it's data members with the two integers, then finally pass the object back. Using a true tuple, the program would just pass the data back in the same way that data gets passed in: each value is pushed on to the stack, then poped off by the callee of the function. There's no over head in creating an object, no extra memory allocation. Just a couple of push and pop instructions. Jamie Nordmeyer Portland, Oregon, USA
*bzzz* you're wrong I'm afraid. Passing a simple struct containing two ints, without a specialized copy constructor, doesn't yield more CPU utilization than passing two "regular ints".
void func() {
int x, y;
...
return (x, y);
}adds 2 * sizeof(int) to the stack.
void func() {
std::pair<int, int> p;
...
return p;
}also adds sizeof(std::pair<int, int>) == 2 * sizeof(int); In both cases you also transfer 2 int's over the stack. There is no difference. I can bet money on that if someone went ahead and implemented tuples like in C++, it would mimic the behaviour of std::pair and boost::tuple. I can admit as far as the compiler may be able to do some optimizations if the tuples were in the language - but the yield would be limited. -- This space for rent.
-
*bzzz* you're wrong I'm afraid. Passing a simple struct containing two ints, without a specialized copy constructor, doesn't yield more CPU utilization than passing two "regular ints".
void func() {
int x, y;
...
return (x, y);
}adds 2 * sizeof(int) to the stack.
void func() {
std::pair<int, int> p;
...
return p;
}also adds sizeof(std::pair<int, int>) == 2 * sizeof(int); In both cases you also transfer 2 int's over the stack. There is no difference. I can bet money on that if someone went ahead and implemented tuples like in C++, it would mimic the behaviour of std::pair and boost::tuple. I can admit as far as the compiler may be able to do some optimizations if the tuples were in the language - but the yield would be limited. -- This space for rent.
Hmm. I always figured there'd be overhead to using the STL classes. I will have to read. Thanks for the insight Jorgen. :) Well, either way, the mention of Tuples made everyone think! ;) Jamie Nordmeyer Portland, Oregon, USA
-
The only problem with using a struct is that 1. you need to make a struct and give it a name. 2. you may want to do this: (a.member, b.member) = fn(); but how do we pass one of the returned parameters into another fn, without using a local variable? My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
Thomas George wrote: you need to make a struct and give it a name. If the tuples are a part of the language, then giving it a name would not be necessary I think. Arrays are supported by the C/C++ languages, and there are ways to express arrays "type anonymously": { "a", "string", "array" }. Thomas George wrote: 2. you may want to do this: (a.member, b.member) = fn(); Yes, that would be very interesting indeed. Or why not:
(x, y) = (fn(), fn2());
Thomas George wrote: but how do we pass one of the returned parameters into another fn, without using a local variable? I guess the language must implement some form of selector operator like the "."-operator in C/C++. That's why I proposed ".1" for first value, ".2" for second value, etc.. Tuples are basically just structs without member names. :) Don't get me wrong. Native support for tuples would be interesting and I guess it could give rise to creative and alternative coding styles. All I'm saying is that you can simulate tuples in many ways depending on how picky you are about the syntax. -- This space for rent.
-
Hmm. I always figured there'd be overhead to using the STL classes. I will have to read. Thanks for the insight Jorgen. :) Well, either way, the mention of Tuples made everyone think! ;) Jamie Nordmeyer Portland, Oregon, USA
Jamie Nordmeyer wrote: Hmm. I always figured there'd be overhead to using the STL classes. Of course, no library is perfect. But the small things in STL are in fact really efficient. Jamie Nordmeyer wrote: Thanks for the insight Jorgen Hey, you're welcome! Jamie Nordmeyer wrote: Well, either way, the mention of Tuples made everyone think! I couldn't agree with you more! I for one would love native support for tuples in C++. For one thing, the syntax would be much nicer. All I argued was that you can simulate tuples quite well in C++. If you want some really fun reading, please take a look at type lists in the boost library (www.boost.org[^]). Template meta-programming can actually yield far more superior code in terms of efficiency than "standard C++ techniques". Mainly because you let the compiler do much of the work at compile time. :) -- This space for rent.
-
Thomas George wrote: you need to make a struct and give it a name. If the tuples are a part of the language, then giving it a name would not be necessary I think. Arrays are supported by the C/C++ languages, and there are ways to express arrays "type anonymously": { "a", "string", "array" }. Thomas George wrote: 2. you may want to do this: (a.member, b.member) = fn(); Yes, that would be very interesting indeed. Or why not:
(x, y) = (fn(), fn2());
Thomas George wrote: but how do we pass one of the returned parameters into another fn, without using a local variable? I guess the language must implement some form of selector operator like the "."-operator in C/C++. That's why I proposed ".1" for first value, ".2" for second value, etc.. Tuples are basically just structs without member names. :) Don't get me wrong. Native support for tuples would be interesting and I guess it could give rise to creative and alternative coding styles. All I'm saying is that you can simulate tuples in many ways depending on how picky you are about the syntax. -- This space for rent.
i like the basic semantics. I was trying to figure out the more complex situations. ---------- My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
-
Colin Davies wrote: The best way to find out how useful something is, isn't to add it, but to remove it. So true! You are the wise man of CodeProject Colin, you have realized that by now, haven't you? <less-serious>If we could find two more wise men and a pregnant virgin, we could setup a CodeProject christmas theatre show.</less-serious> :) -- This space for rent.
Thank you Jorgen, And you must be wise also, to be able to note my own wiseness, :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
Thank you Jorgen, And you must be wise also, to be able to note my own wiseness, :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
Ok, we're two wise men. Now, where's the rest..? :-D -- This space for rent.
-
This is not a question about how to do something, per say, but is a question of opinion. Still, if anyone feels this post is ill placed, let me know, and I'll move it. :) I noticed a language on SourceForget the other day called Nice, that had an interesting feature called Tuples. Essentially, it allowed you to do this:
(int, int) FooBar()
{
return 5, 10;
}My question is what do you think about this in a language. Most of our languages have thus far only supported a single return value, where as Nice allows an arbitrary number of values to be returned. Thoughts? Jamie Nordmeyer Portland, Oregon, USA
old hat guvnor - Fortran programmers were doing this years ago
Stupidity dies. The end of future offspring. Evolution wins. - A Darwin Awards Haiku
-
Ok, we're two wise men. Now, where's the rest..? :-D -- This space for rent.
I'm wise :-D Elaine (sage fluffy tigress) Would you like to meet my teddy bear ?
-
I'm wise :-D Elaine (sage fluffy tigress) Would you like to meet my teddy bear ?
Well. Hmm.. a christmas play would require 3 wise men (don't blame me, I didn't write the book!). Are you perhaps a pregnant virgin? Then you could play Mary. :-D -- This space for rent.
-
This is not a question about how to do something, per say, but is a question of opinion. Still, if anyone feels this post is ill placed, let me know, and I'll move it. :) I noticed a language on SourceForget the other day called Nice, that had an interesting feature called Tuples. Essentially, it allowed you to do this:
(int, int) FooBar()
{
return 5, 10;
}My question is what do you think about this in a language. Most of our languages have thus far only supported a single return value, where as Nice allows an arbitrary number of values to be returned. Thoughts? Jamie Nordmeyer Portland, Oregon, USA
I've thought about that, too. It's a little hard to use in certain cases, though -- for example if you want to pass a value directly to another function. I mainly wish for it when I have multiple ins and outs from a function (and some variables are in+out). Sometimes I can't tell which variables are which -- hence the "tuple" thing, because return values are always out. In general, I compensate for this by using pointers (not references) for all out variables (of course, I can't tell if a variable is in+out or just out). The end result looks like this: int a,b; FooBar( &a, &b ); See the "address of" operator? That tells me that it's an out variable. If you use references you simply can't tell. Are "a" and/or "b" input, output, or both? FooBar( a,b ); I've also considered the possibility of a different argument syntax. For example, forcing programmers to break arguments into separate input and output sections (where a,b are "in" and c,d are "out" variables): int a, b, c, d; MyFunc( a,b )( c,d ); That syntax doesn't address in+out variables. Some other variation might be useful for that (because I hesitate to add even more parenthesis). (e is in+out) MyFunc( a,b; e; c,d ); Kinda looks like a "for" statement, doesn't it? ------------------------------------------ "Isn't it funny how people say they'll never grow up to be their parents, then one day they look in the mirror and they're moving aircraft carriers into the Gulf region?" - The Onion
-
I've thought about that, too. It's a little hard to use in certain cases, though -- for example if you want to pass a value directly to another function. I mainly wish for it when I have multiple ins and outs from a function (and some variables are in+out). Sometimes I can't tell which variables are which -- hence the "tuple" thing, because return values are always out. In general, I compensate for this by using pointers (not references) for all out variables (of course, I can't tell if a variable is in+out or just out). The end result looks like this: int a,b; FooBar( &a, &b ); See the "address of" operator? That tells me that it's an out variable. If you use references you simply can't tell. Are "a" and/or "b" input, output, or both? FooBar( a,b ); I've also considered the possibility of a different argument syntax. For example, forcing programmers to break arguments into separate input and output sections (where a,b are "in" and c,d are "out" variables): int a, b, c, d; MyFunc( a,b )( c,d ); That syntax doesn't address in+out variables. Some other variation might be useful for that (because I hesitate to add even more parenthesis). (e is in+out) MyFunc( a,b; e; c,d ); Kinda looks like a "for" statement, doesn't it? ------------------------------------------ "Isn't it funny how people say they'll never grow up to be their parents, then one day they look in the mirror and they're moving aircraft carriers into the Gulf region?" - The Onion
How about this:
(int, int)MyFunc(int x, int y)
{
if (x < y)
return x, y;
else
return y, x;
}int main()
{
int x, y;(x, y)=MyFunc(6, 10);
.
.
.
}Or maybe
MyFunc(int x, int y) returns (int, int)
{
if (x < y)
return x, y;
else
return y, x;
}int main()
{
int x, y;(x, y)=MyFunc(6, 10);
.
.
.
}Jamie Nordmeyer Portland, Oregon, USA