Binary Compatibility Question
Author
Hi,
My apologies if this is a duplicate post but I couldn't seem to find a response to what I was looking for. Basically my question (with details of implementation) is this:
I have an enumeration defined in a project which will be released as a .lib. The .h file containing the enumeration will also be shipped with the released product so the user can add additional values to the enumeration as they see fit.
My question is:
If the user makes a change to the enumeration in the .h provided (which some classes within the .lib will use as a member variable) would they also be required to recompile the .lib file or are they able to simply tack on additional enumerations to the list, compile their application and the objects within the lib itself will not be affected?
Thanks in advance.
Ryan
This will probably slip through, but this is technically a violation of the one-definition rule, isn't it?
If it does slip through (like I suspect), then adding new values would be okay, as long as values aren't replaced. For example, if you had an enum like:
and you changed it to:
Then you'd have issues. The one other thing to consider is if the enum is used internally in your code, will your code handle the existence of unexpected values in the enumeration? You may want to consider a method of adding values that you can better manage than an enumeration.
If it does slip through (like I suspect), then adding new values would be okay, as long as values aren't replaced. For example, if you had an enum like:
enum { Red = 0, Green = 1, Blue = 2};and you changed it to:
enum { Red = 0, Orange = 1, Green = 2, Blue = 3};Then you'd have issues. The one other thing to consider is if the enum is used internally in your code, will your code handle the existence of unexpected values in the enumeration? You may want to consider a method of adding values that you can better manage than an enumeration.
Quote:Original post by Trentelshark
Hi,
My apologies if this is a duplicate post but I couldn't seem to find a response to what I was looking for. Basically my question (with details of implementation) is this:
I have an enumeration defined in a project which will be released as a .lib. The .h file containing the enumeration will also be shipped with the released product so the user can add additional values to the enumeration as they see fit.
My question is:
If the user makes a change to the enumeration in the .h provided (which some classes within the .lib will use as a member variable) would they also be required to recompile the .lib file or are they able to simply tack on additional enumerations to the list, compile their application and the objects within the lib itself will not be affected?
Thanks in advance.
Ryan
Btw, why not release your project as a dll? That could save some grief.
Quote:Original post by Trentelshark
If the user makes a change to the enumeration in the .h provided (which some classes within the .lib will use as a member variable) would they also be required to recompile the .lib file or are they able to simply tack on additional enumerations to the list, compile their application and the objects within the lib itself will not be affected?
Why would you ever want to do this? Your library would have no clue what to do with the new members of the enum, so the user might as well just make their own enum.
Author
The basic idea behind the enumeration is this:
The core application (housed in a DLL) natively handles a number of object "types" (controllers) and will ignore those which are user defined. The idea behind the enumeration was to provide this to the user to show them that IDs x - y are used by the core application, and if they implement their own controllers that they need to begin setting their IDs at current value + 1. Beyond an enumeration I don't have a decent means of accomplishing this short of bolded font 72 in the included documentation.
The core application (housed in a DLL) natively handles a number of object "types" (controllers) and will ignore those which are user defined. The idea behind the enumeration was to provide this to the user to show them that IDs x - y are used by the core application, and if they implement their own controllers that they need to begin setting their IDs at current value + 1. Beyond an enumeration I don't have a decent means of accomplishing this short of bolded font 72 in the included documentation.
It's not technically legal, but is unlikely to cause problems. One thing, though: force the size of the enumeration.
The last enumerant, of course, is unused, but forces the compiler to use 32 bits for the enumeration instead of 8 or 16.
enum Foo{ Bar = 0, Baz = 1, Qux = 2, FOO_FORCE_SIZE = 0xffffffff};The last enumerant, of course, is unused, but forces the compiler to use 32 bits for the enumeration instead of 8 or 16.
Quote:Original post by Trentelshark
The basic idea behind the enumeration is this:
The core application (housed in a DLL) natively handles a number of object "types" (controllers) and will ignore those which are user defined. The idea behind the enumeration was to provide this to the user to show them that IDs x - y are used by the core application, and if they implement their own controllers that they need to begin setting their IDs at current value + 1. Beyond an enumeration I don't have a decent means of accomplishing this short of bolded font 72 in the included documentation.
A better design might be to have some "controller" interface class and then give them some way to "register" new controllers. If you need an identifier to distinguish the classes for some reason (often not required), you could use typeid() on the concrete class.
Author
Thanks for the ideas everyone it definitely gives me something to run with! This project has definitely given me a whole new perspective on the design process if nothing else :).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
