locked
Microsoft C++ Development Options falling short RRS feed

  • Question

  • While you see other Languages Development options (including C# and VB.Net) being expanded, renewed, and in general moving forward to ease coding / development and rapidly generate "modern" and reliable applications with less effort and minimizing the learning curve, you may get the (strong) impression that C++ fall short.

    For example:

    - C++/CLI interoperability with other .Net Languages fall behind a lot of time ago;

    - C++/CLI in VS2010 didn't even ship with intellisense falling behind and making harder to code and/or maintain C++/CLI code;

    - C++ Native development for GUI (User Interfaces) using MFC fall behind a decade ago by keeping the Legacy codebase while other GUI's has moved forward, for example, allowing the use of WPF and providing a "modern" and easier to use libraries to produce those needed interface in a lot less time that will take to do the same in MFC;

    - C++ Native development in Windows Phone 7 is a no can do!  So if you have invested lots of money in your Native development in previous platforms then... 

    The previous are just a few clues that Microsoft C++ not only can be viewed as falling behind but confirmed that it has.

    Microsoft C++ Development Team does continue to point out that C++ does has a future at Microsoft, specifically by making the Native development the answer when you want performant apps.

    The question will be,  In what platform or technology since C++ Native development can't move forward  to WPF and  most recently to WP7 to mention two examples...

    If you search for C++ development around the world you consistently see C++ or related derived aliases to be in the top 2 - 4 position in decades, when you see Microsoft C++ Native development efforts and offerings for Developers I get the strong impression that they are not interested in participate or be part of those top 2 - 4 groups...

    Your comments about previous issues are welcome.

     


    Eduardo Sobrino
    Wednesday, December 8, 2010 12:08 PM

Answers

  • Regardless of what you think C/C++ are much more prevalent in use than other languages. Yes it can't use WPF but WPF isn't that great anyway, using native C++ technologies like Direct2d/DirectWrite or even working hard and using the older stuff like GDI you can still make applications which look better than WPF and they will run faster.

    WP7, who cares about that IMO.

    C++ is also not about ease. One line which I've heard sums it up prett well. "Some people think that C++ helps stop shooting yourself in the foot, this is untrue as it will happily hand you the gun, help you aim and give you a drink to steady your nerves". Another thing, C#/VB are only popular on Windows, if you start looking at other OS you will find that C/C++ is the most popular language.

    Now onto the CLR itself. These things, the CLR and the Java VM are memory hogs. A C/C++ program usually uses less memory. This is why for embedded platforms with restricted memory native coding is the only way. Another thing which has been pointed out to me by people who I know code for the CLR, it rarely touches the SSE instruction sets, it also doesn't use the higher precision floating operations so the results of float operations are less accurate than C/C++ projects at the default settings.

    OK, now about C++/CLI. I believe that this was introduced to get everyone on the .NET bandwagon, even C++ users. The problem was that C++ users turned around and said no. With legacy code to maintain and too many standard coding practices in place, it would have been too much of a change. Because of that what could Microsoft do, the majority of the users wanted native only yet they had started a drive to push C++/CLI so it was tough for them. In the end it seems as if they relented and started going back to native. But this left a gap of a few years in the native side of C++.

    For MFC vs WPF, the question is are you basing this off of modern applications on the market or off of what you can seemingly do yourself. It may not seem like it right at the start, but MFC can easily harness the power of Direct2D and make snazzy looking apps too. But do most users want that? The best real world example of a WPF application that is easy to point out is Visual Studio 2010 itself. But besides using font smoothing and things like that it doesn't have too much. But this is the kind of environment most people when working prefer. This is the kind of environment that businesses prefer too. But there are also lots of complaints that it is slow, especially compared to native only VS6. In the end WPF can give the power to make a good looking UI relatively easily where the native approach requires work.

    Finally for C++ itself, how can you say it isn't moving forward. VC2010 had lots of new features. The entire project system and intellisense system was rewritten from scratch. That is a lot of work on its own. The compiler had several C++0x features added too. This implimentation again was a lot of work. But another thing to remember is that the C++ development cycle is also shorter than the rest of the VS teams. The first part of the build is to build VC. VC is then used to build the rest. This means that VC has to have its features locked months before C# or VB. So coming here and saying that C++ falls short is just wrong. Yes, comparing it directly to what the .NET has may make it feel like it falls short in what it can access from there. But if you ignore that and look at what it can access natively, what it can do natively and what the others can't do compared to C++ then you realise that the situation is actually inverted. C# and VB are inferior to C/C++.


    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
    Visit my (not very good) blog at
    http://ccprogramming.wordpress.com/
    • Proposed as answer by Victor Stout Thursday, December 9, 2010 1:48 AM
    • Marked as answer by Yi Feng Li Friday, December 17, 2010 2:47 AM
    Wednesday, December 8, 2010 3:02 PM

All replies

  • Regardless of what you think C/C++ are much more prevalent in use than other languages. Yes it can't use WPF but WPF isn't that great anyway, using native C++ technologies like Direct2d/DirectWrite or even working hard and using the older stuff like GDI you can still make applications which look better than WPF and they will run faster.

    WP7, who cares about that IMO.

    C++ is also not about ease. One line which I've heard sums it up prett well. "Some people think that C++ helps stop shooting yourself in the foot, this is untrue as it will happily hand you the gun, help you aim and give you a drink to steady your nerves". Another thing, C#/VB are only popular on Windows, if you start looking at other OS you will find that C/C++ is the most popular language.

    Now onto the CLR itself. These things, the CLR and the Java VM are memory hogs. A C/C++ program usually uses less memory. This is why for embedded platforms with restricted memory native coding is the only way. Another thing which has been pointed out to me by people who I know code for the CLR, it rarely touches the SSE instruction sets, it also doesn't use the higher precision floating operations so the results of float operations are less accurate than C/C++ projects at the default settings.

    OK, now about C++/CLI. I believe that this was introduced to get everyone on the .NET bandwagon, even C++ users. The problem was that C++ users turned around and said no. With legacy code to maintain and too many standard coding practices in place, it would have been too much of a change. Because of that what could Microsoft do, the majority of the users wanted native only yet they had started a drive to push C++/CLI so it was tough for them. In the end it seems as if they relented and started going back to native. But this left a gap of a few years in the native side of C++.

    For MFC vs WPF, the question is are you basing this off of modern applications on the market or off of what you can seemingly do yourself. It may not seem like it right at the start, but MFC can easily harness the power of Direct2D and make snazzy looking apps too. But do most users want that? The best real world example of a WPF application that is easy to point out is Visual Studio 2010 itself. But besides using font smoothing and things like that it doesn't have too much. But this is the kind of environment most people when working prefer. This is the kind of environment that businesses prefer too. But there are also lots of complaints that it is slow, especially compared to native only VS6. In the end WPF can give the power to make a good looking UI relatively easily where the native approach requires work.

    Finally for C++ itself, how can you say it isn't moving forward. VC2010 had lots of new features. The entire project system and intellisense system was rewritten from scratch. That is a lot of work on its own. The compiler had several C++0x features added too. This implimentation again was a lot of work. But another thing to remember is that the C++ development cycle is also shorter than the rest of the VS teams. The first part of the build is to build VC. VC is then used to build the rest. This means that VC has to have its features locked months before C# or VB. So coming here and saying that C++ falls short is just wrong. Yes, comparing it directly to what the .NET has may make it feel like it falls short in what it can access from there. But if you ignore that and look at what it can access natively, what it can do natively and what the others can't do compared to C++ then you realise that the situation is actually inverted. C# and VB are inferior to C/C++.


    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
    Visit my (not very good) blog at
    http://ccprogramming.wordpress.com/
    • Proposed as answer by Victor Stout Thursday, December 9, 2010 1:48 AM
    • Marked as answer by Yi Feng Li Friday, December 17, 2010 2:47 AM
    Wednesday, December 8, 2010 3:02 PM
  • WPF seems to offer much higher level abstractions than do Direct2D and DirectWrite, and tooling built into both VS and Blend.  I don’t think you can compare WPF with Direct2D and DirectWrite.  In fact, I’m not sure who would use either Direct2D and DirectWrite.  First, they are only supported in Vista SP2 and later with no redist for XP.  Second, DirectWrite doesn’t seem to offer anything I can’t get in plain old GDI, and Direct2D seems to be trying to offer HWND-free overlapping Windows from WPF but just the rawness and no framework surrounding it.  Please correct me if I’m wrong, as I don’t know much about these Direct things, except they don’t seem useful to me.
     
    MS needs a mobile story for Windows devs so we can leverage our hard won knowledge to the mobile platforms, which all accounts say will surpass the desktop and laptop platforms in a couple years!  How can you say who cares about WP7?
     
    C++ is not about ease, but neither should it be about making simple things harder than necessary.  I don’t agree with the design decisions that went into STL and Boost, sorry.  Agree about VM performance, size, etc. 
     
    The reason it is obvious that C++ is not making progress is because it’s not!  It is not making progress for the 90% of the C++ devs who used in in the VC6 peak.  The MS C++ team is repurposing what used to be a general purpose language used for all things from device drivers to apps to web controls into a boutique language that only 10% of the devs need for performance, etc. 
     
    And none of us really care what the dev cycle is for VC related to other VS... if it’s not serving C++ well, it needs to be changed.  But I have never heard that VC needs to be frozen before everything else so everything else can use it to build their stuff.  Never.
     
    Since I am among the 90% of the C++ devs and not in the remaining 10%, I reluctantly started switching to C# and .NET 6 years ago to meet my needs.  But I keep looking longingly back at C++, hoping MS will see the light before I am entirely assimilated, because truly C++ is my home.  But it does not seem to be.  I keep saying MS should build a better Qt than Qt for Windows and win me (and a whole lot of others) back.
     
    -- David
     
     
     
     
    "Crescens2k" wrote
    ... a bunch of stuff I don’t agree with
     

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Wednesday, December 8, 2010 8:23 PM
  • Bottom line is if you are windows c++ developer, better move to .net or linux c++.

    If this answer solves your problem, please check Mark as Answered. If this answer helps, please click the Vote as Helpful button. Cheers, Rajender Saini Aditi Enterprise Solutions – Partnering Innovation | www.aditi.com
    Wednesday, December 8, 2010 9:17 PM
  • Bottom line is if you are windows c++ developer, better move to .net or linux c++.


    .NET is Windows development and it can be performed in CLI version of C++.

    Thursday, December 9, 2010 1:55 AM
  • @Victor:  ever since C++/CLI ceased being a first-class .NET language starting in VC2008, it ceased being a solution for the 90% of the devs who used to use VC6.  It is recommended even by MS only for bridging native and managed code.
     
    @rajendersaini:  you are right, if you want to be relevant and stay in C++, the door points to Linux or else embedded C++.  I am sorry to say that after investing over a year in Qt on Windows that I cannot find any Qt on Windows jobs.  They are all Qt on Linux.
     
    -- David
     
     
    "Victor Stout"
    .NET is Windows development and it can be performed in CLI version of C++.

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Thursday, December 9, 2010 2:29 AM
  • @Victor:  ever since C++/CLI ceased being a first-class .NET language starting in VC2008, it ceased being a solution for the 90% of the devs who used to use VC6.

    1. Can I get statistics on that please? The one that shows 90% of developers who used ancient VC6 don't consider C++/CLI as a solution.

    2. They don't consider it as a solution to what exactly? If there is a need to write .NET applications then C++/CLI is a way to go but if there is no need in that, then of course it's better to stay with native code and VC10 for God's sake..

    3. Do you care more about what others are using or what's more beneficial to program with nowadays for you?

    It is recommended even by MS only for bridging native and managed code.

    4. Are you ready to provide a link to that rather interesting recommendation from Microsoft which states C++/CLI should only be used for interoperability?

    All I see here is hate for Visual C++, Windows and love for Unix-like systems. What's the matter with that? Last time I checked Mono project was open source and accessible from Linux. Viva la inventing bicycle..

    P.S. I have to applause to Crescens2k for telling it like it is even though somebody is insisting on high level functionality being more up to date than the one it's built upon.

    Thursday, December 9, 2010 3:11 AM
  • Victor, few if anyone one uses C++/CLI to write Windows apps.  VC2005 fully supports C++/CLI to develop .NET 2.0 apps (although the tooling doesn't work as well as for C#) apps,  VC2008 (which supports .NET 3 and later) does not.  You can't do WPF or LINQ in C++/CLI, for example.

    I've been an MVP for four years, and I really cheered hard when VC2005 came out with full .NET support.  In fact, that's how I learned .NET.  I used C++/CLI to write WinForms apps.  It was much easier for me, coming from C++ and MFC, to grasp C++/CLI than to do it in C#.  But clearly that was not to last, as the lacking support of .NET 3 and later attests.  

    Here is my analysis of a Channel 9 video that says MS repurposed C++/CLI for interop: http://groups.google.com/group/microsoft.public.vc.mfc/msg/a4dbc98040e33090

    For the record, I don't like Linux.  I love Visual C++, but less so than with VC6.  I think C++ under MS's stewardship has suffered drastically.  C++ with cross platform Qt is flourishing.  So now I have to choose.  Do I want to stick with Visual Studio (but not C++) or do I want to stick with C++ but not Visual C++?  What I hate is that MS put me in a position to have to choose.

    If your comment about "somebody is insisting on high level functionality being more up to date than the one it's built upon" was talking about me, I have no idea what your point is.  I do think it's a joke to compare raw HWND-less access (my admittedly limited understanding of DirectWrite) to a full blown framework like WPF complete with tooling visual designers in both Visual Studio and in Blend (even if those are not very intuitive to me, and in my mind, represent a golden opportunity for the Visual C++ team to improve on them).  I mean, it's like comparing the first prototype of a gas engine to a modern car.

    Thanks,
    David

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Thursday, December 9, 2010 4:38 AM
  • what is the point in using C++/CLI ? just to have c++ Syntax to access .net functionality ? why would you do that ? For me working in c# is much more productive and easy to program for .net framework. 

    If this answer solves your problem, please check Mark as Answered. If this answer helps, please click the Vote as Helpful button. Cheers, Rajender Saini Aditi Enterprise Solutions – Partnering Innovation | www.aditi.com
    Thursday, December 9, 2010 11:42 AM
  • what is the point in using C++/CLI ?

    To interface native code - which is presumably why MS are just
    targeting it for that now.

    C++/CLI did add deterministic destruction to managed code - which is a
    big plus when you've come across the issues it can create in a real
    world C# program.

    For me working in c# is much more productive and easy to program for .net framework. 

    I don't think many would disagree with that - but I'm finding that C#
    code can be just as bad as the worst C/C++ code, and the ease of use
    is only an initial saving - you can spend just as long (if not longer)
    finding and fixing other people's C# coding/design issues :(

    Dave

    Thursday, December 9, 2010 1:49 PM
  • After many years with C++, moving to C# is a little weird.  More than a little weird, actually.  In C# everything is a reference, and this causes ‘.’ to be used for everything that in C++ it was separated out into “.”, “->” and “::”.  At least with C++/CLI with the tracking pointers “^”, the pointer concept is still there and works as expected.
     
    Having mastered that, I was in a position to move pretty easily to C#.  But still, C# has weirdness like structs are allocated on the stack and classes are allocated on the heap.  What kind of nonsense is that?  And as David L says, the loss of RAII is a true loss.  IDisposable doesn’t even come close.
     
    I do agree that Visual C# is so much more productive than Visual C++ (even more so with add-ins like ReSharper) that it more than makes up for these kinds of things.  But C# is not all good, and C++ is not all bad.
     
    -- David
     
    "rajendersaini" wrote in message news:eb6877f2-7e49-4a66-bbd0-9c960963960c@communitybridge.codeplex.com...
    what is the point in using C++/CLI ? just to have c++ Syntax to access .net functionality ? why would you do that ? For me working in c# is much more productive and easy to program for .net framework. 

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Thursday, December 9, 2010 2:59 PM
  • After many years with C++, moving to C# is a little weird. More than a little weird, actually. In C# everything is a reference, and this causes ‘.’ to be used for everything that in C++ it was separated out into “.”, “->” and “::”. At least with C++/CLI with the tracking pointers “^”, the pointer concept is still there and works as expected.
     
    Having mastered that, I was in a position to move pretty easily to C#. But still, C# has weirdness like structs are allocated on the stack and classes are allocated on the heap. What kind of nonsense is that? And as David L says, the loss of RAII is a true loss. IDisposable doesn’t even come close.
    Yes, for me one of the saddest things about C# is that it chose to imitate Java, rather than making a better/simpler C++. As it is, some of the best things about C++ (most notably RAII and const correctness) are missing. Not to mention the gratuitous adoption of terms like struct and destructor (with completely different meaning).
     
    In fact I have this fantasy that if C# had been designed differently (using more C++-like syntax in particular), then C++/CLI could have been a superset of both standard C++ and of C#. But perhaps this was just not feasible.
     

    David Wilkinson | Visual C++ MVP
    Thursday, December 9, 2010 4:14 PM
  • Yes, for me one of the saddest things about C# is that it chose to imitate Java, rather than making a better/simpler C++.

    Strangely enough, when it was still called "COOL"  the 'C'-like
    language was described as being a simpler C++ (C++ without the quirks
    IIRC) in a meeting I was in. Dunno what happened to those intentions!

    As it is, some of the best things about C++ (most notably RAII and const correctness) are missing. Not to mention the gratuitous adoption of terms like struct and destructor (with completely different meaning).

    Agreed - and some of it could have so easily been alleviated with
    different terms.

    Dave

    Thursday, December 9, 2010 4:42 PM
  • Well, in the end you may disagree with a lot that I said but that is the nature of opinions.

    But there is one thing I want to be sure of. The way you talked about the STL/Boost and C++ in general made it seem like you thought that C++ and Boost is controlled by Microsoft themselves. I hope this is not true. Boost is an open source project and C++/STL is controled by the C++ standard committee which is a committee under ISO/IEC where Microsoft is a member, but has no real control.

    Second talking about Microsoft making improvements or making a better QT etc, again I hope you really know what you said there. One of the reasons why C++ has a standard is so that it can interoperate with compilers from other vendors. For example the idea is that if you write code for one C++ compiler, then you can compile it on another. So what if Microsoft made improvements? Well, there would be a lot of people who would complain if code uses these specific features because the code is no longer interoperable. This happened a lot with VC6, and even after a lot of improvements VC10 still has conformance issues. I think the best forward movement for VC is to get it much more compliant with the standard. Making a better QT too, do you know why QT is popular? Because it is cross platform. So unless Microsoft could release a better QT which is cross platform then it wont even compete. This is one of the areas where MFC is stuck.

    Well regardless I don't think that things wit C++ are anywhere near as bad as what people think. C/C++ gives power over ease, C# gives ease over power. This is the choice you make and in the end that is what you have to live with.


    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
    Visit my (not very good) blog at
    http://ccprogramming.wordpress.com/
    Thursday, December 9, 2010 4:48 PM
  • Yes, I do realize that STL and Boost are designed by committee.  I think these are overly complex.  Qt is an example of something that puts a sane wrapper around STL so that it is more usable, showing at least STL does not need to be the way it is.  Qt is popular because of its simplicity, usability, consistency, and excellent documentation.  Cross platform is not on that list.  Neither is robustness (parts of Qt are excellent, others need work) or third party widget support.  If MS came up with MFC++ or a new native C++ framework that embraced these concepts, it would be a smashing success even if it were Windows only.  Or maybe, because it was Windows only.  There is still a stiff price to be paid for cross platform support, and Qt is paying it.
     
    The choice of whether to use C++ or C# does not come down to power vs. simplicity alone.  Where I feel the most lost with C# is the fact that when I say I’m a .NET developer, everyone assumes I am doing a Forms Over Data type application.  The IT-centric focus of .NET is so astonishingly tilted toward SQL, etc., there is even a thread going on over at LinkedIn of why someone who calls himself a .NET developer doesn’t know SQL!  C++ has (or at least used to have) a wide range of problem domains that it was ideal for.  Now it is being pitched by MS as being useful only for critical performance, latest OS features, etc.  Leaving the rest of us without a true home.  :-(
     
    I’m glad you don’t think C++ is in a bad state.  I can see if you’re doing the types of things MS still wants you to do, then you are actually doing great with it.  I just don’t see why it is so hard for you to see that this repositioning of C++ is displacing a lot, I would say most, people who used to think VC6 was their best friend back in the 1990’s.
     
    -- David
     
     
    "Crescens2k" wrote
     

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Thursday, December 9, 2010 6:32 PM
  • Hello Eduardo,

    Would you mind letting me know the result of the suggestions? If you need further assistance, feel free to let me know. I will be more than happy to be of assistance.

    Regards,

    Yi


    Yi Feng Li [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, December 14, 2010 3:59 AM

  • Yes, I do realize that STL and Boost are designed by committee.  I think these are overly complex.  Qt is an example of something that puts a sane wrapper around STL so that it is more usable, showing at least STL does not need to be the way it is.  Qt is popular because of its simplicity, usability, consistency, and excellent documentation.  Cross platform is not on that list.  Neither is robustness (parts of Qt are excellent, others need work) or third party widget support.  If MS came up with MFC++ or a new native C++ framework that embraced these concepts, it would be a smashing success even if it were Windows only.  Or maybe, because it was Windows only.  There is still a stiff price to be paid for cross platform support, and Qt is paying it.
     
    The choice of whether to use C++ or C# does not come down to power vs. simplicity alone.  Where I feel the most lost with C# is the fact that when I say I’m a .NET developer, everyone assumes I am doing a Forms Over Data type application.  The IT-centric focus of .NET is so astonishingly tilted toward SQL, etc., there is even a thread going on over at LinkedIn of why someone who calls himself a .NET developer doesn’t know SQL!  C++ has (or at least used to have) a wide range of problem domains that it was ideal for.  Now it is being pitched by MS as being useful only for critical performance, latest OS features, etc.  Leaving the rest of us without a true home.  :-(
     
    I’m glad you don’t think C++ is in a bad state.  I can see if you’re doing the types of things MS still wants you to do, then you are actually doing great with it.  I just don’t see why it is so hard for you to see that this repositioning of C++ is displacing a lot, I would say most, people who used to think VC6 was their best friend back in the 1990’s.
     

    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com

     

    (Disclaimer: personal and possibly poorly thought-out opinions ahead)

    Ugh, David, why are you so hung up on VC6? I used it, too (probably most of any VS versions), and I can't see VC6 being all that good. MFC was the same as today (not very good), ATL was too low-level to be comfortable to use (ATL has gone a lot better since), compiler had quite a bit of quirks to make it quite a bit nonstandard...

    Also, I see why C++/CLI exists, and I think it does hit the perfect spot: interoperability with existing native code. That of course comes with a price: C++/CLI has a two languages in it, classic C++ and the one supporting .NET. And even classic C++ is too much for a lot of people. To me, .NET VM is a world different from C++, and so writing entire .NET apps with C++ just seems silly to me ( but I would reach for it just so that I don't have to implement IDisposable in C#/VB.NET ;-) ). From that standpoint, support for e.g. LINQ in C++/CLI - who cares!?

    I also don't agree with slamming of STL or boost. To me, STL containers are best by far. Not MFC's (these are just eugh! ), not Qt's, not old Borland's containers from (I think) Borland C++ 4.5 for windows. And boost sure is complex, but god-damn well designed.

    Goran.

    Tuesday, December 14, 2010 7:04 AM
  • Hi Goran, VC6 is when using C++ for GUI development had the most momentum.  That’s why I use it as an example.  But it also had the best IDE for MFC apps, but the supporting cast of compiler, MFC, ATL, other libs, etc. has improved since then, you are right.
     
    I would use C++/CLI for all things instead of C#, if I could.  Wouldn’t you?  C++/CLI (the managed part) isn’t more complex than C#.  Actually it is a lot simpler, especially if you already know native C++.  If you don’t, you would just use C# and ignore C++/CLI, so I don’t see what being possibly harder to learn for a newbie has to do with anything.
     
    STL has confusing and ill-named syntax to use.  In that regard, it is not the best.  By setting appropriate initial and growBy sizes, MFC containers can perform as well as STL ones.  So how do you think STL is the best?  As for Boost, look, I’m not looking for a museum piece I can put on a pedestal and admire about how well designed it is.  I’m looking for a practical, go-to library that I can use every day.  Being complex kind of defeats that purpose.
     
    Thanks,
    David
     
     
    "Goran Pušic" wrote in message news:cbcf4e71-f4cf-44fb-aede-02cb90514f49@communitybridge.codeplex.com...

    Ugh, David, why are you so hung up on VC6? I used it, too (probably most of any VS versions), and I can't see VC6 being all that good. MFC was the same as today (not very good), ATL was too low-level to be comfortable to use (ATL has gone a lot better since), compiler had quite a bit of quirks to make it quite a bit nonstandard...

    Also, I see why C++/CLI exists, and I think it does hit the perfect spot: interoperability with existing native code. That of course comes with a price: C++/CLI has a two languages in it, classic C++ and the one supporting .NET. And even classic C++ is too much for a lot of people. To me, .NET VM is a world different from C++, and so writing entire .NET apps with C++ just seems silly to me ( but I would reach for it just so that I don't have to implement IDisposable in C#/VB.NET ;-) ). From that standpoint, support for e.g. LINQ in C++/CLI - who cares!?

    I also don't agree with slamming of STL or boost. To me, STL containers are best by far. Not MFC's (these are just eugh! ), not Qt's, not old Borland's containers from (I think) Borland C++ 4.5 for windows. And boost sure is complex, but god-damn well designed.

    Goran.


    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Tuesday, December 14, 2010 7:52 PM
  • I would use C++/CLI for all things instead of C#, if I could.  Wouldn’t you?

    No, because when it's about pure .NET code, C# is more simple, more prevalent (there's a bigger ... community... behind), and induces less finger pain :-). But I do recognize familiarity (with e.g. C++) as a strong force. For me, it's really more the case of "when in Rome..." than anything else.

    STL has confusing and ill-named syntax to use.  In that regard, it is not the best. 

    Oh. What's confusing/ill named? (Honest question, to me it's just different from e.g. MFC)

    By setting appropriate initial and growBy sizes, MFC containers can perform as well as STL ones.

    Hmmm... Last time I checked, array implementations in MFC still used to grow by 1a fixed 1k amount after some time. This detail, I think, is really silly (and does impact performance for big-ish data sets). STL implementation of vector that comes with MSVC uses a much better "grow by 125%" (or was it 150%? not sure). But to be perfectly honest, I don't care about speed that much. At any rate, it's the choice of the container type that dictates speed, not the implementation.

    So how do you think STL is the best?

    Essentially, due to ïntegration" with iterators and algorithms. (Also bloody cool when used with boost::lambda, even though I can't do that in my current work, it would be too black magic for the rest :-( ). value_type and other typedefs are also cool.

    As for Boost, look, I’m not looking for a museum piece I can put on a pedestal and admire about how well designed it is.  I’m looking for a practical, go-to library that I can use every day.  Being complex kind of defeats that purpose.

    Well, boost is massive, that's for sure. I don't really buy "complex" . Do you mean as in "uses a lot of complex C++ features"? Yeah, I don't like that too much either, but I do sympathize with boost design choices :-).

    But fair enough, Qt is arguably a better "practical, go-to library".

    Goran.


    Tuesday, December 14, 2010 8:21 PM
  • BTW, how can I make text smaller?!
    Tuesday, December 14, 2010 8:21 PM
  • Hi Goran,

    Edit it in HTML Code or

    Copy it to Word, change the font size and paste back.

    Cheers,

    YI


    Yi Feng Li [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, December 17, 2010 2:46 AM
  • Hi,

    C++/CLI is a great addition to C++ (in my opinion) as it allows you to use the functionality of .NET library and interop with native code.

    In my huble personal opinion hard work of going through MFC has tired a large nos of C++ devs and yes evey body feel reluctant to learn new syntax (C++/CLi) after spenting many years learning MFC.

    I may be be wrong totally as I my wxperience in Programming is not nuch.

    Regards

    Adi


    A K
    Tuesday, December 21, 2010 8:56 PM
  • Hi,
     
    C++/CLI is a great addition to C++ (in my opinion) as it allows you to use the functionality of .NET library and interop with native code.
     
    In my huble personal opinion hard work of going through MFC has tired a large nos of C++ devs and yes evey body feel reluctant to learn new syntax (C++/CLi) after spenting many years learning MFC.
     
    I may be be wrong totally as I my wxperience in Programming is not nuch.
    Everything you say is true.
     
    But the unfortunate thing is that Microsoft is only promoting C++/CLI for interrop, not as a first class .NET language for creating GUI applications.
     

    David Wilkinson | Visual C++ MVP
    Tuesday, December 21, 2010 9:54 PM
  • <HTML><HEAD></HEAD> <BODY dir=ltr>
    Hi Goran, sorry for taking so long to reply.  I agree with the C# ecosystem of libraries, add-ins, samples, etc. make it a better way of developing .NET apps than C++/CLI.  But C++/CLI is a better language.  ;)  I really think I cashed in at the right time with VC2005 to learn .NET 2 using C++/CLI as a learning crutch, then to move to C#.
     
    Both C# and Qt have a foreach iterator which is mind blowingly simple and makes STL iterators look really ugly.  (STL is ugly in general.)  I suppose STL’s iterators allow for different iteration schemes and such, but I’m hard pressed to find when I would use those.
     
    The MFC allocation pattern was designed at a time when RAM was scarce and an exponentially increasing allocation strategy like what STL has would have seemed very wasteful at the time.  I agree STL’s strategy is better for modern machines; however, if the typical number of elements that the collection will hold is known at run time, MFC’s collections can be tweaked to approximate this exponential strategy.
     
    To be fair, I haven’t given STL and Boost the time or energy they probably deserve because there are easier ways to get my job done.  If I ever have time to do that, I might start liking them better.  :-)
     
    Cheers,
    David
     
    "Goran Pušic" wrote in message news:cc309a7b-df20-4a22-b7fa-60662f4c6066@communitybridge.codeplex.com...
    I would use C++/CLI for all things instead of C#, if I could.  Wouldn’t you?
     
    No, because when it's about pure .NET code, C# is more simple, more prevalent (there's a bigger ... community... behind), and induces less finger pain :-). But I do recognize familiarity (with e.g. C++) as a strong force. For me, it's really more the case of "when in Rome..." than anything else.
     
    STL has confusing and ill-named syntax to use.  In that regard, it is not the best.
     
    Oh. What's confusing/ill named? (Honest question, to me it's just different from e.g. MFC)
     
    By setting appropriate initial and growBy sizes, MFC containers can perform as well as STL ones.
     
    Hmmm... Last time I checked, array implementations in MFC still used to grow by 1a fixed 1k amount after some time. This detail, I think, is really silly (and does impact performance for big-ish data sets). STL implementation of vector that comes with MSVC uses a much better "grow by 125%" (or was it 150%? not sure). But to be perfectly honest, I don't care about speed that much. At any rate, it's the choice of the container type that dictates speed, not the implementation.
     
    So how do you think STL is the best?
     
    Essentially, due to ïntegration" with iterators and algorithms. (Also bloody cool when used with boost::lambda, even though I can't do that in my current work, it would be too black magic for the rest :-( ). value_type and other typedefs are also cool.
     
    As for Boost, look, I’m not looking for a museum piece I can put on a pedestal and admire about how well designed it is.  I’m looking for a practical, go-to library that I can use every day.  Being complex kind of defeats that purpose.
     
    Well, boost is massive, that's for sure. I don't really buy "complex" . Do you mean as in "uses a lot of complex C++ features"? Yeah, I don't like that too much either, but I do sympathize with boost design choices :-).
     
    But fair enough, Qt is arguably a better "practical, go-to library".
     
    Goran.
     

    </HTML>
    Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com
    Wednesday, December 22, 2010 7:48 PM
  •  
    Both C# and Qt have a foreach iterator which is mind blowingly simple and makes STL iterators look really ugly.  (STL is ugly in general.)  I suppose STL’s iterators allow for different iteration schemes and such, but I’m hard pressed to find when I would use those.

    Yeah, to beat Qt's foreach, std::for_each needs boost::lambda ( or C++0x... erm... I think ;-) ).

    foreach of C#, albeit very practical, just seems bolted on, though. I mean, a language feature that relies on library feature (IEnumberable etc)? That's just... backwards :-( (hey, just like IDisposable!). But hey, I'm in "language purity" land here. ;-)

    Goran.

    Thursday, December 23, 2010 10:07 AM