Boost logo

Boost :

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2002-01-15 13:08:28


From: "Thomas Witt" <witt_at_[hidden]>
> Hi Vesa,
> >On Tuesday 15 January 2002 17:52, you wrote:

> > At least the MSVC++ 6.x compiler implements 'for' incorrectly.
> >
> > There is a simple widely known workaround for this bug:
> >
> > #ifndef for
> > #define for if (0) {} else for
> > #endif
> >
> > The biggest undesirable side-effect is that it may brake some legacy
MSVC++
> > code that relies on the old incorrect behavior. On the other hand, such
> > code probably needs to be fixed sooner or later.
> >
> > Would this be worth adding to the MSVC++ config files?
>
> This is certainly a good point for something like a MSVC FAQ or it should be
> integrated in Jens MSVC deficiency list. With regard to the config files, I
> don't see how this would be kept from leaking to user code.

The idea was that it would be allowed to leak into user code.

It would be possible to disable the fix by defining:

    #define for for

before including boost code.

> As a library user
> I would really get pissed if any library forces something like this on me.
To
> me it feels to intrusive.

Yes. This is what I feared. A couple of questions:

- Do you use this particular MSVC++ feature/bug?
- What would you do if you encountered code using this particular MSVC++ bug
in code review?
- Do you realize that *if* Microsoft fixes their compiler, you probably need
to fix your code?
- Do you realize that porting the code to some other compiler probably
requires you to fix it?
- Which is the best solution in the long term:
  A) let unportable (in this case, relying on a particular compiler
feature/bug) code propagate
  B) not let unportable code propagate

Personally, I have incorporated this fix into our codebase about a year ago
and I've never heard a single complaint from my colleagues. I suggested this
fix here now, because one of my colleagues didn't know about the fix and asked
about it earlier today.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk