Order of ids in id list

hawesie

Hi,

I just thought I'd post this as question before going on to raise a bug report (if warranted).

Is there, or should there be, a fixed order to the strings in the static id array generated for the slice classes? E.g. for a class like

class PlaceMergeNotification {
    PlaceIDSeq mergedPlaces;
    long resultingPlace;
  };

I get the following C++ and Java:

static const ::std::string __SpatialData__PlaceSplitNotification_ids[2] =
{
    "::Ice::Object",
    "::SpatialData::PlaceSplitNotification"
};

public static final String[] __ids =
{
    "::Ice::Object",
    "::SpatialData::PlaceSplitNotification"
};

This is the general pattern for most of the source I generate: the most derived class is last in the list.

However, occasionally I get the id list reversed. E.g.

  class NodeHypothesis {
    double x;
    double y;

    int hypID;
    int originPlaceID;
  };

... yields...

static const ::std::string __FrontierInterface__NodeHypothesis_ids[2] =
{
    "::FrontierInterface::NodeHypothesis",
    "::Ice::Object"
};

public static final String[] __ids =
{
    "::FrontierInterface::NodeHypothesis",
    "::Ice::Object"
};

My code (currently) relies on the order of the id lists to do some simple type inference, but if the order of the lists can vary then it adds some complications.

This is Ice 3.3.1 compiled from source on Mac OS X 10.6 (Snow Leopard). The examples above are taken from a much larger project (so they may work fine in isolation).

thanks,

Nick

benoit

Hi,

The ids are stored in alphabetic order to allow binary searches so this is expected. What order did you expect instead?

Cheers,
Benoit.

hawesie

I guess I expected them in order of the inheritance hierarchy. Thinking about it, I'm not sure what led me to this expectation. Alphabetical is good for me though. Thanks!

Nick

michi

I guess I expected them in order of the inheritance hierarchy.

Due to multiple inheritance, there is no well-defined unique linear ordering that would depend on the inheritance hierarchy.

Cheers,

Michi.