Reputation: 2196 Grandmaster
- Active Posts:
- 3,400 (2.43 per day)
- 21-June 11
- Profile Views:
- Last Active:
- OS Preference:
- Favorite Browser:
- Who Cares
- Favorite Processor:
- Who Cares
- Favorite Gaming Platform:
- Who Cares
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
- C/C++, Functional Programming, Java, Python, Computer Science
Posts I've Made
Posted 19 Apr 2015No, at least in the official Ruby implementation, Fixnums (that is integers that need less than 32/64 bits depending on the platform), booleans and nil are stored as tagged pointers (that is "pointers" that don't actually point anywhere, but rather encode the given value directly), not on the heap.
It will still be slower than C# though, but that's to be expected in a dynamically typed language.
Posted 18 Apr 2015One more question, on line 12 I'm doing
How does it know how many elements are in the array? Or does it just not matter?
It does matter. new stores that information in an implementation-defined manner and delete can then just access it.
QuoteI'm just wondering how the entire block of memory gets sent back to the heap (or am I thinking old style C and off in left field here)? I'm just a bit concerned that I might have a memory leak there if I'm not specifying how many array elements to let go of.
You don't do that in C either, do you? You specify a size when calling malloc and then free just takes the pointer - not a number of elements. So it's the exact same thing as new and delete (except the latter are type safe).
QuoteOriginally I was just saying
without even specifying that it was an array.
Does it matter?
That will invoke undefined behavior. In practice it may not make a difference for primitive types (for classes it will invoke the wrong number of destructors at the least), but it's undefined, so you shouldn't rely on it working.
To expand on that: the most likely implementation of new T and new T[n] are "malloc(sizeof(T)) + call the constructor" and "malloc(sizeof(T) * n) + call the constructor n times" respectively. So delete and delete would be "free(ptr); + call destructor" and "free(ptr); + call n destructors". So when there's no destructors, there'd be no difference between delete and delete. However there's no guarantee that that's how it's really implemented, so it's, as always, best to just stick with the defined behavior.
Posted 18 Apr 2015Now I would like to understand why this works and the other does not.
As I said *ArrayPtr is parsed as *(ArrayPtr). So it takes the 4th element from the address that ArrayPtr points to and then dereferences that, which would make sense if ArrayPtr pointed to the beginning of an array of pointers, but it does not. It points to a single pointer, so ArrayPtr invokes undefined behavior.
QuoteYou also mentioned passing a reference to my pointer. I tried & in a few places and that didn't work out for me so well, but I may have been doing it wrong. I have to admit pointers have never been my strong suit.
int*& ArrayPtr. After you did that, you can change the rest of the code back to your initial version (where you had int* ArrayPtr) and it will now work without any double dereferences or parentheses nightmares.
QuoteOk. So it was really moving to the third element of the outer pointer instead of the inside (array) pointer, which is totally wrong because the outer pointer is not an array of pointers but just one single pointer and I wasn't even pointing to the array any more. That would explain why it blew up.
Posted 18 Apr 2015Oh, I just realized, the syntax you use in your cond is wrong. Each case of the cond should be an opening parenthesis, followed by a condition, followed by one or more expressions that should be executed when the condition is met (as in not #f), followed by a closing parenthesis.
So when you write (equal? (car input) #\space (delete(cdr input))), equal? is your condition and (car input) #\space (delete(cdr input)) are the expressions to execute when that condition is met. Since equal? is a function, it will never be #f and the condition will always be met. What you want is to call the function, meaning you need an extra pair of parentheses enclosing the function and its arguments.
Once you fix that for both your conditions, you'll probably realize that the condition (equal? (car input) null) is never met. That is because (car input) either returns an element of the list (which will be a character and thus never equal to null or causes an error (if the list was empty). To check whether the list is empty, don't use car on it, just compare it to null directly or, better, use null?.
Posted 18 Apr 2015car and cdr produce an error when you try to call them on the empty list, which is why you get the error you do. Note that if they didn't do this, you'd get infinite recursion as you don't have a base case.
What you need to do is to add a case to your cond for when the list is empty.