Re: [boost] Patch bonanza for VS2013 Preview support

Subject: Re: [boost] Patch bonanza for VS2013 Preview support
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2013-07-24 14:07:56

[Niall Douglas]
> You've done well, though I have to say that so far at least the Preview
> feels slightly rough around the edges. For example, when working with Boost
> with all its available C++11 turned on, I'm seeing repeated errors from the
> linker of this form:
> fatal error C1128: number of sections exceeded object file format limit :
> compile with /bigobj
> ... and recompiling Boost with /bigobj for every compiland does indeed do
> the trick. This didn't happen with Nov 2012 CTP though.
> Have any other Boosters seen the same problem? Is /bigobj going to have to
> be made default on for all Boost?

According to my understanding, this happens when you emit more than 64k functions. The compiler really should enable /bigobj by default (or at least automagically) but for historical reasons it doesn't.

> I'm unclear why this is a C++14 issue. Nov 2012 CTP didn't have this
> problem.

I'd have to investigate to figure out exactly what happened, but we changed result_of between 2012 and 2013.

> I also think you haven't looked at the bug closely enough - I'm *not*
> calling result_of<> in the way you think.

Hmm. VC rejects this code:

C:\Temp>type purr.cpp
template <typename T> struct NoCharsAllowed {
    static_assert(sizeof(T) > 1, "No chars allowed!");
};

template <typename A> void purr(int, const A&);

template <typename B, typename... Types> typename NoCharsAllowed<B>::type purr(void *, const B&, Types...);

int main() {
    purr(1729, 'x');
}

C:\Temp>cl /EHsc /nologo /W4 /c purr.cpp
purr.cpp
purr.cpp(2) : error C2338: No chars allowed!
        purr.cpp(10) : see reference to class template instantiation 'NoCharsAllowed<char>' being compiled

However, GCC accepts it, contrary to my understanding of the Standard. My brain tells me that template argument deduction should run for the B overload even though it will ultimately be nonviable (because 1729 isn't convertible to void *). It also tells me that if it runs, the static_assert should really explode and not trigger SFINAE. Either GCC is wrong, or one of these parts of my mental model is wrong. I'll ask our compiler team. 

> AFIO by default uses the C++ standard library where possible, and Boost
> equivalents where not possible. The choice can be overridden at compile time
> of course.

Ok, that makes sense.

Thanks,
STL