Native .NET hat does it mean for C++

Discussion in 'C++' started by cpisztest, May 22, 2014.

  1. cpisztest

    cpisztest Guest

    I just heard that they are working on a compiler option to compile .NET into native code with such advertising as "It will perform as well as native C++."

    While I am not going to buy into performance claims right away, this does scare me, in that C++ might be used much much less if it goes well.

    To add to that fear, they are planning on supporting DX12 in this native .NET code as well! Ack! That was one place where I knew my C++ would be needed, but now people will be doing another round of game programming in .NET.

    What do you think? Are we C++ guys losing our value? Is this bad for us, but good for the world?
    cpisztest, May 22, 2014
    1. Advertisements

  2. You sound as if MS Windows is the only platform on which C++ is used...

    Victor Bazarov, May 23, 2014
    1. Advertisements

  3. cpisztest

    cpisztest Guest

    The only one I'm any good at anyway :p I barely know how to ls or grep. Maybe I'll have to learn that.
    cpisztest, May 23, 2014
  4. cpisztest

    Öö Tiib Guest

    They are always working on myriad of things. Sometimes successfully,
    sometimes not.
    C# is good but it is based on blueprints of Sun. Lets see history
    of their other languages. They did make VB.NET ... it is 2014
    but there are still hundreds of thousands of developers who use
    "long dead" Visual Basic 6.0 of 1998. They did make that "managed"
    C++/CLI that no one uses.

    Now they make "native" C#. What are chances that it succeeds?
    I'm more afraid that it is yet another marketing buzz to mix
    things up and compete better with Java in journals.
    Desktops and consoles are seemingly in process of losing part
    of the entertainment market to tablets and smartphones (that
    don't run .NET nor DX12). If you are genius game programmer then
    better investigate iOS or Android or both.
    I'm not C++ guy. I'm software engineer. C++ is fine tool and it won't
    disappear all of sudden. Most things are based on it. What is the
    Öö Tiib, May 23, 2014
  5. cpisztest

    Stefan Ram Guest

    It is 2014?

    I now quote from the »World-Wide Web«:

    »NET has been sidelined in Windows 8; C++ and COM is
    back in vogue, and HTML5 + JavaScript is the New Way of
    writing applications«

    »Net developers fear their skill sets may become legacy
    ones. Microsoft officials have not clarified where .Net
    fits in the Windows 8 world.«
    Stefan Ram, May 23, 2014
  6. cpisztest

    Jorgen Grahn Guest

    If MS drives the C++ people over to Unix, I'm all for it! ;-)

    More seriously: I think the vendor-specific aspect of the MS languages
    is a serious drawback, and hopefully people will eventually see that.

    Jorgen Grahn, May 23, 2014
  7. I don't think that this will have an effect on what you are referring to asthe C++ guys loosing value. In order for that argument to really mean something then we would have to assume that the majority of products written in C++ are easily replaced by {INSERT MICROSOFT LANGUAGE OF THE DAY HERE, X++, F#, C#, VB.NET, ETC}. Are they? I don't think so; do you think you will see an av, web browser, or any other technology written in that. You specifically mentioned DX, do you think Unity or other guys are going to rewrite their entire backend to gain nothing at all in regards to performance? Also, will you fall into .NET dependency hell still? That is, will I need to require my customers to have .NET 3.5, 3.5SP1, 4.0, 4.5, etc in order torun this thing.....
    Stewart Henderson, May 23, 2014
  8. cpisztest

    J. Clarke Guest

    Maybe I'm naive or maybe I've just missed something, but I don't really
    understand the notion that .NET somehow competes with C++, anymore than
    GTK or Qt competes with C++.
    J. Clarke, May 24, 2014
  9. I think the idea is that the .NET code can be produced from Visual BASIC
    or C# source code, and if some JIT compiler with a powerful optimizer
    makes the code run as fast as a native C++ executable, there is less
    incentive for some folks to learn C++ instead of sticking to the more
    forgiving .NET languages (VB.NET, C#, etc.)

    Victor Bazarov, May 24, 2014
  10. cpisztest

    J. Clarke Guest

    I'm writing this mostly to organize my own thoughts, so please don't be
    too hard on me if I'm off base or repeating common knowledge.

    I did a bit of investigating and now I think I see what's going on.
    Microsoft has a new developer preview of .NET that includes libraries
    compiled to native code for X64 and ARM rather than to intermediate
    code, and a version of the C# compiler to go with it. They are
    currently only targetting "Windows Store" apps with it. They make it
    clear that this is a preview and that at some point "Native .NET" will
    be supported for desktop applications and under other languages than C#,
    but they don't say specifically which languages.

    The trouble comes with C++ and .NET since they don't work and play well
    together--Microsoft has come up with a language (C++/CLI) related to C++
    that works with .NET but disables some language features to do it. Now,
    the reason for this is limitations of the CLR, and going to native code
    would in principle take the CLR out of the picture and remove those
    limitations. So then the question becomes whether Microsoft is going to
    produce a C++/Native .NET system that is an actual superset of C++ or
    whether they're going to stick with the C++/CLI model even with Native
    ..NET. If they go the superset route this could be a good thing for C++
    programmers because it would add one more tool to the arsenal.

    So I think the best attitude at this point is "wait and see".
    J. Clarke, May 24, 2014
  11. cpisztest

    Jorgen Grahn Guest

    As I understood it back when it was discussed here, "disables some
    language features" underestimates the changes: your typical program
    would look radically different in C++/CLI. Not that I've investigated
    it or anything.

    Jorgen Grahn, May 24, 2014
  12. cpisztest

    Dombo Guest

    Op 23-May-14 3:17, Öö Tiib schreef:
    It has been possible to generate native code image with the NGEN tool
    since .NET 1.0 if I'm not mistaken. Though that really only helps for
    the startup performance.
    That isn't necessarily a bad thing. A more problematic aspect is vendor
    lock-in. Though it is possible to run .NET code on non-Microsoft
    platforms, no one in his right mind would consider writing .NET code
    when targeting anything other than a Microsoft platform. Another
    downside, much like Java, is that it requires the installation of the
    rather huge .NET framework.
    I'm not surprised; VB.NET has little to do with Visual Basic 6.0. The
    differences between C# and VB.NET are just cosmetic; keywords and syntax
    aside C# and VB.NET are conceptually the same languages; semantically
    both are very similar to Java. Run decompiler on a .NET application and
    you can choose whether you want to see the code as C# or VB.NET.
    Learning VB.NET would be easier for a C#-, Java- and even a C++
    programmer than for a Visual Basic 6.0 programmer.
    I have used C++/CLI in the past to write an interop layer to allow .NET
    code to use existing C and C++ code base. For that it does do the job as
    well as could reasonably be expected given the rather fundamental
    differences between .NET languages and C++.

    AFAIK C++/CLI is not intended to be an alternative for C++ or for C# (or
    whatever other language), but solely intended for glue layers to
    leverage existing code. I doubt that even at Microsoft anyone had any
    hope that the schizophrenic mess that C++/CLI is would have caught on
    for any other purpose than writing interop layers.
    The question is what problem are they trying to solve? For the vast
    majority of desktop applications runtime performance has become a

    These days Microsoft is struggling to become a relevant player in the
    mobile arena. This is where runtime efficiency matters because mobile
    platforms tend to have less powerful hardware and more importantly
    energy consumption matters.

    My guess is that the purpose of "native" .NET to make it a more viable
    option for mobile applications, hoping that it will attract .NET
    developers to develop programs for Microsoft's mobile platform.

    Whether it will succeed? You never know with Microsoft, they do change
    their ideas from time to time, but they also have deep enough pockets to
    keep trying for a long time. In the end I don't believe Microsoft really
    cares about programming languages, but only cares about staying a
    relevant player. "Native" C# is at best just a means to an end.
    I doubt Java is considered a serious threat. On the desktop Java is
    pretty much dead; Oracle doesn't seem to be overly enthusiastic further
    develop and promote Java. Java seems to be still somewhat relevant in
    server space, but that doesn't seem to be the focus of Microsoft at the

    In the mobile space there is the weird situation with Android, where
    most applications are written in Java but are converted to run on
    Googles runtime environment (Dalvik). Also Google is working on to
    replace the Just-In-Time compiler with a Ahead-Of-Time compiler (ART).
    This is probably what triggered Microsoft to do the same thing for their
    Even if another programming language would replace C++ as the language
    of choice in areas relevant to you, you can still learn that other
    programming language. For someone who has mastered C++ it will be much
    easier to learn a new programming language than the other way around.
    And besides that it is always a good idea to know more than one
    programming language, so you can pick the right tool for the job rather
    than just sticking with what you know.
    Dombo, May 24, 2014
  13. cpisztest

    BGB Guest

    IMHO, its main drawback when I tried using it is that it has few of the
    advantages of *either* native code or .NET development.

    one time I tried using it, but it managed to suck enough for what it was
    needed for that it turned out to just be easier to port a big mass of C
    code over to C#.

    I would probably choose either though over being stuck writing lots of
    code in Java though...

    for whatever claimed merits or being "easy for rapid application
    development" or whatever else, Java manages to just suck so bad for
    actually writing code in it.

    then again, its developer mindset tends to be mostly "what library do I
    invoke to do X?", with people dismayed whenever there isn't a premade
    library and they "might actually need to write some actual code".

    then a few times getting very tempted to throw a C preprocessor on top
    of this to allow using macros to make some stuff less of a pain.

    but, I mostly like to downplay knowing anything about Java, as most of
    what it is used for is stuff I would rather stay far away from.

    at least with C#, it is easier to implement/fake a bit more of the stuff
    which is absent, and do things a little more freeform, which is helpful.

    a drawback though is the relatively limited choices in terms of
    implementations, and relatively little use/support much outside of MS-land.

    one drawback of C and C++ though is there are a few targets where
    support is a bit lacking (namely web-browsers and Android), and recently
    I have been working on a VM designed to try to help lessen some of the
    pain involved on these targets (though, initially it will probably be C
    only, or maybe C and a C++ subset). though, this VM is still at a
    relatively early stage (and mostly just a personal-use project).
    BGB, May 25, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.