Structures and inheritence

[Arta]

I didn't want to have to go through another pointer - this has to remain compatible with existing code.

[Kp]

I didn't want to have to go through another pointer - this has to remain compatible with existing code.

Code Select Expand


struct User {
   char name[16]; /* user's name, known to everyone */
};
struct LocalUser {
   User blah; /* interserver data */
   unsigned local_data_item1; /* add more as needed */
};

Thus, no pointers, and it does as Adron suggested.

[Arta]

With that, you'd have to do:

Code Select Expand


Local->User.name


to get to name. I want to be able to do

Code Select Expand


Local->name


in order to remain compatible with existing code.

[iago]

With that, you'd have to do:

Code Select Expand


Local->User.name


to get to name. I want to be able to do

Code Select Expand


Local->name


in order to remain compatible with existing code.

I'd imagine you could override operator-> if you wanted to.  Although I've never tried overriding that one

[Eibro]

Icky icky, but it'd probably work

Code Select Expand

struct User {
   char name[16]; /* user's name, known to everyone */
   operator char*() { return name; }
};

[Kp]

With that, you'd have to do:

Code Select Expand


Local->User.name


to get to name. I want to be able to do

Code Select Expand


Local->name


in order to remain compatible with existing code.

Yes, it would require a change.  However, unless you use really eww variable names, it ought to be pretty easy to come up with substitution patterns that can do all the renaming for you.  For instance, s/name/User.name/g.

[Adron]

Yes, it would require a change.  However, unless you use really eww variable names, it ought to be pretty easy to come up with substitution patterns that can do all the renaming for you.  For instance, s/name/User.name/g.

Or simply #define servinfo_name User.user_name a la s_addr.