Clan x86
Technical (Development, Security, etc.) => General Programming => Topic started by: AntiVirus on October 16, 2006, 04:56:19 pm
-
Can someone please help me? I have been working on my programming assignment for my CS class and I have been running into a bunch of different problems. Some of which I have been able to over come (I hope), and others I haven't. One of these such problems is with the my_swap function that I created to help me sort an array. When I sent the array to the my_swap function, I get a few errors. At first, I have an infinite loop, but now I think I might have fixed that at the cost of getting two errors. With my little knowledge of C++ I haven't been able to figure out what they mean. So here they are:
hw6.cpp: In function `void my_swap(int*, int*)':
hw6.cpp:12: error: invalid conversion from `int*' to `int'
hw6.cpp:14: error: invalid conversion from `int' to `int*'
sortingalgs.cpp: In function `void bubbleSort(int*, int)':
sortingalgs.cpp:19: error: invalid conversion from `int' to `int*'
sortingalgs.cpp:19: error: invalid conversion from `int' to `int*'
sortingalgs.cpp: In function `void bobSort(int*, int)':
sortingalgs.cpp:42: error: invalid conversion from `int' to `int*'
sortingalgs.cpp:42: error: invalid conversion from `int' to `int*'
Now here's the code:
This is the file that contains the my_swap function:
#include "hw6.h"
void my_swap(int first[], int second[])
{
int temp = 0;
// cout<<"In hw6.cpp in the my_swap function";
temp = first;
first = second;
second = temp;
return;
}
The #include "hw6.h" is the header file where my prototype for the my_swap function is stored.
Now for the sortingalgs.cpp:
#include "sortingalgs.h"
#include "hw6.h"
void bubbleSort(int array[], const int SIZE)
{
// cout<<"In sortingalgs.cpp in the bubbleSort";
bool done = false, swapped = true;
do
{
swapped = false;
for(int index = 0; index <= SIZE - 1; index++)
{
if(array[index] > array[index + 1])
{
my_swap(array[index], array[index + 1], index); //swaps the values of the new indexes (Line 19)
swapped = true; //Everytime it swaps, this is true.
}
}
if(swapped == false) //Once swapping is over, this is true, and the for loop ends.
done = true; //ends do-while loop.
}while(done == false);
return;
}
void bobSort(int unsorted_sub[], const int SIZE)
{
cout<<"In sortingalgs.cpp in the bobSort";
int sorted_sub[] = {}; //declares an array with an undetermined size filled with 0's (wrong?)
for(int index = 0; index <= SIZE - 1; index++)
{
//Assigns the sorted array all of the unsorted array, so that it can be sorted
sorted_sub[index] = unsorted_sub[index];
for(int index2 = 0; index2 <= index; index2++)
{
//Allows for two of the same arrays to exist so that the sorted can be sorted
if(sorted_sub[index2] > sorted_sub[index])
my_swap(sorted_sub[index2], sorted_sub[index], index2); //line 42
}
}
return;
}
I don't know what I am doing wrong. :(
-
Your swap function is switching around addresses of the first node in an external array. Simply put, it's not doing anything for you! If you want to swap two values in an array, you want to pass to the function the addresses of the nodes that you want to swap because you don't care about some internal array that's left to rot after the function is done!
You want it to look something like this:
void swap_values(int &value1, int &value2) // These arguments give the functions the ADDRESSES of these variables
{
// Assign the value located at "the address of" value 1 to a temporary variable
int temp = *value1;
// Assign the value located at the address of value 1 to the value located at the address of value 2
*value1 = *value2;
// Assign the value of the temporary variable to the value located at the address of value 2
*value2 = temp;
}
Then, when you use this function, it should look something like this:
swap_values(&array_1[2], &array_2[2]);
I'm not entirely sure that that's the correct syntax. You may need to do something really tricky like (&array_1 + x), where x is the node you're trying to access.
-
The first[] and second[] signify that it's an array I am passing in, and acts like a reference, I believe.
-
try (int **value1, int **value2)
A pointer stores a memory address instead of an actual value.
int value = 2;
int *address = &value2;
*address = 3;
cout << value;
You'd get 3.
Here's some sample code:
sidoh@deepthought:~/public_html/src$ cat test.c; gcc test.c -o test; ./test
#include <stdio.h>
int main( int argc, char *argv[] ) {
int value = 2;
int *address = &value;
*address = 3;
printf("%d -> %d\n", address, value);
}
-1073744140 -> 3
-
sidoh@deepthought:~/public_html/src$ cat test.c; gcc test.c -o test; ./test
#include <stdio.h>
void swap();
int main( int argc, char *argv[] ) {
int array1[3] = {1, 2 ,3};
int array2[3] = {3, 2, 1};
printf("\n\n");
printf("Array 1, node 0 has a value of %d.\nArray 2, node 0 has a value of %d.", array1[0], array2[0]);
swap(&array1[0], &array2[0]);
printf("\n\n");
printf("Array 1, node 0 has a value of %d.\nArray 2, node 0 has a value of %d.", array1[0], array2[0]);
printf("\n\n");
return 0;
}
void swap(int **value1, int **value2)
{
int temp = (int)*value2;
*value2 = *value1;
*value1 = temp;
return;
}
test.c: In function `swap':
test.c:29: warning: assignment makes pointer from integer without a cast
Array 1, node 0 has a value of 1.
Array 2, node 0 has a value of 3.
Array 1, node 0 has a value of 3.
Array 2, node 0 has a value of 1.
-
What is **? Two pointers?
-
What is **? Two pointers?
Those confused the hell out of me when I had to use them. It's the address of a pointer variable, so basically, yeah.
-
Eh.....
Well you would think that since I haven't learned this stuff I wouldn't be required to use them in my assignment. So there has to be a way around this without using the pointer operator/function(?).
But I can't figure it out!!!!!!! :(
-
Then don't use a function! I was asking you why you were doing that in the first place yesterday with the other sort.
Just do something like:
int temp = 0;
while(...)
{
...
temp = array1[index];
array1[index] = array2[index];
array2[index] = temp;
...
}
-
[Edit]!!!
Actually, it just looked like an infinte loop, but instead it says Segmentation fault. Whatever that is.
-
That doesn't make any sense.
sidoh@deepthought:~/public_html/src$ cat test.c; gcc test.c -o test; ./test
#include <stdio.h>
void swap();
int main( int argc, char *argv[] ) {
int array1[3] = {1, 2 ,3};
int array2[3] = {3, 2, 1};
printf("\n\n");
printf("Array 1, node 0 has a value of %d.\nArray 2, node 0 has a value of %d.", array1[0], array2[0]);
//swap(&array1[0], &array2[0]);
int temp = array1[0];
array1[0] = array2[0];
array2[0] = temp;
printf("\n\n");
printf("Array 1, node 0 has a value of %d.\nArray 2, node 0 has a value of %d.", array1[0], array2[0]);
swap(&array1[0], &array2[0]);
printf("\n\n");
printf("Array 1, node 0 has a value of %d.\nArray 2, node 0 has a value of %d.", array1[0], array2[0]);
printf("\n\n");
return 0;
}
void swap(int **value1, int **value2)
{
int temp = (int)*value2;
*value2 = *value1;
*value1 = temp;
return;
}
test.c: In function `swap':
test.c:37: warning: assignment makes pointer from integer without a cast
Array 1, node 0 has a value of 1.
Array 2, node 0 has a value of 3.
Array 1, node 0 has a value of 3.
Array 2, node 0 has a value of 1.
Array 1, node 0 has a value of 1.
Array 2, node 0 has a value of 3.
PM me your code and I'll try to take a look at it.
-
Well I figured out what a Segmentation Fault is.
A segmentation fault occurs when your program tries to access memory locations that haven't been allocated for the program's use.
But I don't see where I am doing that?
And okay, I will PM you my code.
-
Well I figured out what a Segmentation Fault is.
A segmentation fault occurs when your program tries to access memory locations that haven't been allocated for the program's use.
But I don't see where I am doing that?
Hehe, yep. :)
-
Could it be because of the array[index] = array[index + 1]; ?
-
[Edit]!!!
Actually, it just looked like an infinte loop, but instead it says Segmentation fault. Whatever that is.
If you're infinitely looping you're bound to access some restricted memory sooner or later.
-
If you're infinitely looping you're bound to access some restricted memory sooner or later.
Not if you're continuously re-examining the same memory!
while(true);
I doubt the above presents much threat of accessing dangerous memory.
-
If you're infinitely looping you're bound to access some restricted memory sooner or later.
Not if you're continuously re-examining the same memory!
while(true);
I doubt the above presents much threat of accessing dangerous memory.
That's true but how often is it that you do an infinite loop withought having any code in the middle? You're going to currupt the stack sooner or later.
-
That's true but how often is it that you do an infinite loop withought having any code in the middle? You're going to currupt the stack sooner or later.
That's still a terrible generalization...
-
Yea I guess, I assumed he knew what I meant. :P
-
That's true but how often is it that you do an infinite loop withought having any code in the middle? You're going to currupt the stack sooner or later.
Take a look at all the programs in this folder (http://www.javaop.com/~ron/code/74.455/) -- they're programs for my microcontroller. Notice what they all have in common? They all take place in an infinite loop. And none of them corrupt the memory.
Generally, they're a finite-state-machine, waiting for events, but there's no way to sleep on that uC, since my code is the only code running (no library, no kernel, etc).
-
Cool.
-
That's true but how often is it that you do an infinite loop withought having any code in the middle? You're going to currupt the stack sooner or later.
while (true)
{
i++;
j++;
k++;
l++;
m++;
n++;
o++;
}
No stack corruption.
-
Ugh screw you guys :/
-
Ugh screw you guys :/
Because you're wrong? :P
-
http://en.wikipedia.org/wiki/Stack_overflow
"The most common cause of stack overflows is infinite recursion."
http://en.wikipedia.org/wiki/Infinite_recursion
-
http://en.wikipedia.org/wiki/Stack_overflow
"The most common cause of stack overflows is infinite recursion."
http://en.wikipedia.org/wiki/Infinite_recursion
Okay, first of all, stack overflows != stack corruption. Second of all, infinite looping != infinite recursion.
Infinite looping:
while (true) ;
Infinite recursion:
void doStuff(int a)
{
doStuff(++a);
}
Jackass.
-
http://en.wikipedia.org/wiki/Stack_overflow
"The most common cause of stack overflows is infinite recursion."
http://en.wikipedia.org/wiki/Infinite_recursion
Okay, first of all, stack overflows != stack corruption. Second of all, infinite looping != infinite recursion.
Infinite looping:
while (true) ;
Infinite recursion:
void doStuff(int a)
{
doStuff(++a);
}
Jackass.
Exactly!
-
Second of all, infinite looping != infinite recursion.
Infinite recursion, a special case of an infinite loop, is an infinite loop caused by recursion.
-
Second of all, infinite looping != infinite recursion.
Infinite recursion, a special case of an infinite loop, is an infinite loop caused by recursion.
And Rolle's Theorem is a special case of the Mean Value Theorem. That doesn't make them the same thing. Just because two things are related doesn't mean they're completely synonymous.
-
Second of all, infinite looping != infinite recursion.
Infinite recursion, a special case of an infinite loop, is an infinite loop caused by recursion.
And Rolle's Theorem is a special case of the Mean Value Theorem. That doesn't make them the same thing. Just because two things are related doesn't mean they're completely synonymous.
And? They're still related so I can call infinite recursion and infinite loop if I damn well feel like it and I will still be right.
Which makes me right.
-
And? They're still related so I can call infinite recursion and infinite loop if I damn well feel like it and I will still be right.
Which makes me right.
Warrior, you're pathetic sometimes. It doesn't matter how you want to justify your incorrectness. You're still wrong.
-
And? They're still related so I can call infinite recursion and infinite loop if I damn well feel like it and I will still be right.
Which makes me right.
Warrior, you're pathetic sometimes. It doesn't matter how you want to justify your incorrectness. You're still wrong.
I'm incorrect because you say I'm incorrect? You're not the one with the wikipedia articles proving you right however.
-
Do you remember what you're arguing about? Here's the original quote:
If you're infinitely looping you're bound to access some restricted memory sooner or later.
We've determined that it's quite likely that that's not going to happen. in fact, the only time it's going to happen is if you're processing an array, or something else uncommon. So you're wrong.
Even if infinite recursion could be called an infinite loop, you aren't accessing restricted memory, you're running out of stack space. So wrong again.
-
Do you remember what you're arguing about? Here's the original quote:
If you're infinitely looping you're bound to access some restricted memory sooner or later.
We've determined that it's quite likely that that's not going to happen. in fact, the only time it's going to happen is if you're processing an array, or something else uncommon. So you're wrong.
Even if infinite recursion could be called an infinite loop, you aren't accessing restricted memory, you're running out of stack space. So wrong again.
You're right on those counts, I was thinking of buffer overflows when I wrote that. Who cares, if he fixes his problem with his app then all the power to him, I'm not going to continue arguing over something so stupid.
I do however standby my point I made to on infinite recursions being a form of infinite loops.
Scoreboard:
-----------
iago: 2
warrior: 1
sidoh: -12
-
I'm incorrect because you say I'm incorrect? You're not the one with the wikipedia articles proving you right however.
You're hopeless, Warrior. Your inability to admit defeat is astounding.
I will make my analogy (that you seemed to completely look over, by the way) more understandable for you.
And Rolle's Theorem is a special case of the Mean Value Theorem. That doesn't make them the same thing. Just because two things are related doesn't mean they're completely synonymous.
Rolle's Theorem states: if (http://latex.sidoh.org/?render=f(x)) is continuous on a closed interval (http://latex.sidoh.org/?render=[a,b]) and differentinable on the open interval (http://latex.sidoh.org/?render=(a,b)) and (http://latex.sidoh.org/?render=f(a)=f(b)), then there is some number (http://latex.sidoh.org/?render=c) in the open interval (http://latex.sidoh.org/?render=(a,b)) such that (http://latex.sidoh.org/?render=f'(c)=0).
The Mean Value Theorem states: if (http://latex.sidoh.org/?render=f(x)) is continuous on a closed interval (http://latex.sidoh.org/?render=[a,b]) and differentiable on the open interval (http://latex.sidoh.org/?render=(a,b)) and then there exists some value (http://latex.sidoh.org/?render=x=c) such that (http://latex.sidoh.org/?render=\displaystyle f'(c)=\frac{f(b)-f(a)}{b-a})
As you should be able to see, Rolle's theorem is merely a special case of the MVT. Does that make them equivilant? Identical? No, not at all. Just because something is a special case of some other thing does not make them the same thing. When someone tells you to solve a problem through recursion, you solve it through recursion, not looping. They're two separate things, even though they represent comparable concepts.
It doesn't matter if recursions are a form of infinite loops (which, by the way, none of us have denied. You haven't made a point. You've simply pointed out something that all of us already know). As I surely hope you know, a loop in programming has a far less abstract meaning than you're allowing it to have. When someone tells you to write a loop, you better be typing the word "for" or "while."
-
Blah Blah
Let's go over this:
Loop - Executing the same code over and over again
Infinite - Going on forever
Infinite Loop = Executing the same code over and over again forever.
Recursion - Executing the same code over and over again
Recursion = Loop
Infinite Recursion = Executing the same code over and over again forever.
Infinite Loop = Infinite Recursion
-
Blah Blah
Let's go over this:
Loop - Executing the same code over and over again
Infinite - Going on forever
Infinite Loop = Executing the same code over and over again forever.
Recursion - Executing the same code over and over again
Recursion = Loop
Infinite Recursion = Executing the same code over and over again forever.
Infinite Loop = Infinite Recursion
Why are you so hard headed? You can't win an argument if you don't even understand the other side of the argument, which you clearly don't. This isn't a rap battle, Warrior. Your usual argumentative tactics aren't going to work. :P
As I surely hope you know, a loop in programming has a far less abstract meaning than you're allowing it to have. When someone tells you to write a loop, you better be typing the word "for" or "while."
Your "proof" abstracts the meaning of recursion and looping, which is exactly what I told you why you're wrong. :P
-
I know, I'm being an asshole because it's fun.
-
I know, I'm being an asshole because it's fun.
I don't buy it. :P
-
Warrior's tactic in this argument (and others) is to change the definition of the problem until it matches what he's arguing.
This argument wasn't about whether or not infinite recursion is an infinite loop, it's about whether or not an infinite loop corrupts the stack.
So you lose, gg.
-
Blah Blah
LMFAO!! That's funny.
-
Warrior's tactic in this argument (and others) is to change the definition of the problem until it matches what he's arguing.
This argument wasn't about whether or not infinite recursion is an infinite loop, it's about whether or not an infinite loop corrupts the stack.
So you lose, gg.
What are you talking about..it does. Since we established that Infinite Loops = Infinite Recursion and infinite recursion do corrupt the stack.
I win.
-
Blah Blah
LMFAO!! That's funny.
It's funny because he's an idiot.
Warrior's tactic in this argument (and others) is to change the definition of the problem until it matches what he's arguing.
This argument wasn't about whether or not infinite recursion is an infinite loop, it's about whether or not an infinite loop corrupts the stack.
So you lose, gg.
What are you talking about..it does. Since we established that Infinite Loops = Infinite Recursion and infinite recursion do corrupt the stack.
I win.
No, you completely ignored everything we said so you could establish with yourself that you won. You're an idiot.
-
Blah Blah
LMFAO!! That's funny.
It's funny because he's an idiot.
Warrior's tactic in this argument (and others) is to change the definition of the problem until it matches what he's arguing.
This argument wasn't about whether or not infinite recursion is an infinite loop, it's about whether or not an infinite loop corrupts the stack.
So you lose, gg.
What are you talking about..it does. Since we established that Infinite Loops = Infinite Recursion and infinite recursion do corrupt the stack.
I win.
No, you completely ignored everything we said so you could establish with yourself that you won. You're an idiot.
Funny you get mad over something on the internet, oh well. There is just no way I'm wrong, my proof is in the word itself. I'm fully aware when you say loop isn't just limited to recursion but the point is that, it includes recursion.
Ugh why am I even continuing this with you, I don't care. If you want to defy a definition to prove that you win then so be it, I'll just get on with my life.
You obsess too much over these things imho.
-
Funny you get mad over something on the internet, oh well. There is just no way I'm wrong, my proof is in the word itself. I'm fully aware when you say loop isn't just limited to recursion but the point is that, it includes recursion.
Ugh why am I even continuing this with you, I don't care. If you want to defy a definition to prove that you win then so be it, I'll just get on with my life.
You obsess too much over these things imho.
It doesn't matter where I encounter them, idiots always piss me off.
I'm not defying the definition. Like I said, you're abstracting the definition of a loop and using the abstracted definition to relate it to recursion. I'm not saying that recursion isn't looping; however, it isn't a loop when you use the definition of the word "loop" in the context of a programming language.
In any case, you're still wrong. :P
-
Funny you get mad over something on the internet, oh well. There is just no way I'm wrong, my proof is in the word itself. I'm fully aware when you say loop isn't just limited to recursion but the point is that, it includes recursion.
Ugh why am I even continuing this with you, I don't care. If you want to defy a definition to prove that you win then so be it, I'll just get on with my life.
You obsess too much over these things imho.
It doesn't matter where I encounter them, idiots always piss me off.
I'm not defying the definition. Like I said, you're abstracting the definition of a loop and using the abstracted definition to relate it to recursion. I'm not saying that recursion isn't looping; however, it isn't a loop when you use the definition of the word "loop" in the context of a programming language.
What the hell are you talking about? A loop is simply reusing the same code over and over... I'm not abstracting the definition that is exactly what infinite recursion is, an infinite loop.
Just out of curiosity, what do you definite infinite recursion as?
-
What the hell are you talking about? A loop is simply reusing the same code over and over... I'm not abstracting the definition that is exactly what infinite recursion is, an infinite loop.
Yes, that is the abstracted definition of a loop in programming. The applied meaning of a loop is (as MyndFyre already explained quite plainly):
while(condition) { statement; }for(initializer; condition; update) { statement; }
That is a programming loop.
Just out of curiosity, what do you definite infinite recursion as?
function statement(a) { statement(a++); }
-
What the hell are you talking about? A loop is simply reusing the same code over and over... I'm not abstracting the definition that is exactly what infinite recursion is, an infinite loop.
Yes, that is the abstracted definition of a loop in programming. The applied meaning of a loop is (as MyndFyre already explained quite plainly):
while(condition) { statement; }for(initializer; condition; update) { statement; }
That is a programming loop.
Just out of curiosity, what do you definite infinite recursion as?
function statement(a) { statement(a++); }
Those are two different types of loops, you're just limiting what the term loop applies to as it fits your needs.
The bottom line is that infinite recursions are infinite loops are infinite loops are infinite loops.
No way around it, no way to argue against it.
-
Those are two different types of loops, you're just limiting what the term loop applies to as it fits your needs.
The bottom line is that infinite recursions are infinite loops are infinite loops are infinite loops.
No way around it, no way to argue against it.
First, I think you need to understand the definition of abstract:
abstract: 1 a : disassociated from any specific instance <an abstract entity>
Next, I'll quote some definitions of recursion, most of which are from your own source.
Recursion in computer programming is exemplified when a function is defined in terms of itself. One example application of recursion is in parsers for programming languages. The great advantage of recursion is that an infinite set of possible sentences, designs or other data can be defined, parsed or produced by a finite computer program.
Recursion is the definition of an operation in terms of itself.
Recursion programming technique in which a program or routine calls itself to perform successive steps in an operation, with each step using the output of the preceding step.
Nowadays, only the most performance-hungry software, such as video games, missile guidance systems and graphics card drivers, should worry about whether recursion will be slower than iterative for or while loops.
Notice that they refer to recursion and the types of programming loops as separate entities in the last quote.
Do you recognize the difference yet?
-
ok your point? Recursion = Looping. Infinite recursion = Infinite looping.
Still, I win.
-
Recursion = Looping.
That's where you're wrong. Looping is not recursion. Did you even read those definitions? You're a programmer, right?
Are you making an effort to ignore everything that's thrown at you or does that come naturally?
-
Ok, let's pretend that you can make an infinite loop without a loop. Just for a minute.
Now, if you infinitely recurse, you run out of stack space (you get to the top.. or the bottom, depending on how you look at it). Then your program crashes, since it can't write anything else to the stack.
So where's this corruption you're talking about?
-
Ok, let's pretend that you can make an infinite loop without a loop. Just for a minute.
Now, if you infinitely recurse, you run out of stack space (you get to the top.. or the bottom, depending on how you look at it). Then your program crashes, since it can't write anything else to the stack.
So where's this corruption you're talking about?
It is obviously corrupted if it's crashed right? I mean..the program wouldn't crash if it wasn't corrupted.
-
Ok, let's pretend that you can make an infinite loop without a loop. Just for a minute.
Now, if you infinitely recurse, you run out of stack space (you get to the top.. or the bottom, depending on how you look at it). Then your program crashes, since it can't write anything else to the stack.
So where's this corruption you're talking about?
It is obviously corrupted if it's crashed right? I mean..the program wouldn't crash if it wasn't corrupted.
No. As I said, it crashes because it's out of stack space, not because it's corrupted.
-
Warrior, I can't believe nobody has pointed this out. Recursion is in fact a looping construction. However, loops are not always recursive.
It's like this:
Set(Programming constructs) = { Loops, Assignments, Expressions, Functions }
Set(Loops) = (Recursive loops, While loops, For loops, Do loops }
Or, if you want to think of it this way:
class Loop : ProgrammingIdea
{
...
}
Class Recursion : Loop
{
...
}
You can implicitly cast a Recursion object to a Loop object. However, you cannot safely cast a Loop object to a Recursion object.
-
Second of all, infinite looping != infinite recursion.
Infinite recursion, a special case of an infinite loop, is an infinite loop caused by recursion.
My God, Warrior... Even I know that simply increasing an integer has absolutely nothing to do with the stack! Pushing it, calling a function, and popping it, however, does!
-
Second of all, infinite looping != infinite recursion.
Infinite recursion, a special case of an infinite loop, is an infinite loop caused by recursion.
My God, Warrior... Even I know that simply increasing an integer has absolutely nothing to do with the stack! Pushing it, calling a function, and popping it, however, does!
Joe:
I just saw this today. You have no idea what you're talking about, read it the entire thread tool.
Bottom line: I program better than you.
@Myndfyre: Yea, you're right. I admit defeat.