Thought about programming
-
But using a Tuple object, we're still returning only 1 value... an object. The idea of the tuple as presented in Nice is that you're physically returning 2, 3, or n number of values. You're not wrapping them in an object to fake it, you're physically passing back an int, and then a float, or whatever. Jamie Nordmeyer Portland, Oregon, USA
Whats the difference? The only difference is syntax... -- This space for rent.
-
std::vector :omg::rolleyes::laugh: Tim Smith I'm going to patent thought. I have yet to see any prior art.
You're a very evil man Tim. -- This space for rent.
-
value.second.second.second.second.second.second means...? I'm getting flashbacks from Gödel Escher Bach, an Eternal Golden Braid. :~ -- This space for rent.
-
Yup, sounds good. Only would need it once in a blue moon. I would rather have the compiler vendors spending time working on a better compiler than the standards group sitting around trying to justify their existence. IMHO, C/C++ has really come to the end of their extensible lifetime. It really needs to be rebuilt from the ground up and not have new features just hacked onto it. Tim Smith I'm going to patent thought. I have yet to see any prior art.
Tim Smith wrote: It really needs to be rebuilt from the ground up and not have new features just hacked onto it. How do you mean? Think about all those billion lines of legacy code! I'd be pissed if Bjarne went nuts on C++ rendering my code useless. I've already been through this with java 1.0 -> 1.1 - no more please! I can't take it... -- This space for rent.
-
I think it'd be something like:
int a, b;
(a, b) = FooBar();
Or maybe a special symbol other than parenthesis, perhaps brackets. Jamie Nordmeyer Portland, Oregon, USA
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.
-
People will start doing something like "(int, (int, int)) FooBar, and end up as LISP programmers with the wrong compiler.
If I could find a souvenir / just to prove the world was here [sighist]
That would work for me. But then I'd have to switch to Emacs again. :) -- This space for rent.
-
Whats the difference? The only difference is syntax... -- This space for rent.
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
-
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.
From the samples I saw, yeah. I didn't actually download and try the language, I just read some of the theory on it. I replyed to an earlier post of yours, and I'm thinking that it would just be a couple of pushes and pops from the stack. A regular, single return value function pushes its return value right before returning to the caller, so I'd think you should be able to simply push the extra return values as well, then pop them off in the callee. Jamie Nordmeyer Portland, Oregon, USA
-
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