Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


Blue Ink Blue Ink
  • Another "WTF, Microsoft?" move

    @Dr Herbie: +1

    True multitasking would be nice, but I appreciate how that could easily turn into a battery hog. I would settle for a global event system able to launch/resume some user-approved applications when a specific event occurs.

  • To Infinity and Beyond

    @Proton2: It's the purple thingy at the top of the page.

  • To Infinity and Beyond

    Ok, we had the infinite. What's the new VS logo supposed to mean?

  • How I downloaded and installed FxCop.

    , Maddus Mattus wrote

    Maybe someone should put in on a blog, so this thread does not pop up everytime someone tries to install Fx Cop

    Yes, a blog post would be brilliant.

    Wouldn't take too long to write: all it actually needs is a link to the FxCop installer Tongue Out

  • The Windows 8 nadir

    , cheong wrote

    Metro is heard for a long time, I just wonder why noone happen to sell LCDs/LEDs with touch built-in. This would be popular for even Win7 users. And from what I saw 5 years ago in ShenZhen the parts are not very expensive (like a few hundred CNY or something less than 80 USD for 15-inch display, and that supports single touch point though), why noone try to do that?


    That's because single point touch doesn't work very well (and if it's a resistive touch you are thinking of, then it just plain sucks) unless you apply it to applications that were specifically written around its limitations. Most interesting gestures require multiple fingers and, without that, you don't get a good experience enough to compensate the lack of hovering and a lazy right click.

  • MS working on a same compiler for C++ AND C# ! Not in 'incubation' but for production !

    , Bass wrote

    I'm no expert in this, but I think reference counting is also more predictable (latency wise) making it superior memory management method for real time applications. GC performance depends on the GC algorithm, but I never recall seeing a GC that was conclusively proven to be faster than reference counting. One thing GC does have that reference counting does not is the ability to handle circular references though. 

    The performance of reference counting is pretty much constant with respect to the amount of available memory. Conversely, garbage collectors will improve steadily as you add more memory (interesting special case when the amount of memory is infinite). So, if GC's aren't ahead right now, they will eventually be.


  • MS working on a same compiler for C++ AND C# ! Not in 'incubation' but for production !

    , SteveRichter wrote

    ... And if a modern C++ app is supposed to use smart pointers, how is that more efficient that C# references?  I thought the lesson learned by the designers of the GC was that reference counting was slower than garbage collecting.

    I believe that needs to be put in the right context. Garbage collection can be more performant than reference counting, so if you are designing a language that relies heavily on managed memory, a GC is the way to go. But there's the rub... C++ offers you options that allow you to express your code without using reference counting at all, possibly at the expense of memory safety.

    Take for instance an object that is not meant to survive the scope it's allocated in. Assuming it's a reference type, in C# it gets invariably allocated on the managed heap and you incur collection costs. In C++, you could use a unique_ptr, or even just allocate it on the stack. Sure, that's not foolproof, but the gains in performance and memory pressure are significant.

    That's where a smarter compiler could really help: in C++ it could be more aggressive in detecting dangerous situations; in C#, it could detect cases in which the lifetime of an object can be safely determined at compile time and get them out of the hair of the GC (and possibly onto the stack).

    This is just the tip of the iceberg, but I already rambled enough. Smiley

  • Wad'ya make of Facebook?

    , Harlequin wrote


    I'm always getting ads for "meeting singles"...my status shows me as married.


    Maybe their telemetry beats your common sense. Or maybe they just happened to notice that divorce lawyer tend to have large yachts.

  • Star Trek

    @Maddus Mattus: sorry to break this to you, but DS9 never takes off. It orbits. Smiley

  • MS working on a same compiler for C++ AND C# ! Not in 'incubation' but for production !

    , Richard.Hein wrote

    Awesome.  There's less and less reason to have a CLR or VM if you have a compiler that can take in various languages and target various architectures just as well - and better.  There's a session on auto vectorization that was just live today ... I only caught a part of it and plan to check it out this weekend.

    Someone correct me if I'm wrong here, but if you have deterministic finalization that works with move semantics as you have with C++ 11, which allows you to avoid falling back to raw pointers and having to manage memory outside of destructors etc..., then performant C++ and C# become quite similar.  The compiler can make the C# behave as it would if it were managed code (GC wise ... ignoring CAS or other CLR services), but better since there's true deterministic finalization.  Since older C++ compilers didn't have move semantics for reference types, then trying to get C# code to compile down to native would result in copy semantics and horrible performance. 

    As I see it, the challenge to get C# get deterministic finalization is to make it able to break out of its dependence on the GC. Extending the language would just beef up the unsafe part of the language; what would be really cool would be to get the compiler spot by usage when a reference can be (safely and verifably) converted into an unique_ptr, a shared_ptr, or even just allocate it on the stack.