So, you "only" want split the object.h struct with a union in different
called parts?? You know how much code lines this effects?
Its really some major work... you have to change ALOT there. No question
is useful, but it has some masochistic touch ... :)
I would say: give me the fix, i put it in... But should not do some
#defines the same ? Like
#define WAYPOINT_XOFF(_ob_) _ob_->x
Its of course not so clean but...
But it is an old issue (the double/xx use of *object parts).
One more problem is, that we use in the map scripts the related
names too. This can be change too but i don't want add several new
keywords refering to the same object part... And when the map makers
get confused by double/different meaning of a field part/script name
in a arch - how confused the get when we tell him that different names
means the same field part?
I thought itself some time about it and i never got a good idea which
not has some drawbacks.
MT
>
> jlittle and me had a little brainstorming about the object struct in
> object.h
>
> As you might know, all objects contain the same data -- no matter if it=
is
> a floor tile or a NPC. There is one big ugly struct that has to be used=
in
> really strange ways.
>
> Our suggestion is that we start rewriting it using a union to handle th=
e
> fact that different object types need different data.
> This can be done in a backwards-compatible way (no need to change all t=
he
> old code, we can roll out the changes part by part) by using anonymous
> unions. So a new struct object would be something like this:
> (the shown fields are just some examples of what kind of data should go
> where.)
>
> struct object {
> /* Here comes common data used by object management */
> ...
> object *env;
> ...
>
> union {
> struct {
> /* Here come all the old fields currently in struct object */
> ...
> uint16 x, y;
> ...
> };
>
> struct {
> /* Special data for one of the object types. e.g. waypoints */
> ...
> uint16 dest_x, dest_y;
> ...
> } waypoint;
> };
> };
>
> Nothing has to be changed to the code using the old system, and that co=
de
> can be slowly replaced by new unions. So instead of code looking like
> this:
>
> find_path(op, op->map, op->x, op->y, destmap, waypoint->stats.hp,
> waypoint->stats.sp)
>
> we would get something more readable (i.e. the fields do what you expec=
t
> them to do.):
>
> find_path(op,op->map, op->x, op->y, destmap, waypoint->waypoint.dest_x,
> waypoint->waypoint.dest_y)
>
> The pros are
> 1) more readable and maintainable code and
> 2) possibly a smaller object struct in the future if we can
> remove redundant fields.
> 3) No changes necessary to old code. New and old code can coexist
> 4) It works, and no animals were hurt during the brainstorming =3D)
>
> The cons:
> 1) Problems with loading/saving data
> 2) unnamed unions are not part of ISO C =3D(
>
> Problem 1 can be handled by carefully lining up the unions to follow th=
e
> layout of the original data (possibly by reordering the original data s=
o
> fields off different size are in order). This requires careful ordering
> and padding of the fields in the new unions, but as long as an int16 in
> the waypoint data lines up with a int16 in the original data the old fi=
le
> IO code still works.
>
> Problem 2 is not so bad since the code above cleanly compiles under
> gcc-3.x and Visual Studio. It does however not compile under gcc-2.95, =
or
> with the "-ansi -pedantic" flags. This will no longer be a problem when
> all code has been converted and we no longer need an unnamed union for =
the
> old data.
>
> As I inderstand it is jlittle prepared to do, or has already done all t=
he
> preliminary work for this and we can try it out on the waypoint and
> killcredz systems.
>
> So, what do you guys think?
>
> --
> Bj=F6rn Axelsson
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Daimonin-devel mailing list
> Daimonin-devel@...
> https://lists.sourceforge.net/lists/listinfo/daimonin-devel
|