If you're doing manual resource management, then no, the default assignment operator won't work. Your class is clearly in violation of the Rule of Three, you should read up on it.

In my destructor I delete dynamic arrays which I create when loading a scene. These pointer arrays are set to NULL in the constructor.

Use std::vector instead of your own dynamic array. If you do, the destructor, copy constructor and assignment operator would automatically do the right thing for you and you don't need to write them.

If I go for this I think I also have to adopt iterators and use the size() function, instead of looping up to for example mNrLighs or mNrMeshes. I'll probably keep them to not depend on only the size() of each vector. To prevent that all my source files throughout my engine are required to use vectors. Unless my const functions returning for example the number of lights, meshes etc, just return the vector.size() value.

You can iterate a vector without iterators, the same as you would an array, since it provides a subscript operator and at() function. The only difference in your code would be switching from a manually controlled size to the vector's .size(). Of course, iterators are nice because should you ever decide to switch from a vector to some other standard container, you don't have to refactor all your code again.

Thanks Alvaro.
I never found any good reasons to use std::vector, up till now that is

I'll get into it. Always thought I'd be wasting memory when I "reserve" to much elements versus giving in performance when not reservering and only use "push back". Maybe I'll do a new reserve of the vectors size +10 every time I've pushed back 10 more elements. To prevent unnecessary copying. Although this 'feels' like using the advantages of std::vector only partially.

That's why up till now I used dynamic arrays with the size I need. The advantage of the std::vector though, is that for example when loading my scene from file, I don't have to do it twice, once for just counting (determine size of dynamic arrays) and once for the actual loading.

If you already use your own dynamic vectors with the size you need, then why not use that size to reserve space for the vector as well?

If I go for this I think I also have to adopt iterators and use the size() function, instead of looping up to for example mNrLighs or mNrMeshes. I'll probably keep them to not depend on only the size() of each vector. To prevent that all my source files throughout my engine are required to use vectors. Unless my const functions returning for example the number of lights, meshes etc, just return the vector.size() value.

That's quite a lot of changes throughout the whole engine, but with the advantage being good practice and creating future flexibility.

It's a bad idea to keep track of the size yourself when the vector is already doing that. It introduces more points of failures when you have to ensure that your code is, in fact, always up to date with the vectors: the vectors do that themselves automatically. Switching from your own dynamic arrays to using standard vectors is not something you should just do halfway.

And as Zipster said, you don't have to use iterators to access the vector. You probably already use pointer or array subscript access your own dynamic array, and those methods can still be used with the vector.

Thanks.
Regarding the 1st point, I do have the requested sizes now, but they're gathered going through a file once, and then loaded afterwards, reading the file again.
I think with std::vector I should be able to do that at once, with each next object just 'push back' the next one. And then in the end I know the total number.
When I'm thinking about this, this is probably the answer. After loading I can use the size() function of each array in my const functions, returning the number of meshes, lights etc.

The only disadvantage is when I load the file directly and fill the objects in the array, I don't know the size on forehand, meaning I have to do some reserve actions (maybe after each 10 objects or so). Unless the disadvantage of copying the array of objects, when I exceed the size of the std::vector, is not that bad (since it's only during loading time).

The question is then: is it more expensive to parse the file once to figure out the number of items, or to relocate the vector a few times?

By the way, is there some sort of default size that's reserved when initializing the std::vector as member of my class?

Visual Studio 2012 appears to not pre-reserve anything by default, and is expanding the vector by 50% every time it has to reserve more memory. This exponential growth is very efficient in the long run as opposed to just reserve an additional fixed number of items as you mentioned in an earlier post.

Will reserving 'x' objects of the std::vector's in my constructor kill the possibility to use the default assignment operator, copy operator and destructor?

No, the vector won't stop working because you tell it to reserve memory before adding items to it.