I believe that an enum with hundreds of posible values would have the same problem. After all, we are talking of what are likely to be a one-liner functions.1. Ease of implemenation - You'd have to write a function for each "value" you want which as you've already stated, with hundreds could be a lot.
I think that we have to take this into perspective. Are we likely to use this with hundreds of values? Meyers' example was with dates, in particular a Month class. There are only twelve months in a year, and this status quo is likely to stay for the duration of our lifetimes. Likewise, there are four cardinal directions, and this is not likely to change either.2. Maintenance and error proneness. - Because you have to assign each integer value, a class with hundreds of values is more prone to duplicates, either by careless assignment or typo whereas enum value assignment is automatic. Inserting a value in between other values would be quite difficult for the static functions.
I note that Meyers' example corresponds very closely to the integers that the static member functions are supposed to replace (e.g., we usually designate January as month 1). But there is no precedent by which west should be 1 and south 2. So, having an enum in which the values are not explicitly given makes more sense than arbitrarily assigning values. On the other hand, if we see that we might want to add the ordinal directions, or even all the principal compass points, then using the compass point angles to provide integer values could well be an even better solution.
I agree, but the objects in question are not likely to be heavyweight in construction, assignment and destruction, and this factor may even prove to be negligible.3. Efficiency - Every time you change a direction, with the static method you create a new temp object which calls a constructor, destructor and assignment operator.