Re: [boost] Fix for old style for scoping (e.g. MSVC)

From: Thomas Witt (witt_at_[hidden])
Date: 2002-01-15 13:42:56

On Tuesday 15 January 2002 19:08, you wrote:
> 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?

No.

> - What would you do if you encountered code using this particular MSVC++
> bug in code review?

The code gets fixed. I had to do this anyway, as we used MSVC-win32/gcc-linux 
until recently.

> - Do you realize that *if* Microsoft fixes their compiler, you probably
> need to fix your code?

Yes

> - Do you realize that porting the code to some other compiler probably
> requires you to fix it?

Yes

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

This effect is undesirable to me. I think that the programmer should 
consciously deal with any compiler bug that affects his code. It should not 
be hidden by using a library unless the stated purpose of the library is to 
fix these bugs, i.e <boost/fix_my_compiler.hpp> would be fine.

The practical effect of your proposal would be to actually hide bugs. 
Removing any of boost headers from a cpp file can brake it. Try think about 
telling your colleague that the compiler behaves differently because he no 
longer includes <boost/math/octonion.hpp>. 

I think we cannot reasonably expect a boost include in every source file. 
Though at least in my case boost is making progress on this :-).

Thomas

>
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de