Re: [boost] Patch bonanza for VS2013 Preview support

Subject: Re: [boost] Patch bonanza for VS2013 Preview support
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-07-25 11:21:47

> 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 certainly can see that a C++11 standard library when combined with Boost
might just exceed that limit regularly.

I might add that seeing as VS2012 doesn't output binaries which will execute
on pre-Vista, it might be worth turning /bigobj on by default in VS2015 and
needing a /-bigobj to get the VS2005 behaviour.

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

Thanks for the example. It helped me see your position a lot.

In my head as a non-compiler implementer, as return types have no effect on
overload resolution I wouldn't waste compiler time compiling them until I
know I have selected the overload as the one it's going to be. If the
standard says we should do other than that, I think that's a very good
candidate for a defect report as we gain little while losing much by
compiling the return type during the overload resolution stage (except as a
method to silently rule out that overload, but that's not how C++ has done
things till now). I also think that given the trend we're seeing in
post-C++11 towards a less cookie cutter template syntax like the forthcoming
auto lambdas (and one would assume auto functions are coming), return types
need to get less in the way anyway.

BTW, in your later post you mention clang won't compile the above. As clang
does compile my call() test case, I take it that result_of<> in libstdc++
and libcxx are the SFINAE friendly variants you mentioned? If so then arse,
because for VS2013 I'm going to have to make a special exception just for
that compiler version alone to use boost::result_of<>.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.