search for: vc2010

wine is 1.1.21 I use VC10 beta1 compiler on window, and it's work fine. The Windows is pure: not install any software. That mean is: The VC 10 is a portable software. I can compile main.cpp use: ./cl.exe /EHsc main.cpp it's OK! the main.exe created! but if i do: ./cl.exe /EHsc /Zi main.cpp it's fair. the error information is: > loaden at qpsoft:~/qpcb/bin$ ./cl.exe /EHsc /Zi

...ervatively great progress for LLVM 3.4 to bump > the minimum GCC requirement up to enable use of VC 2010-era features (like > rvalue refs and simple stdlib features), I am strongly opposed to this. Currently, we have people that are relying on our C++98 status. This isn't actually about VC2010 issues, this is about GCC support. I think it would be a disservice to change that in 3.4, only a small number of weeks away from the branch point. That seems like very little notice. > then jump to VC2012 features in LLVM 3.5 assuming that goes well. We're > talking about a 6 month de...

...servatively great progress for LLVM 3.4 to bump the minimum GCC requirement up to enable use of VC 2010-era features (like rvalue refs and simple stdlib features), > > I am strongly opposed to this. Currently, we have people that are relying on our C++98 status. This isn't actually about VC2010 issues, this is about GCC support. I think it would be a disservice to change that in 3.4, only a small number of weeks away from the branch point. That seems like very little notice. Yes, good point. A more logical one would be to go for 3.5/3.6 for "VC2010" and "VC2012" feat...

..., but have not yet had the > available man hours to do so. Ok. Unfortunately, I don't think it makes sense for the general community to bend over backwards to support VC2005 anymore. We're talking about LLVM 3.3 here (at the earliest), is there a strong reason you couldn't move to VC2010 by whenever you move up to LLVM 3.3? -Chris

>> Ok. Unfortunately, I don't think it makes sense for the general community to bend over backwards to support VC2005 anymore. We're talking about LLVM 3.3 here (at the earliest), is there a strong reason you couldn't move to VC2010 by whenever you move up to LLVM 3.3? >> >> -Chris > LLVM has not been compatible with VS2005 for a long time. > > And as a note to why you can be held back by external software on VS. > MSVC changes the C++ ABI with every release. If you have a 3rd party > product with no...

...t yet had the >> available man hours to do so. > > Ok. Unfortunately, I don't think it makes sense for the general community to bend over backwards to support VC2005 anymore. We're talking about LLVM 3.3 here (at the earliest), is there a strong reason you couldn't move to VC2010 by whenever you move up to LLVM 3.3? > > -Chris LLVM has not been compatible with VS2005 for a long time. And as a note to why you can be held back by external software on VS. MSVC changes the C++ ABI with every release. If you have a 3rd party product with no source access, or you need to...

...y great progress for LLVM 3.4 to bump the minimum GCC requirement up to enable use of VC 2010-era features (like rvalue refs and simple stdlib features), > > > > I am strongly opposed to this. Currently, we have people that are relying on our C++98 status. This isn't actually about VC2010 issues, this is about GCC support. I think it would be a disservice to change that in 3.4, only a small number of weeks away from the branch point. That seems like very little notice. > > Yes, good point. A more logical one would be to go for 3.5/3.6 for "VC2010" and "VC2012&...

Chris Lattner <clattner at apple.com> writes: > One other specific problem with this is that (I'm told) MSVC 2010 > doesn't support range-based for loops. I don't think it is reasonable > to require windows users to be on MSVC 2012. That's _really_ unfortunate. I've found range-based for gets one thinking a different way about how to present data. The range

>> One other specific problem with this is that (I'm told) MSVC 2010 doesn't support range-based for loops. I don't think it is reasonable to require windows users to be on MSVC 2012. :-( > I suspect you're right about that, but I'd appreciate if some MSVC > users would speak up here. We shouldn't hold back on using range-based > for loops if all our MSVC

anyone has installed Rage? the appdb entry doesn't work for me. Thanks

On Jul 24, 2011, at 6:31 PM, David Blaikie wrote: >>> This keeps things simple & seems to be "good enough" to me, but we >>> could perhaps do better (at the very least, again, if we did do >>> better, we could go back & remove TwineString & again fix all the >>> places that fail to compile with whatever new hotness we invent) >>

Thanks for your appreciated help. i found casting fromunsigned short to short gives different value: unsigned short FFFF=65535 where short FFFF= -1. however, can i configure speex codec (specifically speex_encode_int function) to take input of type unsigned short instead of short so that i avoid casting errors ? Regards, Mashal ________________________________ From: Yanick Bourbeau

On Tue, Jan 8, 2013 at 6:23 PM, Chris Lattner <clattner at apple.com> wrote: > On Jan 8, 2013, at 4:26 PM, Jeffrey Yasskin <jyasskin at googlers.com> wrote: >>> Another thing to bring up is that we have a lot of classes which have >>> method pairs `foo_begin()` and `foo_end()` (e.g. >>> `Function::arg_{begin,end}()`). These don't play nice with

On Oct 27, 2013, at 9:07 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <clattner at apple.com> wrote: > On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at google.com> wrote:> Concrete long term proposal: > > > > We support building with C++ toolchains which were released and widely

On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <clattner at apple.com> wrote: > On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at google.com> > wrote:> Concrete long term proposal: > > > > We support building with C++ toolchains which were released and widely > available on their respective target platforms at least 2 years prior to > the next