Live data from Hacker News

Visual Studio 2013

blogs.msdn.com

111–120 of 201 posts

Re: Visual Studio 2013

#111
post #8

Way way way way, WAY too soon Microsoft... most shops, including my current employer aren't even on 2012 yet... Honestly I prefer VS to be tied to desktop OS releases or SQL release or something other than yearly. This is not a Madden game, nobody is asking for yearly updates for Visual Studio.

I believe it is tied to the OS release: http://blogs.windows.com/windows/b/bloggingwindows/archive/2...

Re: Visual Studio 2013

#112
post #59

Earlier quoted context omitted.

Try R# with VS.

Try R# with VS in a solution with 54 projects and ~ 1.5MLOC... It stinks!

Well, I don't know how many LOC I have, but I'm sure close to or more than that.

But we've got 62 projects. I've turned off a few things like code analysis in R# and it runs fairly well.

Re: Visual Studio 2013

#113

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…

Current VS-compiler dev here, the backend codegen team to be more precise (I actually own PGO). I wish this comment had been written in few days/weeks/months so I answer directly and talk specifics about some of the work that went into VS2013, but for now I just want you to know we've aware of all of the issues you brought up, and have either worked on or plan to work on many of them.

RE: likely/unlikely, VS has __assume(0), which isn't exactly the same thing I know, but it is something and does help. I'm actually in favor of us doing more with static annotations to bring PGO style optimizations to non-PGO builds. If you feel the same way please be louder about it, but realize there is a vocal group of people who consider static annotations harmful (and they have a large body of evidence in __forceinline backing them up).

oprofile: There is ETW/xperf, and of course a variety of instrumented profilers (both shipping and internal)

Although I do wish my team was larger, and it doesn't get all the love that some of the more flashing UI stuff does, I wouldn't go as far as to say the toolchain is withering. Some of the smartest people I know are working on my team with me on these problems.

Re: Visual Studio 2013

#114
post #103

Earlier quoted context omitted.

Mozilla has been fighting the MSVC linker's 3GB virtual address space limit for years. Mozilla has asked Microsoft for a 64-bit linker that can produce 32-bit code, but Microsoft apparently has no plans for such a configuration. https://groups.google.com/forum/?fromgroups#!topic/mozilla.d...

What I want to know is how someone can see that their software project has become unlinkable on a 32-bit OS and somehow think that this is purely a compiler problem.

I'm actually about to sit down and write a blog post about VS compiler memory issues, and I had a long talk with the Firefox guys a few weeks ago about this issue. It's not all their fault.

Re: Visual Studio 2013

#115
post #75

Earlier quoted context omitted.

It happens regardless of precompiled headers, so I don't think that's the issue. I do think it's an include problem, but I don't know why.

It's precompiled headers and it can be proved: If you would try to turn off precompiled headers in your project and rebuild it, the compilation would fail in all the files in which you see the red lines. It's because your project has subfolders and the files in the subfolders reach stdafx only by accident of having the "use precompiled headers" turned on. So once you fix the include path, and that you can do on the p…

That's actually not it, but that idea helped me to find the issue. L52-56, this Freetype preprocessor magic defeats Intellisense https://code.google.com/p/freetype-gl/source/browse/trunk/te...

I feel silly for never mousing over the three characters at line 62 where Intellisense describes the problem it's having.

Re: Visual Studio 2013

#116
post #75

Earlier quoted context omitted.

It happens regardless of precompiled headers, so I don't think that's the issue. I do think it's an include problem, but I don't know why.

It's precompiled headers and it can be proved: If you would try to turn off precompiled headers in your project and rebuild it, the compilation would fail in all the files in which you see the red lines. It's because your project has subfolders and the files in the subfolders reach stdafx only by accident of having the "use precompiled headers" turned on. So once you fix the include path, and that you can do on the p…

[deleted]

Re: Visual Studio 2013

#117
post #31

Earlier quoted context omitted.

ex-VS person here (from 5 years ago though). It is never an either-or. It is always a complex mix of what customers ask for, what the strategic priorities/market realities are. Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. On promotions - I think it's the reverse problem. People…

Mozilla has been fighting the MSVC linker's 3GB virtual address space limit for years. Mozilla has asked Microsoft for a 64-bit linker that can produce 32-bit code, but Microsoft apparently has no plans for such a configuration. https://groups.google.com/forum/?fromgroups#!topic/mozilla.d...

I am a bit confused. That thread seems to claim that Microsoft isn't producing a 64 bit linker, my install seems to disagree with them (vc\bin\amd64). Then you claim that the linker won't produce 32 bit code, but /machine:x86 seems to disagree with that. I tested this by building as 32 bit, then just repeating the link using the 64 bit linker and /machine:x86, worked fine.

So what are their problems exactly? That they are building with VS 2005 (from what I saw in that thread) and MS isn't backporting changes to the 2005 toolset?

Re: Visual Studio 2013

#118
post #100
post #90

Earlier quoted context omitted.

After reading through the two linked pages I can not see the relevance. The first article just discusses the in-place update but shows no (real) problems with that. The problem in the Stackoverflow question turns out to be caused by a bug in the OPs code and not by a breaking change between versions 4.0 and 4.5. Of interest may be the linked list of breaking changes [1] and given the size of the .NET framework it is…

Even if there was only one issue, that is an issue to spend effort working around it if you're the poor soul that needs to do the fix for the product that broke.

I am still unable to see the problem. It's your decision if you switch to 4.5 or not. If you have projects targeting 4.0 and are unable to ensure that you code does not hit any of the documented breaking changes or if you are unwilling to take the risk of hitting unknown or undocumented compatibility problems, then don't switch to 4.5. Or take a hybrid solution - develop against 4.5 but test against 4.0.

We have deviated quite a bit from the original comment - you can install different Visual Studio (and .NET framework) versions side by side if you have to support legacy projects. There are some case where this will not work - obvious examples are .NET 1.0 not being supported since Vista, .NET 1.1 since Windows 8 - but there are still a lot of cases where this works just fine. If an side by side installation is not possible, you can still just setup up a second machine or a virtual machine for you legacy development needs. Not being able to upgrade Visual Studio because you have to support legacy projects is mostly a non-issue.

Re: Visual Studio 2013

#119

Earlier quoted context omitted.

I prefer to think of it as "Microsoft tooling is dead", since C continues to work just fine.

Either way, C99 in Visual C++ isn't happening, so why beat a dead horse?

For the same reason people still push Python 3...hope.

Re: Visual Studio 2013

#120
post #103

Earlier quoted context omitted.

What I want to know is how someone can see that their software project has become unlinkable on a 32-bit OS and somehow think that this is purely a compiler problem.

I'm actually about to sit down and write a blog post about VS compiler memory issues, and I had a long talk with the Firefox guys a few weeks ago about this issue. It's not all their fault.

Awesome - where's it likely to get posted?
Post reply on HN