0

I have a new project where I cannot use boost::format. I get a compiler error complaining that boost's override of a virtual function, ~basic_altstringbuf, lacks a "throw()". Even the most trivial attempt to use boost::format does that.

I have other projects where it works fine. I have verified that the new project uses the same include-paths for boost, and for the VC++ includes. All the projects have "Enable C++ Exceptions" set to Yes. The only explanation I can come up with is that the projects that work have some #DEFINE or some setting that disables those vile exception specs in the std:: include-files. But I have no idea what or where it might be. Any ideas?

Error 1 error C2694: 'boost::io::basic_altstringbuf::~basic_altstringbuf(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<_Elem,_Traits>::~basic_streambuf(void) throw()

EDIT: Corollary question: Is there a Properties-item in VS++ 2012 that will cause the std:: header files to be included without exception-specs? - short of turning off exceptions, that is?

Jive Dadson
  • 16,680
  • 9
  • 52
  • 65
  • what version of Boost? Try the latest version? If it is the latest, file a bug at the boost Trac issue tracker, since the compiler detection apparently fails for VC++ 2012 – sehe Oct 06 '12 at 22:00
  • @sehe Boost version boost-1.51. It does not fail in another project that uses the same compiler. Both use v110. I am using the same boost include files for both, but just as a test, I tried using first include files from a boost that I compiled locally and second from one that I got pre-built off of the net. Same thing on both. Works for other projects, not for the new one. The new one must be different somehow, but I have no clue what that how might be. – Jive Dadson Oct 06 '12 at 22:54

2 Answers2

2

At the request of the original owner of the green check-mark, I am submitting this summary.

  1. The bugs are on the Microsoft side, in header-files for C++ standard library interfaces, and in the VC++ compiler when "Disable Language Extensions" is NOT set. The header files contain exception-specifications that the standard does not call for. When "language extensions" are not enabled, the compiler accepts invalid code. I have filed a bug report.

  2. Boost could work around the problem in this specific case by adding seven characters to a nested include-file, i.e. "throw()" at line 65 in alt_sstream_impl.hpp. I filed a report with boost also, although I made it clear that the bug is not in their code. I am just suggesting a workaround.

All the tedious details are in the two reports linked above.

Jive Dadson
  • 16,680
  • 9
  • 52
  • 65
  • Thanks for taking the effort to publish the effective answer. I hope you liked my change of the title :) – sehe Oct 08 '12 at 22:06
0

Check the preprocessor defines.

You might turn on and inspect verbose logging to see the exact flags that are passed to cl.exe

You could keep the preprocessed source and compare the version from the old (working) project with the new (failing) project.

My gut says, something else is being #defined/passed using -D in the old project that is not being defined in the new project, of differently (think of WINVER type macros)

See new answer posted: VC++ 2012 and Boost incompatibility - `throw()` specifications in library headers

EDIT by OP, Jive Dadson - It turned out to be /Za, which enables/disables "Microsoft language extensions." It is the contention of Visual Studio that the C++ standard requires that a program shall not compile if it has a virtual function override that is less restrictive in the "throw()" category than the function it overrides. Boost has a class that derives from basic_streambuf, and has a virtual destructor that lacks "throw()". The original destructor has that evil festoon. My new project will compile boost::format if I turn MS language extensions ON.

So the question becomes, who is wrong, and how? Is it standard-complying to put throw() on that destructor or not? Is the desired behavior (desired by me, that is) actually an "extension"? I seem to recall that MS considered some standard C++11 features to be "extensions," but I am not sure I remember correctly. Anyway, I will leave it to the boosters to decide, if they are interested. https://svn.boost.org/trac/boost/ticket/7477

Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • I went through the command lines already. I googled up a bunch of flags that were not familiar to me, but I did not see anything that looked like it could possibly be the culprit. Oh well. Onward through the fog! – Jive Dadson Oct 06 '12 at 23:09
  • The exception specification is definitely required to match in the override, [even for destructors](http://stackoverflow.com/questions/3233078/how-does-an-exception-specification-affect-virtual-destructor-overriding). – James McNellis Oct 07 '12 at 06:23
  • @James Then either MS or boost has errors in their header files. Does the standard say that ~basic_streambuf() is supposed to be decorated with throw()? That abomination is deprecated, finally. – Jive Dadson Oct 07 '12 at 11:26
  • @James I tracked it down. The bug is in the VC++ header file. The declaration for ~basic_streambuf() does not have a "throw()" exception-specifier. Section 27.6.3, C++11; Section 27.5.1 C++03. – Jive Dadson Oct 07 '12 at 12:10
  • @JiveDadson Great information. I'm not entirely sure anymore whether it was the /Za flag, or the headers, or the combination thereof? Perhaps you can post the summary as your own answer for future reference (and accept it). More people might run into this. – sehe Oct 07 '12 at 18:08
  • @James See the Answer I just submitted. – Jive Dadson Oct 07 '12 at 21:55
  • @sehe I did as you requested. Stackoverflow will not allow me to accept my own answer for 24 hours. – Jive Dadson Oct 07 '12 at 22:26