...

...

That is horribly inefficient: O(N). Yes, I warned :-). I was going to post another code equivalent to the one you posted (same complexity) this time, when I read you post.

Best regards, Pierre Morcello

Thanks for the replies... However I forgot to put in my question that I am looking for a macro and not template if possible, and for a solution as elegant as BOOST_FOREACH, where you have to code as less as possible. It not (only :) ) that I am lazy to write, but I think the resulting code would be easier to read. furthermore: 1. exception... throwing the exception removes the complexity of writing but introduces the complexity of exception (writing code + runtime). 2. pointer... use cases I would like to avoid pointers, as I have other constraints to work with const references. I was thinking all the day about this little "handicap" of the std::map. One way would be to have the concept of invalid object of the map data type that could be returned to satisfy the constraint of the reference, and a "horrible" function like bool return; const data_type & data = map.find(key, bool) if( return ) { //use the data } With this approach is that the "return" variable has to be declared. with the form I proposed BOOST_CONSTMAPFIND(aStringMap, "key", data) { processResult( data ); } the problem is that I do not know how to detect the type of data knowing in the map object. I thought for the moment that BOOST_FOREACH would "automatically" declare the type in the container (using non-standard typeof for eg), but revisiting again BOOST_FOREACH documentation i see that it declares the type. vector<int> v; BOOST_FOREACH( int i, v) etc. so it seems that if I declare the type of the data, my job becomes easy, a sort of "problem solved" const map<string, Mytype> & mymap = getMap(); //I changed the order of variables BOOST_CONSTMAPFIND(const Mytype &data, "key", mymap) { processResult(data); } and pair for non-const BOOST_MAPFIND(Mytype &data, "key", mymap) probably with some trick (probably sthg. similar used in BOOST_FOREACH), one could merge theh two macros. I am now two tired, but will write tomorrow the macro, test it, and would be happy if boost would accept it into the macros family. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com

at the end that is also not bad... It is still not clear for me how well for eg. gcc can optimize code generation if I would have such macros for like 100 types arround. In the worst case I would have extra 100 functions + extra overhead of function call. On Wed, Oct 21, 2009 at 1:04 AM, Steven Watanabe <watanabesj@gmail.com> wrote:

AMDG

mobi phil wrote:

...

I forgot to put in my question that I am looking for a macro and not template if possible, and for a solution as elegant as BOOST_FOREACH, where you have to code as less as possible. It not (only :) ) that I am lazy to write, but I think the resulting code would be easier to read.

furthermore: 1. exception... throwing the exception removes the complexity of writing but introduces the complexity of exception (writing code + runtime).

2. pointer... use cases I would like to avoid pointers, as I have other constraints to work with const references.

Why?  What's wrong with

if(const data_type* data = get_value(map, key)) {   processResult(*data); }

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- rgrds, mobi phil being mobile, but including technology http://mobiphil.com

mobi phil wrote:

I forgot to put in my question that I am looking for a macro and not template if possible, and for a solution as elegant as BOOST_FOREACH, where you have to code as less as possible. It not (only :) ) that I

How does a macro reduce the code you write? Your example is: BOOST_CONSTMAPFIND(aStringMap, "key", data) { processResult( data ); } My version was: data_type & data(get_value(aStringMap, "key")); processResult(data); Looking at your example here, it seems that you want this logic: if (find "key" in aStringMap) { // initialize data to reference the value for "key" processResult(data); } I had thought you wanted to assume that the value was always found. Given what I now understand, your macro would need to be something like this (ignoring necessary encapsulation details and not implementing the std::map to type mappings): #define BOOST_CONSTMAPFIND(_map, _key, _value) \ const_iterator_type_from(_map) const it(_map.find(_key)); typedef data_type_from(_map) data_type; data_type dummy; data_type * value(&dummy); data_type & _value(*value); if (it != _map.end()) { value = &it->second; }

furthermore: 1. exception... throwing the exception removes the complexity of writing but introduces the complexity of exception (writing code + runtime).

I had understood your initial use case to imply that you assumed the value was found. I didn't recognize that you meant the macro to be a conditional controlling the following block.

I was thinking all the day about this little "handicap" of the std::map. One way would be to have the concept of invalid object of the map data type that could be returned to satisfy the constraint of

Not all types have an unused value to indicate invalidity.

with the form I proposed

BOOST_CONSTMAPFIND(aStringMap, "key", data) { processResult( data ); }

the problem is that I do not know how to detect the type of data knowing in the map object. I thought for the moment that BOOST_FOREACH

That's the unimplemented part in my macro above.

would "automatically" declare the type in the container (using non-standard typeof for eg), but revisiting again BOOST_FOREACH documentation i see that it declares the type. vector<int> v; BOOST_FOREACH( int i, v) etc.

so it seems that if I declare the type of the data, my job becomes easy, a sort of "problem solved"

const map<string, Mytype> & mymap = getMap(); //I changed the order of variables BOOST_CONSTMAPFIND(const Mytype &data, "key", mymap) { processResult(data); }

You need the iterator type, too. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.