Boost: Getting Started on Windows

Olivier Bertrand

26 Sep 2010 26 Sep '10

5:43 p.m.

Using this tutorial I tried to build the first sample with Windows Visual C++ 6.0. All seems correct in the settings, but the compilation failed with the following messages: --------------------Configuration: Sample - Win32 Debug-------------------- Compiling... Lambda.cpp c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration c:\boost_1_44\boost\mpl\aux_\yes_no.hpp(56) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe. Sample.exe - 3 error(s), 0 warning(s) The second sample gave me similar errors. I need help to be able to use the Boost libs...

Show replies by date

OvermindDL1

26 Sep 26 Sep

10:38 p.m.

On Sun, Sep 26, 2010 at 11:43 AM, Olivier Bertrand wrote:

...

Using this tutorial I tried to build the first sample with Windows Visual C++ 6.0.

All seems correct in the settings, but the compilation failed with the following messages:

--------------------Configuration: Sample - Win32 Debug-------------------- Compiling... Lambda.cpp c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration c:\boost_1_44\boost\mpl\aux_\yes_no.hpp(56) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe.

Sample.exe - 3 error(s), 0 warning(s)

The second sample gave me similar errors.

I need help to be able to use the Boost libs...

visual C++ 6.0 is inching toward 13 years old, there is not much nowadays that supports it, and I know many Boost sublibraries do not (although some still do), however, MPL I doubt is one that does due to its heavy template usage and VS6's lack of proper template support (although it 'might', anyone want to chime in?). You might try going back to an older Boost version, maybe 1.33 or so, when VC6 was still somewhat used. Personally, I would highly recommend at least downloading the free Visual Studio 2010 (or 2008) Express version to get upgraded to something more modern.

Joshua Boyce

10:48 p.m.

On Mon, Sep 27, 2010 at 8:38 AM, OvermindDL1 wrote:

...

On Sun, Sep 26, 2010 at 11:43 AM, Olivier Bertrand wrote:

...
Using this tutorial I tried to build the first sample with Windows Visual C++ 6.0.

All seems correct in the settings, but the compilation failed with the following messages:

--------------------Configuration: Sample - Win32 Debug-------------------- Compiling... Lambda.cpp c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration c:\boost_1_44\boost\mpl\aux_\yes_no.hpp(56) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe.

Sample.exe - 3 error(s), 0 warning(s)

The second sample gave me similar errors.

I need help to be able to use the Boost libs...

visual C++ 6.0 is inching toward 13 years old, there is not much nowadays that supports it, and I know many Boost sublibraries do not (although some still do), however, MPL I doubt is one that does due to its heavy template usage and VS6's lack of proper template support (although it 'might', anyone want to chime in?). You might try going back to an older Boost version, maybe 1.33 or so, when VC6 was still somewhat used.

Personally, I would highly recommend at least downloading the free Visual Studio 2010 (or 2008) Express version to get upgraded to something more modern. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Not sure how up to date this is, but it may be of interest: http://www.boost.org/doc/libs/1_44_0/libs/mpl/doc/tutorial/portability.html At any rate, stop using VC6. Seriously, it's awful.

Olivier Bertrand

10:54 p.m.

Ok, but when I have tried a free version of Visual studio 2008 (because the 6.0 version was not compatible with Vista) I realized that the program I developed with it did not work under XP!!! That is why I continue with Visual studio 6.0 with which I can develop programs that work on all Windows systems. Anyway, even I am not familiar with the use of namespace, I think it is a standard C++ feature so why should this be dependent on the compiler version? Le 27/09/2010 00:38, OvermindDL1 a écrit :

...

On Sun, Sep 26, 2010 at 11:43 AM, Olivier Bertrand wrote:

...
Using this tutorial I tried to build the first sample with Windows Visual C++ 6.0.

All seems correct in the settings, but the compilation failed with the following messages:

--------------------Configuration: Sample - Win32 Debug-------------------- Compiling... Lambda.cpp c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration c:\boost_1_44\boost\mpl\aux_\yes_no.hpp(56) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe.

Sample.exe - 3 error(s), 0 warning(s)

The second sample gave me similar errors.

I need help to be able to use the Boost libs... visual C++ 6.0 is inching toward 13 years old, there is not much nowadays that supports it, and I know many Boost sublibraries do not (although some still do), however, MPL I doubt is one that does due to its heavy template usage and VS6's lack of proper template support (although it 'might', anyone want to chime in?). You might try going back to an older Boost version, maybe 1.33 or so, when VC6 was still somewhat used.

Personally, I would highly recommend at least downloading the free Visual Studio 2010 (or 2008) Express version to get upgraded to something more modern. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Andrew Maclean

27 Sep 27 Sep

12:17 a.m.

The point is that that compiler is so old that namespaces were not properly implemented, from memory there were conflicts in the std:: namespace. As the other poster also indicated, template support was really poor and additionally there were bugs in the stl implementation. Essentially you are constrained to use a very old version of boost if you go down this path. Also be very careful about for loops, this version of visual studio was not standards compliant. The subtle issue here is that, in Visual Studio 6, variables declared in a for-loop were visible from the loop's enclosing scope, so it was quite possible to use the the variables outside the loop. e.g // count = 10; for (int i=0; ihttp://msdn.microsoft.com/en-us/library/ms235427.aspx and here: http://msdn.microsoft.com/en-us/library/ms177253.aspx Hope this helps. Regards Andrew On Mon, Sep 27, 2010 at 8:54 AM, Olivier Bertrand wrote:

...

Ok, but when I have tried a free version of Visual studio 2008 (because the 6.0 version was not compatible with Vista) I realized that the program I developed with it did not work under XP!!! That is why I continue with Visual studio 6.0 with which I can develop programs that work on all Windows systems.

Anyway, even I am not familiar with the use of namespace, I think it is a standard C++ feature so why should this be dependent on the compiler version?

Le 27/09/2010 00:38, OvermindDL1 a écrit :

...
On Sun, Sep 26, 2010 at 11:43 AM, Olivier Bertrand wrote:

...
Using this tutorial I tried to build the first sample with Windows Visual C++ 6.0.

All seems correct in the settings, but the compilation failed with the following messages:

--------------------Configuration: Sample - Win32 Debug-------------------- Compiling... Lambda.cpp c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration c:\boost_1_44\boost\mpl\aux_\yes_no.hpp(56) : fatal error C1506: unrecoverable block scoping error Error executing cl.exe.

Sample.exe - 3 error(s), 0 warning(s)

The second sample gave me similar errors.

I need help to be able to use the Boost libs...

visual C++ 6.0 is inching toward 13 years old, there is not much nowadays that supports it, and I know many Boost sublibraries do not (although some still do), however, MPL I doubt is one that does due to its heavy template usage and VS6's lack of proper template support (although it 'might', anyone want to chime in?). You might try going back to an older Boost version, maybe 1.33 or so, when VC6 was still somewhat used.

Personally, I would highly recommend at least downloading the free Visual Studio 2010 (or 2008) Express version to get upgraded to something more modern. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________

Dave Abrahams

12:19 a.m.

On Sep 26, 2010, at 6:54 PM, Olivier Bertrand wrote:

...

I am not familiar with the use of namespace, I think it is a standard C++ feature so why should this be dependent on the compiler version?

Because some compiler versions are lot closer to implementing the standard features correctly than others! BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device] --

OvermindDL1

5:29 a.m.

On Sun, Sep 26, 2010 at 4:54 PM, Olivier Bertrand wrote:

...

Ok, but when I have tried a free version of Visual studio 2008 (because the 6.0 version was not compatible with Vista) I realized that the program I developed with it did not work under XP!!! That is why I continue with Visual studio 6.0 with which I can develop programs that work on all Windows systems.

They support XP just fine (they should support Win2000 and higher just fine as I recall).

Dave Abrahams

26 Sep 26 Sep

11:56 p.m.

On Sep 26, 2010, at 6:38 PM, OvermindDL1 wrote:

...

visual C++ 6.0 is inching toward 13 years old, there is not much nowadays that supports it, and I know many Boost sublibraries do not (although some still do), however, MPL I doubt is one that does due to its heavy template usage and VS6's lack of proper template support (although it 'might', anyone want to chime in?).

Unless we've broken something, vc6 is supported by MPL. BoostPro Computing * http://boostpro.com [Sent from coveted but awkward mobile device] --

Daniel James

27 Sep 27 Sep

7:40 a.m.

On 26 September 2010 18:43, Olivier Bertrand wrote:

...

c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration

It looks like this change broke Boost.Config on VC6: https://svn.boost.org/trac/boost/changeset/61434 If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped. Daniel

Marsh Ray

30 Sep 30 Sep

9:11 p.m.

On 09/27/2010 02:40 AM, Daniel James wrote:

...

On 26 September 2010 18:43, Olivier Bertrand wrote:

...
c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration

It looks like this change broke Boost.Config on VC6:

https://svn.boost.org/trac/boost/changeset/61434

If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped.

As a long time Boost user (yes, even since the VC6 days) I suggest that Boost make an explicit policy change. Not only should VC6 be deprecated, not supported, and otherwise ignored in Boost, but all its vestigial compatibility workaround code should be actively ripped out! It's largely clutter at this point, and these breaks are evidence that it's poorly maintained and not used or tested much either. A dangerous breeding ground for bugs. This is when somebody raises their hand and says "But I need VC6 because it's the only way I can build something for these military embedded WinCE98 things we're still contractually obligated to support for another 13 years". We should all be very sympathetic, but that application should probably stay on the last Boost release that works for them. Just think how much fun it will be to grep for those VC6 macros and submit all those negative-LoC patches! - Marsh

Andrew Maclean

10:17 p.m.

Well said. VC6 has had it' s time. On Fri, Oct 1, 2010 at 7:11 AM, Marsh Ray wrote:

...

On 09/27/2010 02:40 AM, Daniel James wrote:

...
On 26 September 2010 18:43, Olivier Bertrand wrote:

...
c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration

It looks like this change broke Boost.Config on VC6:

https://svn.boost.org/trac/boost/changeset/61434

If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped.

As a long time Boost user (yes, even since the VC6 days) I suggest that Boost make an explicit policy change.

Not only should VC6 be deprecated, not supported, and otherwise ignored in Boost, but all its vestigial compatibility workaround code should be actively ripped out!

It's largely clutter at this point, and these breaks are evidence that it's poorly maintained and not used or tested much either. A dangerous breeding ground for bugs.

This is when somebody raises their hand and says "But I need VC6 because it's the only way I can build something for these military embedded WinCE98 things we're still contractually obligated to support for another 13 years". We should all be very sympathetic, but that application should probably stay on the last Boost release that works for them.

Just think how much fun it will be to grep for those VC6 macros and submit all those negative-LoC patches!

- Marsh

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

OvermindDL1

2 Oct 2 Oct

2:15 a.m.

On Thu, Sep 30, 2010 at 3:11 PM, Marsh Ray wrote:

...

On 09/27/2010 02:40 AM, Daniel James wrote:

...
On 26 September 2010 18:43, Olivier Bertrand wrote:

...
c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration

It looks like this change broke Boost.Config on VC6:

https://svn.boost.org/trac/boost/changeset/61434

If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped.

As a long time Boost user (yes, even since the VC6 days) I suggest that Boost make an explicit policy change.

Not only should VC6 be deprecated, not supported, and otherwise ignored in Boost, but all its vestigial compatibility workaround code should be actively ripped out!

It's largely clutter at this point, and these breaks are evidence that it's poorly maintained and not used or tested much either. A dangerous breeding ground for bugs.

This is when somebody raises their hand and says "But I need VC6 because it's the only way I can build something for these military embedded WinCE98 things we're still contractually obligated to support for another 13 years". We should all be very sympathetic, but that application should probably stay on the last Boost release that works for them.

Just think how much fun it will be to grep for those VC6 macros and submit all those negative-LoC patches!

Also speaking as a user of Boost since using VC6, +1 VC6 was such a horrible system, so much code could be cleaned up if its support were stripped out.

Damien Hocking

2:27 a.m.

On 01/10/2010 8:15 PM, OvermindDL1 wrote:

...

On Thu, Sep 30, 2010 at 3:11 PM, Marsh Ray wrote:

...
On 09/27/2010 02:40 AM, Daniel James wrote:

...
On 26 September 2010 18:43, Olivier Bertrand wrote:

...
c:\boost_1_44\boost\config\suffix.hpp(588) : error C2039: 'typeinfo' : is not a member of '`global namespace'' c:\boost_1_44\boost\config\suffix.hpp(588) : error C2873: 'typeinfo' : symbol cannot be used in a using-declaration It looks like this change broke Boost.Config on VC6:

https://svn.boost.org/trac/boost/changeset/61434

If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped. As a long time Boost user (yes, even since the VC6 days) I suggest that Boost make an explicit policy change.

Not only should VC6 be deprecated, not supported, and otherwise ignored in Boost, but all its vestigial compatibility workaround code should be actively ripped out!

It's largely clutter at this point, and these breaks are evidence that it's poorly maintained and not used or tested much either. A dangerous breeding ground for bugs.

This is when somebody raises their hand and says "But I need VC6 because it's the only way I can build something for these military embedded WinCE98 things we're still contractually obligated to support for another 13 years". We should all be very sympathetic, but that application should probably stay on the last Boost release that works for them.

Just think how much fun it will be to grep for those VC6 macros and submit all those negative-LoC patches! Also speaking as a user of Boost since using VC6, +1 VC6 was such a horrible system, so much code could be cleaned up if its support were stripped out.

From experience with other C++ projects that required long-term support, dropping VC6 removed a lot of nasty special-case code. It supported writing broken C++. VC6 is now 12 years old, and the updated, compliant Visual Studio Express is free for the 32-bit Windows platform and VC6 never did 64-bit anyway. +1 to dropping it. Damien

Marsh Ray

5:25 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

...
...
On 09/27/2010 02:40 AM, Daniel James wrote:

...
On 26 September 2010 18:43, Olivier Bertrand wrote: It looks like this change broke Boost.Config on VC6:

https://svn.boost.org/trac/boost/changeset/61434

If that's true then very little of Boost 1.44 will work on that compiler, since almost everything depends on the config headers. Is it worth fixing? Something like this was inevitable once testing stopped.

Looks like that change was made 5 months ago and nobody noticed until now.

...

...
On Thu, Sep 30, 2010 at 3:11 PM, Marsh Ray wrote:

...
As a long time Boost user (yes, even since the VC6 days) I suggest that Boost make an explicit policy change.

Not only should VC6 be deprecated, not supported, and otherwise ignored in Boost, but all its vestigial compatibility workaround code should be actively ripped out!

It's largely clutter at this point, and these breaks are evidence that it's poorly maintained and not used or tested much either. A dangerous breeding ground for bugs.

This is when somebody raises their hand and says "But I need VC6 because it's the only way I can build something for these military embedded WinCE98 things we're still contractually obligated to support for another 13 years". We should all be very sympathetic, but that application should probably stay on the last Boost release that works for them.

Just think how much fun it will be to grep for those VC6 macros and submit all those negative-LoC patches!

...

On 01/10/2010 8:15 PM, OvermindDL1 wrote:

...
Also speaking as a user of Boost since using VC6, +1 VC6 was such a horrible system, so much code could be cleaned up if its support were stripped out.

Now, we needn't speak ill of the dead. VC6 was great in a lot of ways, e.g., compared to what came before it. However, the fact that MS has completely stopped supporting it means that security bugs in some of the runtime libs may not be getting patches. To continue to support the use of such a product could be complicit in producing insecure systems. On 10/01/2010 09:27 PM, Damien Hocking wrote:

...

From experience with other C++ projects that required long-term support, dropping VC6 removed a lot of nasty special-case code. It supported writing broken C++. VC6 is now 12 years old, and the updated, compliant Visual Studio Express is free for the 32-bit Windows platform and VC6 never did 64-bit anyway.

The platform SDK compiler is sometimes pretty decent, too.

...

+1 to dropping it.

Well, this thread is on the users' list. I would think that the developers on the codebase would like this more than anybody. As a developer on (other stuff) myself, I also know how reluctant I am to take away any functionality at all that some user somewhere may be depending on, at least without a good reason. So one tends to error on the side of not changing anything, lest you have no justification for the occasional minor accidental build bug. It may be that all they need is a representative group of users to make a clear statement of preference. Not a demand or anything, just "preemptively endorsing" an easy improvement they've probably been wanting to do anyway. With users on board, it could just be a Boost code policy statement to empower developers to remove the VC6-specific cruft as the opportunity arises. I find that the dead stuff obscures and distracts from the relevant stuff and sometimes makes it a little harder to figure out what's going on. Troubleshooting some of these type system errors leaves me with little brainpower to spare! If the code doesn't get a little spring cleaning once in a while, the dead wood will just builds up more and more over time. A codebase as big as Boost could probably have a ongoing minor project for dusting and vacuuming. Heck, maybe there's some magic preprocessor that can do much of it automatically. Of course, if anyone has a real objection (perhaps unlikely at this point) they can share it here. Let's collect simple "+1"s from the user community on this thread and then ask nicely on the dev list. - Marsh

Joshua Boyce

6:28 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

Diederick C. Niehorster

8:45 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1 to dropping VC6 support On Sat, Oct 2, 2010 at 13:25, Marsh Ray wrote:

...

If the code doesn't get a little spring cleaning once in a while, the dead wood will just builds up more and more over time. A codebase as big as Boost could probably have a ongoing minor project for dusting and vacuuming. Heck, maybe there's some magic preprocessor that can do much of it automatically.

As cleaning would be done anyway, is there support for other very old compilers or versions of compilers that might be dropped? Best, Dee

michi7x7

9:39 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

Let's collect simple "+1"s from the user community on this thread and then ask nicely on the dev list. Hi,

many boost-libraries dropped VC6-support anyway. +1 Regards, michi7x7

Jens Weller

9:59 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1 Even if its still in use in some very old projects, its time to move on and leave the antique C++ compilers behind. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Roland Bock

12:21 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On 10/02/2010 07:25 AM, Marsh Ray wrote:

...

Of course, if anyone has a real objection (perhaps unlikely at this point) they can share it here.

Let's collect simple "+1"s from the user community on this thread and then ask nicely on the dev list.

+1 People using such an old compiler should not expect expect freshly released libraries to be compatible anymore, IMO

John Wilkinson

2:34 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

Let's collect simple "+1"s from the user community on this thread and then ask nicely on the dev list.

+1 (Take it out, take it out, remooooooove it.... :-) ) This e-mail message and any attachment(s) transmitted with it are intended only for the use of the recipient(s) named above.This message may be privileged and/or confidential. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message.

Ian Bruntlett

3:52 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1 as well -- -- ACCU - Professionalism in programming - http://www.accu.org/

PB

3 Oct 3 Oct

6:13 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1. I can't ever see I'm need VC6 support.

Robert Jones

7:19 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1 too.

Damien Hocking

7:34 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

Hehehe. If this was the Coliseum there'd be a lot of thumbs pointing downward right now... Damien On 03/10/2010 1:19 PM, Robert Jones wrote:

...

+1 too.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Robert Ramey

9:41 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

Damien Hocking wrote:

...

Hehehe. If this was the Coliseum there'd be a lot of thumbs pointing downward right now...

Damien

On 03/10/2010 1:19 PM, Robert Jones wrote: +1 too.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Robert Ramey

9:52 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

Damien Hocking wrote:

...

Hehehe. If this was the Coliseum there'd be a lot of thumbs pointing downward right now...

Hmmm - I don't see any of the combatents with a thumb down. Undertaking such an effort is a lot more work than first meets the eye. It means going through the code line by line and likely breaking a lot of arcane stuff. This is due the fact that in many cases something like #if MSVC_VERSION < 7.0 ... #else ... #endf Really is a substitute for #idef "COMPILER_MISFEATURE_X... ... And a lot of compilers have implmented the misfeature so that they're stuff is compatible with microsoft. So one might well break a bunch of stuff with out knowing it. Also a lot of boost code relies on ambiguously defined language features. Sorting out all this and making one's code work accross all the combinations is and incredibly time consuming job. Way beyond what anyone who hasn't done it can imagine. (Aside - the single most important piece of code in boost is john maddocks "config" without which none of this would be possible). We already spend huge amounts of time dealing with things like visibility, dll compatibility, differing standard library implementations, etc. So, this would entail much more effort than meets the eye and with no real benefit. -1 Robert Ramey

David Abrahams

9:20 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

At Sun, 3 Oct 2010 13:52:05 -0800, Robert Ramey wrote:

...

a lot of boost code relies on ambiguously defined language features.

I disagree with that characterization. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Robert Jones

4 Oct 4 Oct

8:04 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On Sun, Oct 3, 2010 at 10:52 PM, Robert Ramey wrote:

...

So, this would entail much more effort than meets the eye and with no real benefit.

-1

I am in no sense an expert on this, and absolutely yield the floor to those who know far more about it than I do, but isn't the whole point to do what requires least effort? In voting to remove MSVC6 support I'm expressing the sentiment that I see little need to maintain it, but if maintaining it is the easier route then I see no objection IN PRINCIPLE to doing so, beyond a general feeling that a leaner codebase is better than a bloated one. Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it? Just my $0.02 worth. - Rob.

John Maddock

8:20 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-) John.

Marsh Ray

1:56 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On 10/04/2010 03:20 AM, John Maddock wrote:

...

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

I see a lot of '+1's here, and here I'll add my own: +1 with the intent that this can enable a change, but not a bunch of new work. Certainly there are cases where the old VC6 support is deeply intermixed with good code such that it would be too much work to be worth changing just on the principle of tidiness. The idea is that if a Boost developer happens to be working in a source file and comes across a block of VC6 workaround code that he'd really like to whack, he can just go ahead and whack it knowing he has the full support of the users behind him. - Marsh

Patrick Loney

2:38 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1 - We still develop with VC6 :( but that shouldn't hold back or slow down the development of boost; if we need to use any boost libraries we can carry on using old versions, if we need a new piece of functionality we can upgrade our compiler or roll our own.

Robert Ramey

4:18 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdefBOOST_MSVC6_* workarounds?

Marsh Ray wrote:

...

On 10/04/2010 03:20 AM, John Maddock wrote: The idea is that if a Boost developer happens to be working in a source file and comes across a block of VC6 workaround code that he'd really like to whack, he can just go ahead and whack it knowing he has the full support of the users behind him.

That's exactly what's happening at least in my case. MSVC 6.0 isn't being tested anymore. So any change I make is likely to break it. I seriously doubt that the current serialization library would compile with this compiler. With Borland, I don't have a borland compiler, but even though it's being tested, I couldn't maintain compatibility and anyway it's not worth it. If someone wanted to suggest changes (and run tests) to maintain support for these compilers, I would be willing to roll them in - but I'm not spending my own time on this. Basically, I respond to "market" demand. The problem with this is that since the "product" isn't sold I have no way to gauge this demand other than these lists. This is a large part of the motivation behind the proposal I presented at BoostCon this year. Robert Ramey PS. I think I may have misunderstand the original proposal. If its to strip out compatibility code for these compilers my vote would be -1 If it would be to just stop investing effort in maintaining compatibility - which is the current policy - I would vote +1 RR

Damien Hocking

3:38 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdefBOOST_MSVC6_* workarounds?

...

Robert Ramey

PS. I think I may have misunderstand the original proposal.

If its to strip out compatibility code for these compilers my vote would be -1

If it would be to just stop investing effort in maintaining compatibility - which is the current policy - I would vote +1

RR

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

As with all software, anything not actively maintained eventually fades away. If devs stop supporting it, the various VC6-specific sections will gradually move out of the tree as part of the development process. That's less work and less likely to accidentally break something critical than an active purge. Damien

Paul A. Bristow

5:51 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?) The risks of removing are not worth the effort. (And whoever suggested it would be fun needs to get out more ;-) Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

Marshall Clow

6:36 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On Oct 4, 2010, at 10:51 AM, Paul A. Bristow wrote:

...

...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?)

The risks of removing are not worth the effort.

I disagree. I'm confident that there are places where removing VC6 support is more trouble than it is worth. I'm _also_ confident that there are places where removing VC6 will lead to simpler, easier to maintain code. So, I guess my vote is a '0' - I think that the library maintainers should decide for their own library(ies). [ FWIW, I think that removing VC6-specific code is, in the abstract, a good idea. ]

...

(And whoever suggested it would be fun needs to get out more ;-)

That's a completely different discussion ;-) -- Marshall

Louis Lavery

5 Oct 5 Oct

7:10 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On 04/10/2010 19:36, Marshall Clow wrote:

...

On Oct 4, 2010, at 10:51 AM, Paul A. Bristow wrote:

...
...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?)

The risks of removing are not worth the effort.

I disagree.

I agree with you. If it's difficult to remove the MSVC6 specific code then, by definition, the code is difficult to maintain. It's better to learn from mistakes than to ignore them, you don't want to repeat them, do you? Louis.

Paul A. Bristow

9:02 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Louis Lavery Sent: Tuesday, October 05, 2010 8:11 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On 04/10/2010 19:36, Marshall Clow wrote:

...
On Oct 4, 2010, at 10:51 AM, Paul A. Bristow wrote:

...
...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?)

The risks of removing are not worth the effort.

I didn't make clear that I opposed removal of VC6 stuff from Boost *'global'* config. I meant that individual authors should remain free to do what they judge best for their library to cater for VC6, if anything. If they want to remove VC6 specific stuff, they can, or they can ignore VC6 - as many new libraries do. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

Rune Lund Olesen

9:16 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

But would you still be spending time on changing the code for the sake of removing MSVC6 ? +1 * -1 = -1 It might be more productive to get rid of the MSVC6 when you are changing the code anyways for another reason. So I guess it would be helpfull if boost made some sort of "vision statement" for which compilers boost are aiming to support in new development (and to a lesser extent which compilers are _not_ supportet in future, and which compilers are not aimed to get supportet but still could work) Rune On Tue, Oct 5, 2010 at 9:10 AM, Louis Lavery wrote:

...

On 04/10/2010 19:36, Marshall Clow wrote:

...
On Oct 4, 2010, at 10:51 AM, Paul A. Bristow wrote:

...
...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?)

The risks of removing are not worth the effort.

I disagree.

I agree with you.

If it's difficult to remove the MSVC6 specific code then, by definition, the code is difficult to maintain. It's better to learn from mistakes than to ignore them, you don't want to repeat them, do you?

Louis.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Edward Diener

4 Oct 4 Oct

7:52 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

On 10/4/2010 1:51 PM, Paul A. Bristow wrote:

...

...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?)

The risks of removing are not worth the effort.

(And whoever suggested it would be fun needs to get out more ;-)

I think that you are minimizing the fact that removing workaround code for an implementation which is no longer supported may make understanding code easier for maintainers.

Frank Mori Hess

8:01 p.m.

New subject: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 04 October 2010, Paul A. Bristow wrote:

...

...
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Maddock Sent: Monday, October 04, 2010 9:21 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...
Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

LOL, I suspect that's the current situation ;-)

Agree - so let's just leave the code as is (perhaps adding a stronger "you're entirely on your own with VC6" rider?)

Just curious, where is support for MSVC6 support advertised by Boost? And where do we state authors are required to support it? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkyqMnwACgkQ5vihyNWuA4WOgACgrbdmVQyo7aSI8nw0A1wbB658 DgIAoMBLKnXFdv2uGFZ7I4coqV7Kq8ke =B26l -----END PGP SIGNATURE-----

michi7x7

1:01 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

Is there a 'do nothing' option here? Ie., leave the codebase unchanged but no longer declare MSVC6 support, and so no longer require authors to support it?

Hi, Yeah, that's exactly what IMO most of us "+1" here are saying. There is no need to remove this hacky code, as it will bisabled by Preprocessor, but future versions don't need to support those old compilers, which makes writing it a lot easier. If the support is dropped, those - then deprecated - parts of code might be deleted from version to version, just due to rewriting and improving... Regards, michi7x7

Attila Feher F

7:08 a.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

+1 RIP MS-VC6

John Dlugosz

3:48 p.m.

New subject: Users! Who'd like to wave goodbye to #ifdef BOOST_MSVC6_* workarounds?

...

I find that the dead stuff obscures and distracts from the relevant stuff and sometimes makes it a little harder to figure out what's going on. Troubleshooting some of these type system errors leaves me with little brainpower to spare!

If the code doesn't get a little spring cleaning once in a while, the dead wood will just builds up more and more over time. A codebase as big as Boost could probably have a ongoing minor project for dusting and vacuuming. Heck, maybe there's some magic preprocessor that can do much of it automatically.

Of course, if anyone has a real objection (perhaps unlikely at this point) they can share it here.

Let's collect simple "+1"s from the user community on this thread and then ask nicely on the dev list.

I agree. Maintainers of old code who need to make a patch will be working with the existing versions and will not about to update a major library! TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

5150

Age (days ago)

5159

Last active (days ago)

List overview

Download

42 comments

28 participants

participants (28)

Andrew Maclean
Attila Feher F
Damien Hocking
Daniel James
Dave Abrahams
David Abrahams
Diederick C. Niehorster
Edward Diener
Frank Mori Hess
Ian Bruntlett
Jens Weller
John Dlugosz
John Maddock
John Wilkinson
Joshua Boyce
Louis Lavery
Marsh Ray
Marshall Clow
michi7x7
Olivier Bertrand
OvermindDL1
Patrick Loney
Paul A. Bristow
PB
Robert Jones
Robert Ramey
Roland Bock
Rune Lund Olesen