On 09/13/2013 06:10 PM, John Maddock wrote:

...

Something else that would allow progress would be dropping MPW support and increasing the SunPro requirement to 5.3 or later.

That would allow the removal of the BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION macro.

That sounds sensible, anything that still doesn't support that should be considered terminally broken IMO.

I agree. In order for progress to be non-zero, I need an svn account. I emailed boost-owner to ask for one last week and didn't get any response or acknowledgement of receipt. What is the normal waiting time for account activation? Thanks, Steve.

On 09/25/2013 03:20 PM, Stephen Kelly wrote:

On 09/13/2013 06:10 PM, John Maddock wrote:

...

...

Something else that would allow progress would be dropping MPW support and increasing the SunPro requirement to 5.3 or later.

That would allow the removal of the BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION macro. That sounds sensible, anything that still doesn't support that should be considered terminally broken IMO. Hello,

Please review the attached patch. From the commit message:

Drop support for some ancient compilers.

The MPW one is replaced by Xcode:

http://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop

SunPro prior to 0x530 does not support partial template specializations.

As John already said that compilers without partial template specializations should be considered terminally broken from a current boost POV, I'll commit theses parts of the patch tomorrow unless there are objections before then. Are there any other features, the lack of which would make a compiler terminally broken? BOOST_NO_SFINAE, perhaps?

It is not clear what compilers define __BORLANDC__. According to

http://en.wikipedia.org/wiki/C%2B%2BBuilder#Version_history

0x6xx may have been released in 2002. Bump the requirement to 0x610, as most of the ifdefs in boost are < 600. The strange part is that boost config issues an unconditional error if > 0x613, and yet parts of boost check for version 0x620 (boost::bind) and 0x630. This compiler may be untested for a long time.

I'm still confused about Borland. The config file for it makes reference to Borland 2008 and Borland 6. There were no objections to the suggestion to drop support for Borland 5.x. http://www.boost.org/users/news/old_compilers.html What should I set the minimum version of __BORLANDC__ to? Does anyone on this list actually have a Borland compiler (especially a non-ancient one) for testing? As far as I know, Borland is succeeded by Codegear. There seems to be 2008, 2009 and 2010 versions of that compiler. As that succeeds Borland, does it define __BORLANDC__ ? If not, and if we can drop Borland entirely, I can drop a lot of ifdefed-for-__BORLANDC__-code. Does anyone on this list actually have a codegear compiler for testing?

MetroWerks is probably obsolete. Change the requirement to the latest known version.

Any information about this one? There is a lot of workarounds for this one too. Does anyone have one of these compilers for testing? Thanks, Steve.

On 09/26/2013 10:49 PM, Peter Dimov wrote:

current Borland compiler (now by Embarcadero)

Do you have any idea what the current version is? Do you have any idea what __BORLANDC__ it defines? Thanks, Steve.

On 09/26/2013 10:56 PM, Stephen Kelly wrote:

Do you have any idea what the current version is? Do you have any idea what __BORLANDC__ it defines?

http://docwiki.embarcadero.com/RADStudio/XE5/en/Predefined_Macros#C.2B.2B_Co...

On 09/27/2013 01:12 PM, Stephen Kelly wrote:

Does anyone have any of those compilers? What is the reported _MSC_VER for those compilers?

Some url hacking got me to the earliest XE version: http://docwiki.embarcadero.com/RADStudio/XE/en/Predefined_Macros#C.2B.2B_Com... and a search got me to the C++ Builder 2010 page http://docwiki.embarcadero.com/RADStudio/2010/en/Predefined_Macros None of them document a _MSC_VER macro at all. However, http://docwiki.embarcadero.com/RADStudio/2009/en/Predefined_Macros is a 404. Searching for _MSC_VER on that site gives no results. http://docwiki.embarcadero.com/RADStudio/XE5/en/BCC32.EXE,_the_C%2B%2B_32-bi... does not mention _MSC_VER at all, and http://docwiki.embarcadero.com/RADStudio/XE/en/C%2B%2B_Compiler_Option_Chang... and other urls for other XE versions do not mention it as a value changed in the release. Can I conclude that for codegear, there is no _MSC_VER defined? Thanks, Steve.

On 27 September 2013 12:12, Stephen Kelly wrote:

So, if looks like requiring a minimum value for __BORLANDC__ of 0x610, as I have in the patch I posted, is reasonable, right?

No. Someone's still using an older version and I don't see any good reason to stop them. The question is not, "why should we continue to allow an old compiler?", it's "why shouldn't we?".

On 09/26/2013 11:01 PM, Glen Fernandes wrote:

On Fri, Sep 27, 2013 at 6:49 AM, Peter Dimov wrote:

...

Stephen Kelly wrote:

...

Does anyone on this list actually have a Borland compiler (especially a non-ancient one) for testing?

No. I do occasionally get bug reports when some change breaks the current Borland compiler (now by Embarcadero) though. So people are still using it, at least for shared_ptr. But we don't have a tester.

I have Embarcadero C++Builder XE4 (and XE3) that I use for the 64-bit compiler (which is a working clang 3.x on Windows). On vacation now, but when I get back to Redmond next week I could help test with it.

Thanks! I'm particularly interested in whether it still defines __BORLANDC__.

...

I have Embarcadero C++Builder XE4 (and XE3) that I use for the 64-bit compiler (which is a working clang 3.x on Windows). On vacation now, but when I get back to Redmond next week I could help test with it.

Thanks! I'm particularly interested in whether it still defines __BORLANDC__.

I would expect so, certainly the original codegear releases all defined __BORLANDC__. The __BORLANDC__ version numbers were all over the place as well (they went backwards at least one point, maybe more - don't ask me when!). John.

On 25 September 2013 14:20, Stephen Kelly wrote:

It is not clear what compilers define __BORLANDC__. According to

http://en.wikipedia.org/wiki/C%2B%2BBuilder#Version_history

0x6xx may have been released in 2002. Bump the requirement to 0x610, as most of the ifdefs in boost are < 600. The strange part is that boost config issues an unconditional error if > 0x613, and yet parts of boost check for version 0x620 (boost::bind) and 0x630. This compiler may be untested for a long time.

The Borland compiler versions aren't the same as the C++ Builder versions, Version 6 of the compiler is a lot later. I had an email (this morning) from someone who's still using 5.93. Later versions are handled by the Codegear config file, which is why that error is never triggered. Whichever way, I don't think we should make these changes until after the next release, they can't be merged to release until then, and it's a problem to have significant changes in trunk and release in core libraries.

On 09/26/2013 10:47 PM, Daniel James wrote:

On 25 September 2013 14:20, Stephen Kelly wrote:

...

It is not clear what compilers define __BORLANDC__. According to

http://en.wikipedia.org/wiki/C%2B%2BBuilder#Version_history

0x6xx may have been released in 2002. Bump the requirement to 0x610, as most of the ifdefs in boost are < 600. The strange part is that boost config issues an unconditional error if > 0x613, and yet parts of boost check for version 0x620 (boost::bind) and 0x630. This compiler may be untested for a long time. The Borland compiler versions aren't the same as the C++ Builder versions, Version 6 of the compiler is a lot later. I had an email (this morning) from someone who's still using 5.93.

Any idea when 5.93 was released? Is it ancient? What about the concept that people using ancient compilers can use ancient boost? I guess that's not consensus...

Later versions are handled by the Codegear config file, which is why that error is never triggered.

Ok, I see. There is also this in select_compiler_config.hpp #elif defined __CODEGEARC__ // CodeGear - must be checked for before Borland #elif defined __BORLANDC__ So, presumably CodeGear defines __BORLANDC__? Can anyone confirm that? Is it always defined to the same value as __CODEGEARC__?

Whichever way, I don't think we should make these changes until after the next release, they can't be merged to release until then, and it's a problem to have significant changes in trunk and release in core libraries.

Ok. The discussion can happen independent of patches. Thanks, Steve.

On 09/26/2013 11:02 PM, Daniel James wrote:

...

The Borland compiler versions aren't the same as the C++ Builder versions, Version 6 of the compiler is a lot later. I had an email (this morning) from someone who's still using 5.93. Later versions are handled by the Codegear config file, which is why that error is never triggered. I really should have posted a summary of the emails I received by now. There were 5 in total, none of them gave me permission to forward to

On 26 September 2013 21:47, Daniel James wrote: the list. Text in brackets is my commentary.

One said "Yes, please".

'Yes please' to what? Keeping Borland 5.93 working with trunk? Or some earlier Borland version?

One is still using codegear/borland c++ 5.93, which is c++ builder 2007.

That's interesting, but confusing. http://en.wikipedia.org/wiki/C%2B%2BBuilder#Version_history says that the version released in 2007 was released by CodeGear. Any idea what's going on there? Thanks, Steve.

according to page 22 of http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pd... Sun Studio 11 is the oldest Studio version actively supported by Oracle and even that one's support ends soonish - January 2014, so perhaps the SunPro req. could be bumped even higher? hajma 2013/9/13 Stephen Kelly

On 09/13/2013 01:45 PM, Stephen Kelly wrote:

...

Hello,

In the work I've done so far on removing ifdefs for obsolete compilers, some compilers which have come up a few times are __BORLANDC__ and __MWERKS__.

I have never used either of those compilers. Can old versions of either of them be dropped at this point in boost trunk?

Something else that would allow progress would be dropping MPW support and increasing the SunPro requirement to 5.3 or later.

That would allow the removal of the BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION macro.

Thanks,

Steve.

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

On 09/27/2013 01:02 PM, Stephen Kelly wrote:

Yes, Sun Studio 11 may be a reasonable one to bump the support to.

Does that define __SUNPRO_CC? To what? The most recent value known to the boost/config/compiler/sunpro_cc.hpp is 0x590.

I found http://docs.oracle.com/cd/E19422-01/819-3690/819-3690.pdf which documents the value of __SUNPRO_CC as 0x580. So, can I bump the requirement to that in sunpro_cc.hpp? Thanks, Steve.

On 27 September 2013 08:05, Pavel Heimlich, a.k.a. hajma wrote:

according to page 22 of http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pd... Sun Studio 11 is the oldest Studio version actively supported by Oracle and even that one's support ends soonish - January 2014, so perhaps the SunPro req. could be bumped even higher?

What Oracle chooses to support is irrelevant. What matters is what boost developers are willing to support, and what boost users wish to use.