user defined Copy ctor, and copy-ctors further down the chain - compiler bug ? programmers brainbug ?

Question

Hi. i have a little problem, and I am not sure if it's a compiler bug, or stupidity on my side. I have this struct :

struct BulletFXData
{
 int time_next_fx_counter;
 int next_fx_steps;
 Particle particles[2];//this is the interesting one
 ParticleManager::ParticleId particle_id[2];
};

The member "Particle particles[2]" has a self-made kind of smart-ptr in it (resource-counted texture-class). this smart-pointer has a default constructor, that initializes to the ptr to 0 (but that is not important)

I also have another struct, containing the BulletFXData struct :

struct BulletFX
{
 BulletFXData     data;
 BulletFXRenderFunPtr   render_fun_ptr;
 BulletFXUpdateFunPtr   update_fun_ptr;
 BulletFXExplosionFunPtr  explode_fun_ptr;
 BulletFXLifetimeOverFunPtr  lifetime_over_fun_ptr;

 BulletFX( BulletFXData     data,
    BulletFXRenderFunPtr   render_fun_ptr,
    BulletFXUpdateFunPtr   update_fun_ptr,
    BulletFXExplosionFunPtr  explode_fun_ptr,
    BulletFXLifetimeOverFunPtr  lifetime_over_fun_ptr)
 :data(data),
 render_fun_ptr(render_fun_ptr),
 update_fun_ptr(update_fun_ptr),
 explode_fun_ptr(explode_fun_ptr),
 lifetime_over_fun_ptr(lifetime_over_fun_ptr)
 {
 }
/*
 //USER DEFINED copy-ctor. if it's defined things go crazy
     BulletFX(const BulletFX& rhs)
     :data(data),//this line of code seems to do a plain memory-copy without calling the right ctors
     render_fun_ptr(render_fun_ptr),
     update_fun_ptr(update_fun_ptr),
     explode_fun_ptr(explode_fun_ptr),
     lifetime_over_fun_ptr(lifetime_over_fun_ptr)
     {
     }
    */
    };

If i use the user-defined copy-ctor my smart-pointer class goes crazy, and it seems that calling the CopyCtor / assignment operator aren't called as they should. So - does this all make sense ? it seems as if my own copy-ctor of struct BulletFX should do exactly what the compiler-generated would, but it seems to forget to call the right constructors down the chain. compiler bug ? me being stupid ?

Sorry about the big code, some small example could have illustrated too. but often you guys ask for the real code, so well - here it is :D

EDIT : more info :

typedef ParticleId unsigned int; 

Particle has no user defined copyctor, but has a member of type :

Particle
{
    ....
    Resource<Texture>  tex_res;
    ...
}

Resource is a smart-pointer class, and has all ctor's defined (also asignment operator) and it seems that Resource is copied bitwise.

EDIT :
henrik solved it... data(data) is stupid of course ! it should of course be rhs.data !!!
sorry for huge amount of code, with a very little bug in it !!!
(Guess you shouldn't code at 1 in the morning :D )

Answer 1

:data(data)

This is problematic. This is because your BulletFXData struct does not have it's own copy-ctor. You need to define one.

Answer 2

Two things jump out at me:

1. Is this a compiler bug
   No. It is never a compiler bug. In twenty years I have seen enumerus complaints,
   'it must be a compiler bug' only one has ever turned out to be a bug and that way
   back with gcc 2.95 (nowadays gcc is solidly stable (as is dev studio))'
2. I built my own smart pointer.
   Its a nice concept and a nice learning experience. But it is so much harder to get correct than you think. Especially when you seem to be having trouble with
   copy constructors

This is wrong The structure is copy constructed using itself as the object to be copied. Thus you are copy random data into itself.

:Look at comments to see what you should be using as parameters.

//USER DEFINED copy-ctor. if it's defined things go crazy
 BulletFX(const BulletFX& rhs)
 :data(data),                                   // rhs.data
 render_fun_ptr(render_fun_ptr),                // rhs.render_fun_ptr
 update_fun_ptr(update_fun_ptr),                // rhs.update_fun_ptr
 explode_fun_ptr(explode_fun_ptr),              // rhs.explode_fun_ptr
 lifetime_over_fun_ptr(lifetime_over_fun_ptr)   // rhs.lifetime_over_fun_ptr
 {
 }

Of course at this point you may as well use the compiler generated version of the copy constructor as this is exactly what it is doing.