You are not logged in.

#1 2009-06-25 02:35:27

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,356

Suitable method for user-defined option list?

Hi all,

I'm doing research on computer vision, which obviously involves coding. My knowledge of C++ (my development language) is uneven, very heavy towards the topics which directly concern me for algorithm development and very light on the entire 'generic programming' and 'OO' stuff.

Anyway, I'm thinking of modifying my code-base to make maintenance easier, one of the things I'm looking at is providing a user-defined options list. For example, the user may want to code a module for my algorithm, which needs an option he wants to name 'width'. I already have a options class, and I'd prefer he adds his option there, but the current method I'm using (std::map of std::string and an enum) requires that he edits the options class to add his option there.

I was wondering whether there's some other container or method which allows the user to, within his class, call my options class and say something like "I want to have an option named 'width', with a value of 15", and there would exist an option called 'width' with the requisite value, which would then be accessible to any other class. Would std::map be useable for something of this nature?

I'm not sure how clear I am in this request. Please give suggestions, or ask questions if I've not been clear.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#2 2009-06-25 14:37:01

Trent
Member
From: Baltimore, MD (US)
Registered: 2009-04-16
Posts: 990

Re: Suitable method for user-defined option list?

I'm not sure what exactly you're looking for, but could your purposes be served by adding methods to your options class (e.g. setOption, getOption) which modify the map?  If not, how is your options class laid out?

Offline

#3 2009-06-26 00:03:01

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,356

Re: Suitable method for user-defined option list?

I currently have setters and getters for individual options. I'd like to simplify the class by making it sort of a 'home of all options' class, where any user (another researcher adding an algorithm) can perhaps call setoption(std::string name,*some datatype here*) and getoption(std::string name) would return that value. Probably, since return class cannot be overloaded, I'd have to have getoption<datatype>(std::string name) or get*datatype*option(..) for a hard-coded value?

I'd need different std::maps for each datatype then, as of now there are int and std::string options, but I foresee the need for perhaps a double datatype as well. Any container class can act as a map for all datatypes? Or do I have to use void pointers (urgh)?


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#4 2009-06-26 01:16:17

Trent
Member
From: Baltimore, MD (US)
Registered: 2009-04-16
Posts: 990

Re: Suitable method for user-defined option list?

Void pointers are the least intrusive solution I can see for your project.  I can't help much with implementation because my C++ is almost as bad as my Fortran (which is nonexistent), but it looks like you need a way to store an option of some arbitrary type and index it by a string, right?

In Java, which I am much more fluent with, it would be possible to make a map of String to Object and insert any kind of object as a value.  This wouldn't be a good solution, though, because you can't do much with an Object except cast it to another type.  The thoroughly OO approach might be to write an Option class which holds not only a reference to the object but also information about its type.  That sounds like a monstrocity to me, but maybe there are better solutions.

Come to think of it, consider that while *your* code doesn't necessarily know what kind of object to look for, the *user's* code presumably does, and can handle it accordingly.  I can think of two ways to exploit this fact:
(a) map strings to void pointers, which can refer to objects of arbitrary type
(b) map strings to strings, which contain string representations of objects
Choice (a) makes it easy to create an option by taking the address of the desired value, but if client code later modifies the value at that address, your option will change too.  I don't know of any way around this unless C++ perhaps offers an analog to Java's Object.clone().  Choice (b) avoids the possibility of user code inadvertently changing an option, but burdens the user with choosing and implementing a stringizing algorithm.

Perhaps some people who have actual experience with C++ can speak up and tell me what I have missed.

Offline

#5 2009-06-26 01:43:00

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,356

Re: Suitable method for user-defined option list?

Thanks, sounds pretty much like my thinking. And yes, Objects are convenient, though once you take the fact that it still needs to be casted into account, its basically just a void pointer to my way of thinking.

I'm currently looking at string to string mapping, which would shift the burden for interpretation to the user. I'm sure anyone comfortable with C++ can convert std::string to datatype and back... convenience is another issue though. As is the inadvertant "convert double to string and back to int" problems.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

Board footer

Powered by FluxBB