mapping strings to indexes at compile time - MPL map? - Boost-users

mapping strings to indexes at compile time - MPL map?

Paul Baxter

8 Dec 2005 8 Dec '05

2:34 p.m.

I have a fixed list of parameter names and with each an associated set of attributes. I wish to access the attributes via the parameter name rather than the equivalent list entry index. In the past, we've created ENUMs with meaningful names to represent the parameter name->index mapping but I can't help feeling there must be a better way usng the name directly without this extra artificial mapping type. Rather than access an attribute of a given parameter via a numerical index into an array of attribute structures or similar, I'd like to be able to use the name field directly. I would like the name->index mapping to happen at compile time so as not to include some run-time overhead. // Define a list of all allowable parameter names along with associated attributes .. // Not necessarily the required syntax unsigned config_offset = parameter["third parameter"].get_byte_offset(); I want a compile time error if "third parameter" isn't a valid name, and if it is valid, I want the code to reduce to parameter[3].get_byte_offset() which the compiler would further reduce to an inlined access to the right attribute. I've tried looking at the MPL map, but am having difficulty with the documentation though I confess part of this may be a lack of familiarity with meta template programming. Can anyone point me to the right area of Boost for doing this name->index mapping at compile time.

Show replies by date

David Abrahams

8 Dec 8 Dec

9:43 p.m.

New subject: mapping strings to indexes at compile time - MPL map?

"Paul Baxter" writes:

...

I have a fixed list of parameter names and with each an associated set of attributes. I wish to access the attributes via the parameter name rather than the equivalent list entry index.

In the past, we've created ENUMs with meaningful names to represent the parameter name->index mapping but I can't help feeling there must be a better way usng the name directly without this extra artificial mapping type.

Is there some reason http://www.boost.org/libs/parameter is not appropriate for you? -- Dave Abrahams Boost Consulting www.boost-consulting.com

Paul Baxter

10:34 p.m.

New subject: mapping strings to indexes at compile time - MPLmap?

...

"Paul Baxter" writes:

...
I have a fixed list of parameter names and with each an associated set of attributes. I wish to access the attributes via the parameter name rather than the equivalent list entry index.

In the past, we've created ENUMs with meaningful names to represent the parameter name->index mapping but I can't help feeling there must be a better way usng the name directly without this extra artificial mapping type.

Is there some reason http://www.boost.org/libs/parameter is not appropriate for you?

The parameter library looks like an incredibly useful library, I'm not sure it is what I'm looking for though, but am happy if you could give me an example. I'm looking for something that does the name->index 'lookup' at compile time. (Sorry if this fact wasn't made clearer). My initial reading of parameter is that it is solving a different problem. Each of my configurable classes defines a fixed list of parameter names and associated attributes known at compile time. Rather than accessing via parameter 'list position' 1, I'd like to access attributes of each parameter (such as parameter type, default value, min/max values) via the parameter's name, mainly from a readability and maintainability point of view. If I ever change the list to add/delete a parameter, the parameter 'access' code would require a recompile but pick up its new index automatically. I can't help feeling this should be easy to do and its frustrating that I can't find a way to achieve this other than the aforementioned enum. My application is a real-time high-speed one with hundreds (sometimes thousands) of configuration parameters. I need to interrogate these in a very short space of time which doesn't allow run-time assessment of strings for matching them. Since all are known at compile time I'm sure it must be easy to do this. I'm pretty sure when someone shows me the obvious solution I will be very embarrassed, but until then I can do this with a std::map at runtime, but not at compile time. Many thanks if anyone can help further. Paul

Paul Baxter

11:25 p.m.

New subject: mapping strings to indexes at compile time -MPLmap?

From: "Paul Baxter" Newsgroups: gmane.comp.lib.boost.user Sent: Thursday, December 08, 2005 10:34 PM Subject: Re: mapping strings to indexes at compile time -MPLmap?

...

...
"Paul Baxter" writes:

...
I have a fixed list of parameter names and with each an associated set of attributes. I wish to access the attributes via the parameter name rather than the equivalent list entry index.

In the past, we've created ENUMs with meaningful names to represent the parameter name->index mapping but I can't help feeling there must be a better way usng the name directly without this extra artificial mapping type.

Is there some reason http://www.boost.org/libs/parameter is not appropriate for you?

The parameter library looks like an incredibly useful library, I'm not sure it is what I'm looking for though, but am happy if you could give me an example. I'm looking for something that does the name->index 'lookup' at compile time. (Sorry if this fact wasn't made clearer). My initial reading of parameter is that it is solving a different problem.

Just to clarify, the parameter lib appears to do much of what it does at compile time, but I'm having a bit of difficulty mapping my concepts to parameter. Since Dave is rarely mistaken, I am trying to grapple with this further. I want a constant map with parameter names as key. These are associated with a tuple of pre-defined fixed attributes. I'm pretty sure much of the behind the scenes machinery that makes parameter work may be appropriate to this solution, but can't figure if the current machinery for parameter would help in its current form. Paul

David Abrahams

9 Dec 9 Dec

3:30 p.m.

New subject: mapping strings to indexes at compile time - MPLmap?

"Paul Baxter" writes:

...

...
"Paul Baxter" writes:

...
I have a fixed list of parameter names and with each an associated set of attributes. I wish to access the attributes via the parameter name rather than the equivalent list entry index.

In the past, we've created ENUMs with meaningful names to represent the parameter name->index mapping but I can't help feeling there must be a better way usng the name directly without this extra artificial mapping type.

Is there some reason http://www.boost.org/libs/parameter is not appropriate for you?

The parameter library looks like an incredibly useful library, I'm not sure it is what I'm looking for though, but am happy if you could give me an example. I'm looking for something that does the name->index 'lookup' at compile time.

The parameter library does compile-time lookups. args[third_parameter].get_byte_offset() is a possible syntax with the parameter library. The key to the compile-time lookup is that third_parameter is a different type from, e.g., second_parameter,

...

(Sorry if this fact wasn't made clearer). My initial reading of parameter is that it is solving a different problem.

Some facts: You can't use a string literal as a template parameter in C++, so there is *no way* to use a string literal as a key in a compile-time lookup. Your example, parameter["third parameter"].get_byte_offset(), goes through a function call (operator[]) to get a class object. That part is necessarily a runtime operation.

...

Each of my configurable classes defines a fixed list of parameter names and associated attributes known at compile time. Rather than accessing via parameter 'list position' 1, I'd like to access attributes of each parameter (such as parameter type, default value, min/max values) via the parameter's name, mainly from a readability and maintainability point of view.

Sounds like the parameter library to me... provided you give up using strings as indices.

...

If I ever change the list to add/delete a parameter, the parameter 'access' code would require a recompile but pick up its new index automatically.

Sounds like the parameter library to me...

...

I can't help feeling this should be easy to do and its frustrating that I can't find a way to achieve this other than the aforementioned enum.

My application is a real-time high-speed one with hundreds (sometimes thousands) of configuration parameters. I need to interrogate these in a very short space of time which doesn't allow run-time assessment of strings for matching them.

http://lists.boost.org/Archives/boost/2005/09/93343.php

...

Since all are known at compile time I'm sure it must be easy to do this. I'm pretty sure when someone shows me the obvious solution I will be very embarrassed, but until then I can do this with a std::map at runtime, but not at compile time.

I'm pretty sure the parameter library is a good -- if not perfect -- match for your problem. Since I've pointed at it twice now, if you're not embarrassed yet, I'll stop pushing ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com

Paul Baxter

10 Dec 10 Dec

11:45 p.m.

New subject: mapping strings to indexes at compile time -MPLmap?

Dave Abrahams wrote

...

Some facts:

You can't use a string literal as a template parameter in C++, so there is *no way* to use a string literal as a key in a compile-time lookup.

This is the piece of the puzzle I was needing and is the crux of the matter. I can't do what I want with strings directly on the interface. I was hopeful of some compile-time map or hashing function to convert the constant string to a constant index and work from there.

...

Sounds like the parameter library to me... provided you give up using strings as indices.

...

I'm pretty sure the parameter library is a good -- if not perfect -- match for your problem. Since I've pointed at it twice now, if you're not embarrassed yet, I'll stop pushing ;-)

I've already acknowledged my embarrassment in my previous post! Though parameter cannot solve my problem directly, I'll try to find another way without strings. Many thanks for your help. Paul

6927

Age (days ago)

6929

Last active (days ago)

List overview

Download

5 comments

2 participants

participants (2)

David Abrahams
Paul Baxter