On 16 Aug 2008, at 23:29, Tim Moore wrote:
> I don't find this use of type enums in a base class to be clean at
> all. I have
> nothing against having a type field in a base, but with an enum
> approach the
> base has to have knowledge of all the derived classes, and any time
> you add a
> new one the base has to be modified. I'd prefer to see here a
> singleton type
> object defined in each derived class that compared to in order to
> find the type.
Well, there's a motive here: because I'm using consecutive numbers for
the types, I can implement things like 'all airports' or 'all ATC
frequencies' as range compares, by doing lower_bound and upper_bound
queries against appropriate sets and multipmaps. This scheme doesn't
work perfectly for every kind of type-based query, but it handles a
lot of cases pretty well - right now we tend to want everything of a
certain type (airports is the classic example) or just one specific
type.
Equally, the enum doesn't have to live inside the type - the base
class doesn't really do anything with them, they could just be ints,
so I'd be fine with individual derived classes just claiming chunks of
the numbering space. But being able to write switch statements on type
code, or range-checks (if type >= FOO and type <= FOO2), especially in
a FMS / GPS / flightplan context is very handy.
> Also, your search member functions don't seem to belong to
> "FGPositioned," but
> to the index that stores these things.
Well, that's a personal style thing - my preference is for indexes to
be internal to the class of things they index, i.e implements as class
or file statics. I certainly want to get rid of the 'list' classes
from globals (I have a dream of a future without globals.hxx at all,
but that will take years). I don't think there's a huge difference
between
class FGAirport
{
}
class FGAirportList
{
public:
static FGAirportList* instance(); // or globals->get_airport_list(),
whatever
FGAirport* findByBlah(....);
}
and
class FGAirport
{
public:
static FGAirport* findByBlah()
}
Semantically, I like the second because at a call site, you can see
that you're dealing with FGAirport - it makes the find method 'self-
naming', but this is very much a personal taste issue.
> Finally, in my own code I've been using the simgear and flightgear
> namespaces
> instead of the SG and FG prefixes, but I won't force anyone else to
> do that :)
I must say a 'flightgear' namespace seems a bit pointless to me, since
FlightGear isn't a library, but by that argument the FG prefix is also
pointless. I'd happily drop it, or use a flightgear namespace if
people felt that was a better approach.
James
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
