sepp2k's Profile User Rating: *****

Reputation: 2196 Grandmaster
Group:
Mentors
Active Posts:
3,400 (2.43 per day)
Joined:
21-June 11
Profile Views:
55,897
Last Active:
User is offline Private
Currently:
Offline

Previous Fields

Country:
DE
OS Preference:
Linux
Favorite Browser:
Who Cares
Favorite Processor:
Who Cares
Favorite Gaming Platform:
Who Cares
Your Car:
Who Cares
Dream Kudos:
0
Expert In:
C/C++, Functional Programming, Java, Python, Computer Science
Icon   sepp2k has not set their status

Posts I've Made

  1. In Topic: Ruby and stack memory

    Posted 19 Apr 2015

    No, 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.
  2. In Topic: Dynamically allocating an array passed as a parameter

    Posted 18 Apr 2015

    View PostBBeck, on 18 April 2015 - 10:01 PM, said:

    One more question, on line 12 I'm doing

    delete[] MyArray; 
    
    


    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.

    Quote

    I'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).

    Quote

    Originally I was just saying

    delete MyArray;
    
    


    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.
  3. In Topic: Dynamically allocating an array passed as a parameter

    Posted 18 Apr 2015

    View PostBBeck, on 18 April 2015 - 09:20 PM, said:

    Now I would like to understand why this works and the other does not.


    As I said *ArrayPtr[3] is parsed as *(ArrayPtr[3]). 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[3] invokes undefined behavior.

    Quote

    You 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.

    Quote

    Ok. 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.


    Exactly.
  4. In Topic: Scheme: Removing a char from a string

    Posted 18 Apr 2015

    Oh, 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?.
  5. In Topic: Scheme: Removing a char from a string

    Posted 18 Apr 2015

    car 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.

My Information

Member Title:
D.I.C Lover
Age:
Age Unknown
Birthday:
Birthday Unknown
Gender:
Years Programming:
15
Programming Languages:
Haskell, Ruby, OCaml, SML, F#, Scala, Racket/Scheme, Vala, C#, C++, Java

Contact Information

E-mail:
Private
ICQ:
ICQ  205544826
Jabber:
Jabber  sexykane86@jabber.ccc.de