Visual Studio 2013

Post by seanmcdirmid » Tue, Jun 04, 2013, 12:34 AM UTC

echohack wrote: post #33

CoolGuySteve wrote: post #22

I wish they would dedicate more time to improving cl.exe and link.exe in terms of performance and language support and less time with these hokey team visualization gimics. Every release since 2008 has been getting slower and slower for C++, the C compiler is awful, PGO instrumentation in Win8 is less capable, and there's no equivalents in the Windows ecosystem to gcc's likely/unlikely, oprofile, or valgrind. It's at…

My assessment: Gimmicks: - Popout explorer windows (So you can get the old style Pending Changes window, if you like) - Make comments and discussions on code through web UI - New release management plugin - “Team rooms” allow your team to collaborate on code "I'm OK with this" improvements: - “Indicators” in code that give you info about blocks of code - Cloud load testing - More agile portfolio management options -…

Post by rpgmaker » Tue, Jun 04, 2013, 12:37 AM UTC

ajross wrote: post #71

FactoryFactory wrote: post #68

Earlier quoted context omitted.

>But you're right, that clearly the "devs" have preferences. The problem with your mechanism is that they don't express them to you in customer service requests. They just job-hop to another environment, doing Javascript work, or Linux, or Ruby. And you never hear from them. >Basically, the way feedback works in this world is with feet, not bug reports. If you build it they will come. If you don't they will leave. Is…

Well, just to address the first point there is undeniably an "exodus" from Visual Studio. Just look at all the code shipped to run in browsers, or iOS, or Android, or on node or rails. A decade and a half ago a far (far!) greater fraction of that was spend in a Microsoft IDE. But that's really not the point. The upstream discussion was much narrower, and focused specifically on C/C++ support, which frankly sucks in t…

Post by yuhong » Tue, Jun 04, 2013, 12:43 AM UTC

pjmlp wrote: post #41

CoolGuySteve wrote: post #22

I wish they would dedicate more time to improving cl.exe and link.exe in terms of performance and language support and less time with these hokey team visualization gimics. Every release since 2008 has been getting slower and slower for C++, the C compiler is awful, PGO instrumentation in Win8 is less capable, and there's no equivalents in the Windows ecosystem to gcc's likely/unlikely, oprofile, or valgrind. It's at…

C is officially deprecated. Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level. Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already availa…

Post by yuhong » Tue, Jun 04, 2013, 12:45 AM UTC

cpeterso wrote: post #146

jlgreco wrote: post #110

Earlier quoted context omitted.

Keep in mind that this is the group that thinks de-prioritizing 64-bit windows builds is a-okay while at the same time they need 64-bit windows machines running 32-bit linkers to build their 32-bit windows binaries. ...phew, what a mouthfull. Mozilla has never struck me as the most... forward looking.

btw, Google Chrome doesn't have a 64-bit version* for Windows. The Chrome team also disabled PGO on Windows because of the same MSVC linker limitations that Mozilla hit. * Edit: oops, I corrected a typo where I wrote "32-bit build".

Post by ryanmolden » Tue, Jun 04, 2013, 12:55 AM UTC

yuhong wrote: post #135

ryanmolden wrote: post #131

Earlier quoted context omitted.

You mean it only produces 32 bit code? This disagrees ( http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as... ) going back to at least 2005. The following list describes the various versions of cl.exe (the Visual C++ compiler): ... x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit W…

I am talking about the cl.exe executable that output x86-32 code itself, not the code it produces. You can use a 32-bit cl.exe to cross compile 64-bit code, but not the other way round.