Thought about programming
-
ah.. the VARIANT. the deepest chasm in the Valley of Dangerous Practices. i fear the VARIANT and all its evil offspring. nothing but pain and suffering down that road.
There's one easy way to prove the effectiveness of 'letting the market decide' when it comes to environmental protection. It's spelt 'S-U-V'. --Holgate, from Plastic
I haven't thought about Variants since I started using .NET. Now, to have them return to my memory... AAAAARRRRGGGHHH!!!! :omg::omg::omg::wtf::wtf::wtf: :-D Jamie Nordmeyer Portland, Oregon, USA
-
This looks nice but how do i call this function ?
(int, int) a=FooBar(); //?? int b=a??+a??; :confused:i'm only pointer to myselfI 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
-
pair will get you 2. how do you do 3, 10 or 50? -c
There's one easy way to prove the effectiveness of 'letting the market decide' when it comes to environmental protection. It's spelt 'S-U-V'. --Holgate, from Plastic
-
Eh, what's wrong with:
struct blah_t { int i; int j; };
blah_t FooBar()
{
blah_t ret = {5,10};
return ret;
}or for that matter,
void FooBar(int& i, int &j)
{
i = 5; j = 10;
}Granted, Nice sounds concise, but it seems unnecessary given how often such a thing is necessary.
---
Shog9 Life seems pretty easy when it's from my easy chair And you're burnin up inside and no one cares...
Option one makes you perform a copy of the data, which is always expensive. The compiler may be capable of optimizing the copy away though -any thoughts? Christian Skovdal Andersen Don't mention the war...
-
Eh, what's wrong with:
struct blah_t { int i; int j; };
blah_t FooBar()
{
blah_t ret = {5,10};
return ret;
}or for that matter,
void FooBar(int& i, int &j)
{
i = 5; j = 10;
}Granted, Nice sounds concise, but it seems unnecessary given how often such a thing is necessary.
---
Shog9 Life seems pretty easy when it's from my easy chair And you're burnin up inside and no one cares...
Shog9 wrote: Granted, Nice sounds concise, but it seems unnecessary given how often such a thing is necessary. It happens enough to be annoying. I usually use std::pair or one of my handcrafter stdex::triplet, std::quadruplet, etc. Maybe I should start using boost for this too. :) -- This space for rent.
-
Jamie Nordmeyer wrote: My question is what do you think about this in a language. I think it's a darn useful feature. Some might think "How often would I use it?" But if it was added to C++ I'm sure I'd find more and more uses for it. The best way to find out how useful something is, isn't to add it, but to remove it. :-) Maybe, I should use the Boost version. :-) 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.
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.
-
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