Re: [boost] Re : BOOST_FOREACH like macro for map

Subject: Re: [boost] Re : BOOST_FOREACH like macro for map
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-21 09:07:38

mobi phil wrote:

Please don't top post and don't overquote.

> 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.

Don't optimize until you know you need it.  Macro code makes for harder debugging and can lead to code bloat.  Whether the alternative is inlined or is a function call, and what effect those have on performance are subjects to investigate once a solution is available.

> On Wed, Oct 21, 2009 at 1:04 AM, Steven Watanabe
> <watanabesj_at_[hidden]> wrote:
> > mobi phil wrote:
> >>
> >> furthermore:
[snip]
> >> 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);
> > }

_____
Rob Stewart                           robert.stewart_at_[hidden]
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.