|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
Russian Federation4235 Posts
On April 20 2017 08:30 travis wrote:
**p;
*k;
statement 1: p = &k;
statement 2: *p = k;
both of these statements are the same?
lets assume there's no aliasing here, say:
T* k = 0x01, &k == 0x10 (k as a variable holds the value of 0x01 which is an address of some object of type T, it's own address is 0x10)
T* m = 0x02, &m == 0x20 (same for m)
T** p = &m;
then, initially:
p == 0x20
1) p = &k which translates to p = 0x10 which leads to: p == 0x10, m == 0x02
2) *p = k which translates to m = 0x01 which leads to: p == 0x20, m == 0x01
EDIT: made a little mistake on the first try  but basically those are quite different
|
ah ok yeah i get it, thanks
pointers are *still* rough haha
|
One of the reasons why I work with highly abstract languages in the first place (Ruby). I just write a bunch of pseudo code and it "just works". I don't have to worry about so much bullshit which leaves me plenty of time to figure out what and how my code should do things instead of fighting a constant battle just to make it work.
I don't know. I enjoy me some C now and then, but working with it full-time would be too nerve-wracking for me.
|
On April 20 2017 06:55 BluzMan wrote:Show nested quote +On April 20 2017 06:47 travis wrote:
but j is not null at that point, j is still a pointer to the section of memory that was freed.
p points to null, j contains the address it was assigned when we did j = p
also the above example is bad too. you don't want to free a bunch of memory that was never allocated you'll get seg faults or worse
maybe you guys are referencing behavior of free in c++ ? The first thing that comes to mind without allocating memory would be casting the input to an array of ints, sorting it and just using continue if a[i] == a[i - 1]. Double free is a dangerous error and should be avoided at all costs. Furthermore, you can't tell if a pointer has been freed just by looking at it, otherwise, C programming would have been really easy. Freeing a nullptr is generally safe, but you have to set it to nullptr first.
Don't cast a pointer to int, it is not portable and unsafe. Just leave it as a pointer.
|
On April 20 2017 08:03 Manit0u wrote:Show nested quote +On April 20 2017 07:25 travis wrote:On April 20 2017 06:55 BluzMan wrote:On April 20 2017 06:47 travis wrote:
but j is not null at that point, j is still a pointer to the section of memory that was freed.
p points to null, j contains the address it was assigned when we did j = p
also the above example is bad too. you don't want to free a bunch of memory that was never allocated you'll get seg faults or worse
maybe you guys are referencing behavior of free in c++ ? The first thing that comes to mind without allocating memory would be casting the input to an array of ints, sorting it and just using continue if a[i] == a[i - 1]. Double free is a dangerous error and should be avoided at all costs. Furthermore, you can't tell if a pointer has been freed just by looking at it, otherwise, C programming would have been really easy. Freeing a nullptr is generally safe, but you have to set it to nullptr first. well that's a way cooler solution than the given solution, I guess technically yours is faster than the given solution too This is indeed nice...
#include <stdio.h>
#include <stdlib.h>
int compare(const void *a, const void *b);
int main(void) {
int i = 0;
int len = 2;
int **ary = malloc(sizeof(int) * len);
int *p = malloc(sizeof(int));;
int *j = p;
ary[0] = p;
ary[1] = j;
qsort(ary, len, sizeof(int), compare);
for (i; i < len; i++) {
if (i > 0 && ary[i] != ary[i - 1]) {
free(ary[i]);
}
}
free(ary);
printf("We are free!\n");
return 0;
}
int compare(const void *a, const void *b) {
return (*(int*)a - *(int*)b);
}
This doesn't free ary[0]
|
On April 20 2017 10:45 Hanh wrote:Show nested quote +On April 20 2017 08:03 Manit0u wrote:On April 20 2017 07:25 travis wrote:On April 20 2017 06:55 BluzMan wrote:On April 20 2017 06:47 travis wrote:
but j is not null at that point, j is still a pointer to the section of memory that was freed.
p points to null, j contains the address it was assigned when we did j = p
also the above example is bad too. you don't want to free a bunch of memory that was never allocated you'll get seg faults or worse
maybe you guys are referencing behavior of free in c++ ? The first thing that comes to mind without allocating memory would be casting the input to an array of ints, sorting it and just using continue if a[i] == a[i - 1]. Double free is a dangerous error and should be avoided at all costs. Furthermore, you can't tell if a pointer has been freed just by looking at it, otherwise, C programming would have been really easy. Freeing a nullptr is generally safe, but you have to set it to nullptr first. well that's a way cooler solution than the given solution, I guess technically yours is faster than the given solution too This is indeed nice...
#include <stdio.h>
#include <stdlib.h>
int compare(const void *a, const void *b);
int main(void) {
int i = 0;
int len = 2;
int **ary = malloc(sizeof(int) * len);
int *p = malloc(sizeof(int));;
int *j = p;
ary[0] = p;
ary[1] = j;
qsort(ary, len, sizeof(int), compare);
for (i; i < len; i++) {
if (i > 0 && ary[i] != ary[i - 1]) {
free(ary[i]);
}
}
free(ary);
printf("We are free!\n");
return 0;
}
int compare(const void *a, const void *b) {
return (*(int*)a - *(int*)b);
}
This doesn't free ary[0]
You're right. I'm dumb 
|
On April 20 2017 09:03 Nesserev wrote:(Also, both are valid statements.)
// original setup
p -> a -> d
k -> e
// statement 1
a -> d
p -> k -> e
// statement 2
p -> a -> e
k -> e
Interesting. You're allowed to put operators on the LHS of assignments? Any operator (that makes sense)? Or just pointer operators?
In other words, can you do:
int i, j, k;
i + 1 = 8; // i is 7
(i == 7? j : k) = 101;
I sure hope not, but just wondering. Would be funny to write almost prolog-esque code in C. Just to fuck with whoever has to debug.
E: thinking about it a bit more, dereferencing in the LHS of the statement makes perfect sense, it's just syntax I am not used to seeing. So nvm about my questions about operators. I'm sure they're not allowed. No sane imperative language should allow that kind of stuff 
|
It's quite common in C because that's how you would write to a pointer location. You can assign to a lvalue which is an expression that has a location in memory. So things like,
*(p+1)
(*p).a
*(2+p)
are ok. They could also be written as
p[1]
p->a
p[2]
|
Russian Federation4235 Posts
On April 20 2017 21:12 Acrofales wrote:Show nested quote +On April 20 2017 09:03 Nesserev wrote:(Also, both are valid statements.)
// original setup
p -> a -> d
k -> e
// statement 1
a -> d
p -> k -> e
// statement 2
p -> a -> e
k -> e
Interesting. You're allowed to put operators on the LHS of assignments? Any operator (that makes sense)? Or just pointer operators? In other words, can you do:
int i, j, k;
i + 1 = 8; // i is 7
(i == 7? j : k) = 101;
I sure hope not, but just wondering. Would be funny to write almost prolog-esque code in C. Just to fuck with whoever has to debug. E: thinking about it a bit more, dereferencing in the LHS of the statement makes perfect sense, it's just syntax I am not used to seeing. So nvm about my questions about operators. I'm sure they're not allowed. No sane imperative language should allow that kind of stuff
It takes a while to get your head around, but in C++ even this is possible:
func() = value;
|
Russian Federation4235 Posts
On April 20 2017 10:43 Hanh wrote:Show nested quote +On April 20 2017 06:55 BluzMan wrote:On April 20 2017 06:47 travis wrote:
but j is not null at that point, j is still a pointer to the section of memory that was freed.
p points to null, j contains the address it was assigned when we did j = p
also the above example is bad too. you don't want to free a bunch of memory that was never allocated you'll get seg faults or worse
maybe you guys are referencing behavior of free in c++ ? The first thing that comes to mind without allocating memory would be casting the input to an array of ints, sorting it and just using continue if a[i] == a[i - 1]. Double free is a dangerous error and should be avoided at all costs. Furthermore, you can't tell if a pointer has been freed just by looking at it, otherwise, C programming would have been really easy. Freeing a nullptr is generally safe, but you have to set it to nullptr first. Don't cast a pointer to int, it is not portable and unsafe. Just leave it as a pointer.
I don't exactly remember what the standard says about comparing pointers that don't belong the the same range, but I'm pretty sure it's a step towards undefined behaviour. I'm also pretty sure that it defines an uintptr_t type that you can safely cast any pointer to. I should have made myself clear on that one, yeah.
|
On April 21 2017 00:46 BluzMan wrote:Show nested quote +On April 20 2017 21:12 Acrofales wrote:On April 20 2017 09:03 Nesserev wrote:(Also, both are valid statements.)
// original setup
p -> a -> d
k -> e
// statement 1
a -> d
p -> k -> e
// statement 2
p -> a -> e
k -> e
Interesting. You're allowed to put operators on the LHS of assignments? Any operator (that makes sense)? Or just pointer operators? In other words, can you do:
int i, j, k;
i + 1 = 8; // i is 7
(i == 7? j : k) = 101;
I sure hope not, but just wondering. Would be funny to write almost prolog-esque code in C. Just to fuck with whoever has to debug. E: thinking about it a bit more, dereferencing in the LHS of the statement makes perfect sense, it's just syntax I am not used to seeing. So nvm about my questions about operators. I'm sure they're not allowed. No sane imperative language should allow that kind of stuff It takes a while to get your head around, but in C++ even this is possible: func() = value;
Only if func() returns an lvalue-reference though? So, it's consistent with lvalue's idea.
Edit: As far as I remember, lvalue can only be on the left side. It's a thing that exists after the line is executed (unlike rvalue). So, if a function returns a reference (Object&), then it's an object that persists after function's call, hence it's considered to be lvalue so it's OK to have:
func() = value;
Essentially, you're saying
variable = value;
|
edit: ah no, explanation is way diff from C
|
On April 21 2017 00:53 BluzMan wrote:Show nested quote +On April 20 2017 10:43 Hanh wrote:On April 20 2017 06:55 BluzMan wrote:On April 20 2017 06:47 travis wrote:
but j is not null at that point, j is still a pointer to the section of memory that was freed.
p points to null, j contains the address it was assigned when we did j = p
also the above example is bad too. you don't want to free a bunch of memory that was never allocated you'll get seg faults or worse
maybe you guys are referencing behavior of free in c++ ? The first thing that comes to mind without allocating memory would be casting the input to an array of ints, sorting it and just using continue if a[i] == a[i - 1]. Double free is a dangerous error and should be avoided at all costs. Furthermore, you can't tell if a pointer has been freed just by looking at it, otherwise, C programming would have been really easy. Freeing a nullptr is generally safe, but you have to set it to nullptr first. Don't cast a pointer to int, it is not portable and unsafe. Just leave it as a pointer. I don't exactly remember what the standard says about comparing pointers that don't belong the the same range, but I'm pretty sure it's a step towards undefined behaviour. I'm also pretty sure that it defines an uintptr_t type that you can safely cast any pointer to. I should have made myself clear on that one, yeah.
Well, if you can't compare pointers on your architecture you can't compare pointers casted to integers either.
On segmented memory architecture, two pointers can have different values and yet refer to the same physical location. Even in linear models, it could happen if for example these pointers are obtained from mmap. But otherwise, pointers to the same type have total ordering.
BTW uintptr_t is an optional type.
|
|
|
Lol. That is one dated song! :D
|
we've been assigned a bit of a harder project than anything we've had before
anyways i need to check up on my understanding of trees/recursion
Let's say I am given a tree of "commands", and the commands come in 2 types: instructions and conjunctions. Each node on the tree is an instruction, or a conjunction (such as &&, or piping).
commands have been entered into the tree such that the first most instruction you execute will be the furthest left leaf.
The tree is a binary tree, where instructions are always leafs and conjunctions always have a left and a right node.
Would I be correct in that the way I should traverse this tree, to execute commands in order, should be something like this:
recursive_traversal(node) {
if node is a tree {
recursive_traversal(left)
visit current node
recursive_traversal(right)
}
if node is a leaf {
visit current node
}
}
edit: wait.. why am I doing this. In this case I could just do an in order traversal of nodes couldn't I? hmmm now I am worried there was some reason why I wanted to do this in this way
|
The pseudocode you posted IS an in-order traversal of nodes. And seems correct to me...
|
On April 22 2017 02:56 Acrofales wrote:
The pseudocode you posted IS an in-order traversal of nodes. And seems correct to me...
well for in order traversal can't I get rid of the the first if statement and remove the 2nd if statement/block entirely ?
oh wait, no I can't huh. well I am a bit silly aren't I
|
edit: nevermind. rubber ducky debugging. sorry for spam
|
Hyrule19252 Posts
don't apologize to my duck
![[image loading]](http://i.imgur.com/RhPSuwc.jpg)
|
|
|
|
|
|
EPT
