Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ILikePie]

ILikePie, you are actually making out->data point to the same location as the function's data variable, and since that variable is local to the function, the memory it points to is released after the function returns. Therefore you need to copy the data using the memcpy function.

That did it, thanks.

[MaximumZero]

Anyone here good with VB? I'm stumped on a project for school that seems like I'm overlooking something really stupid.

Nevermind, I'm just a dumbass. Carry on being better programmers than me.

[Nadaka]

And that's why I never use arrays.

You can create arrays on the heap.

[Virex]

OK now I'm utterly stumped. I tried loading a library into a running image of Clozure Common Lisp using:

Code: [Select]

(CFFI:load-foreign-library "C:\\Programming\\Projects\\lisp\\BloodTV\\lib\\SDL.dll")Now that works fine. However, trying to load it's little brother fails:

Code: [Select]

CCL-USER>(CFFI:load-foreign-library "C:\\Programming\\Projects\\lisp\\BloodTV\\lib\\SDL_ttf.dll")
; Evaluation aborted on #<CFFI:LOAD-FOREIGN-LIBRARY-ERROR #xCC14246>.
CCL-USER>(let ((CFFI:*foreign-library-directories* '(#P"C:\\Programming\\Projects\\lisp\\BloodTV\\lib\\")))
        (CFFI::load-foreign-library "SDL_ttf.dll"))
; Evaluation aborted on #<CFFI:LOAD-FOREIGN-LIBRARY-ERROR #xCC14246>.

CL-USER> (if :this-sucks
         (format t "yeah this does suck")
         (format t "No, you're just an idiot"))
yeah this does suck
NIL
This fails with the error:
Unable to load foreign library (LIBRARY-81).
  Error opening shared library C:\Programming\Projects\lisp\BloodTV\lib\SDL_ttf.dll : Kan opgegeven module niet vinden. .
   [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR].


However, the file system is capable of finding the supplied file:

Code: [Select]

CL-USER>(probe-file "C:\\Programming\\Projects\\lisp\\BloodTV\\lib\\SDL_ttf.dll")
#P"C:/Programming/Projects/lisp/BloodTV/lib/SDL_ttf.dll"And so can the CFFI library:

Code: [Select]

CL-USER>(CFFI::find-file "SDL_ttf.dll" '(#P"C:\\Programming\\Projects\\lisp\\BloodTV\\lib\\"))
#P"C:/Programming/Projects/lisp/BloodTV/lib/SDL_ttf.dll"
(let ((CFFI:*foreign-library-directories* '(#P"C:\\Programming\\Projects\\lisp\\BloodTV\\lib\\")))
       (CFFI::find-file "SDL_ttf.dll" CFFI:*foreign-library-directories*))
#P"C:/Programming/Projects/lisp/BloodTV/lib/SDL_ttf.dll"

So I suspect the problem is in windows failing to find the DLL or something, but I have no clue about how to check that. Is there any way to ensure the filesystem can open the DLL?

[nenjin]

So I've got a generic concept question.

You make classes. Classes contain all this nice data and functions. When you instance an object of a class, you get an object in memory that contains all the stuff contained in the class it was instanced from.

My brain still has trouble wrapping itself around this concept though: how do you dynamically instance and track class objects? Say you're making a game and you have your class definition for what a monster is, and when the game is in play, the program instances an object of class Monster:Griffon. In the code, you tell the function to instance an object of class Monster:Griffon....but how you would go about labeling and identifying this object dynamically? Can you write a function such that it instances an object of the class with a handle that is derivative? So something like griffon++ = getGriffonCount(), or whatever would work with correct syntax?

I'm in the process of defining some data structures for an idea I have and I understand that you write the class to contain all the data to be instanced....I just can't really see the process as it would function in real time.

[Levi]

My brain still has trouble wrapping itself around this concept though: how do you dynamically instance and track class objects? Say you're making a game and you have your class definition for what a monster is, and when the game is in play, the program instances an object of class Monster:Griffon. In the code, you tell the function to instance an object of class Monster:Griffon....but how you would go about labeling and identifying this object dynamically? Can you write a function such that it instances an object of the class with a handle that is derivative? So something like griffon++ = getGriffonCount(), or whatever would work with correct syntax?

I'm in the process of defining some data structures for an idea I have and I understand that you write the class to contain all the data to be instanced....I just can't really see the process as it would function in real time.

The instance itself shouldn't need to be labeled externally.  Just toss it in an array or something and be done with it.  If you need to retrieve it based on a label, give the class a string member called "label" or "name" and search through the array for that object.

Now you could write a static function in the class to keep track of all instanced griffins, but its generally best to avoid that unless you really need to.

Edit:  If you want to have a unique label for each griffon for some reason, you could just keep a static integer value in the class that gets incremented every time in the constructor.  Something like this:

Code: [Select]

Pseudocode:

class Griffon
  string name;
  static int id = 0;

  def constructor()
    name = "Griffon_" + to_char(id)
    id++
  end
end




[nenjin]

Yeah, I know to tread lightly around static functions and variables.....I guess my question though is, the program knows the difference between instanced class objects explicitly because of the different positions they occupy in memory, yeah? Doesn't that mean you'd still need to store a pointer or reference in an array to find it later? (Or find it a hell of a lot more quickly?)

Code: [Select]

Pseudocode:

class Griffon
  string name;
  static int id = 0;

  def constructor()
    name = "Griffon_" + to_char(id)
    id++
  end
end

Thanks, that's more or less what I thought would be doable.

[Levi]

Yeah, I know to tread lightly around static functions and variables.....I guess my question though is, the program knows the difference between instanced class objects implicitly because of the different positions they occupy in memory, yeah? Doesn't that mean you'd still need to store a pointer or reference in an array to find it later? (Or find it a hell of a lot more quickly?)

Absolutely.  For objects you almost always want to use pointers.  So the array of monsters would actually be an array of pointers to monsters. 

[nenjin]

Gotcha.

[Shades]

Yeah, I know to tread lightly around static functions and variables.....I guess my question though is, the program knows the difference between instanced class objects implicitly because of the different positions they occupy in memory, yeah? Doesn't that mean you'd still need to store a pointer or reference in an array to find it later? (Or find it a hell of a lot more quickly?)

Absolutely.  For objects you almost always want to use pointers.  So the array of monsters would actually be an array of pointers to monsters.

I'd recommend references over pointers in languages that have both. (languages that don't you don't need to think about it

[Levi]

Yeah, I know to tread lightly around static functions and variables.....I guess my question though is, the program knows the difference between instanced class objects implicitly because of the different positions they occupy in memory, yeah? Doesn't that mean you'd still need to store a pointer or reference in an array to find it later? (Or find it a hell of a lot more quickly?)

Absolutely.  For objects you almost always want to use pointers.  So the array of monsters would actually be an array of pointers to monsters.

I'd recommend references over pointers in languages that have both. (languages that don't you don't need to think about it

My memory of c++ is a little hazy, but wouldn't you run into scoping issues with references?  The memory would be de-allocated if you leave the scope the object was declared in, right?

[Shades]

My memory of c++ is a little hazy, but wouldn't you run into scoping issues with references?  The memory would be de-allocated if you leave the scope the object was declared in, right?

I'm assuming the array/list/vector/map/set of references would itself be owned by something or that defeats the whole point of being able to get access to the object.
If the array was deleted then yes the object would be as well, but assuming this is the definitive object list every other reference would be to the one in this set and so the delete behaviour is what you would want.

Specifically in C++ you would ideally pass the objects around as Griffon& or Griffon const& depending on if the caller in question needed to be to alter it and the array would be something like stl::array<Griffon>. (or more likely stl::vector<Griffon> so you could add and remove at will)

This has the added benefit of never needing to nullptr check your pointers or worry about memory leaks

[Levi]

My memory of c++ is a little hazy, but wouldn't you run into scoping issues with references?  The memory would be de-allocated if you leave the scope the object was declared in, right?

I'm assuming the array/list/vector/map/set of references would itself be owned by something or that defeats the whole point of being able to get access to the object.
If the array was deleted then yes the object would be as well, but assuming this is the definitive object list every other reference would be to the one in this set and so the delete behaviour is what you would want.

Specifically in C++ you would ideally pass the objects around as Griffon& or Griffon const& depending on if the caller in question needed to be to alter it and the array would be something like stl::array<Griffon>. (or more likely stl::vector<Griffon> so you could add and remove at will)

This has the added benefit of never needing to nullptr check your pointers or worry about memory leaks

Hmm, fair enough I suppose that works.    I feel more comfortable the other way for some reason, it just sits in my head better.   

[Shades]

Hmm, fair enough I suppose that works.    I feel more comfortable the other way for some reason, it just sits in my head better.   

Either way works, but as a rule of thumb it's better to use references where you can and pointers where you must. There are a whole load of reasons for this but the main one in my mind is that there is just less that can go wrong with a reference.

That said the main point of C++ (and C) is to give the developer the control to program how they want/need to, so whatever feels right to you go with.

[nenjin]

Oh no, by all means, tell me what has resulted in the least programmers sitting in padded rooms. Having not made anything practical yet, this is all good stuff. I've already settled on using references as much as possible, for some reason they seem easier to construct and manage.