Is MC++ a serious contender
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
I don't hear much about managed C++. It gets even less attention than un-managed C++.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
Phil Harding wrote:
does anyone here use MC++ for any significant aspects of "commercial" software developmen
Still using MS C++ for most development, but that is a legacy thing. We are slowing switching some stuff like the GUI, it seems to be the case that most people aren't considering C++ for .NET development. I am sure Nish has quiet a bit to say on this.
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
MC++ was meant as an interim technology, and its syntax was rather ugly. C++/CLI is the C++ for the managed world. I'm writing some wrapper classes for some unmanaged functionality using C++/CLI, and those wrapper classes will be used by a commercial component I am creating. It's a rather small portion of the code, but a vital one. I don't plan to use C++/CLI for most typical dev work, however - I like C# much better for most things.
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
First of all there is nothing called MC++ any more, it all got deprecated and became C++/CLI. I have used it only as a thin thunking layer from unmanaged C++ to C#. It does not make sense to write fully managed applications in C++/CLI as it is far more easy to do the same job in C# for various reasons including IDE support. MS advertises that you can compile an entire C++ application into IL but it is not at all practical to do so. For example the size of one of the small application in my application suite jumped to more than twice the regular size when I did so. So it is stupid to do so. I have used C++\CLI to support hosting of managed controls in MFC applications. It is true that C++\CLI is fastest for interop. But if you have too much interop between native and managed code in your application you are in a problem the first place. May be in that case managed code might not be the option.
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
We use it for unit testing (it allows us to use NUnit to test native code), but not for production code.
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
-
First of all there is nothing called MC++ any more, it all got deprecated and became C++/CLI. I have used it only as a thin thunking layer from unmanaged C++ to C#. It does not make sense to write fully managed applications in C++/CLI as it is far more easy to do the same job in C# for various reasons including IDE support. MS advertises that you can compile an entire C++ application into IL but it is not at all practical to do so. For example the size of one of the small application in my application suite jumped to more than twice the regular size when I did so. So it is stupid to do so. I have used C++\CLI to support hosting of managed controls in MFC applications. It is true that C++\CLI is fastest for interop. But if you have too much interop between native and managed code in your application you are in a problem the first place. May be in that case managed code might not be the option.
I have used it only as a thin thunking layer from unmanaged C++ to C#. I intend to do the same thing - adding c# assemblies to a C++ project. I am not too clear about where to start. Are there any articles/samples here on the CP or elsewhere that might be of help? Thank you Vaclav
-
First of all there is nothing called MC++ any more, it all got deprecated and became C++/CLI. I have used it only as a thin thunking layer from unmanaged C++ to C#. It does not make sense to write fully managed applications in C++/CLI as it is far more easy to do the same job in C# for various reasons including IDE support. MS advertises that you can compile an entire C++ application into IL but it is not at all practical to do so. For example the size of one of the small application in my application suite jumped to more than twice the regular size when I did so. So it is stupid to do so. I have used C++\CLI to support hosting of managed controls in MFC applications. It is true that C++\CLI is fastest for interop. But if you have too much interop between native and managed code in your application you are in a problem the first place. May be in that case managed code might not be the option.
Rama Krishna Vavilala wrote:
it all got deprecated and became C++/CLI
My spider-sense detects the masterful touch of the Microsoft Product Naming Division somewhere in there... :rolleyes: :laugh:
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.4 [^]: A free RSS/Atom feed reader with support for Code Project.
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
Phil Harding wrote:
I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++
Me too. The whole managed C++ thing was a disaster, and now, the ship has sailed.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
Phil Hardingdoes anyone here use MC++ for any significant aspects of "commercial" software development?
I don't know... is this[^] significant? It is a niche market, per se. Most of the games, scientific visualization, military and engineering visualization and design work is done in C++. edit: ahhh, the reference is actually to managed C++, not C++ in general... nope, no managed C++.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
-
Phil Hardingdoes anyone here use MC++ for any significant aspects of "commercial" software development?
I don't know... is this[^] significant? It is a niche market, per se. Most of the games, scientific visualization, military and engineering visualization and design work is done in C++. edit: ahhh, the reference is actually to managed C++, not C++ in general... nope, no managed C++.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
As has been pointed out, MC++ was deprecated and it's now C++/CLI. Unfortunately, the latter is still rather convoluted. It does have the advantage that you can compile regular C++ code and it sometimes, smartly, produces native code. In some very limited testing, I was able to get an tight algorithm run twice as fast in C++/CLI than in C# (it ran 4x faster in pure native code than C#.) I still prefer the cleaner syntax of C#. As for "mainstream Windows development activities", it all depends what market you're talking about. For internal corporate apps, unless you have an overwhelming reason to use C++, I feel C#.NET is the best choice. For commercial shrink-wrapped apps, I still lean toward C++/MFC--the framework, third parties libraries (like CodeJock and so forth) are just too plentiful and rich. Plus it's still easier to find C++ experts than C# experts (no matter what those claiming C# expertise may say--note that I believe that with few exceptions you can't be an expert in anything in less than seven years.) (I am hopeful that .NET 4.0 will finally add all the missing pieces so you don't have to resort to bloated third party libraries like Infragistics [didn't like it, but your mileage may vary] and even my own MRU class posted here on CodeProject.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
ednrgc wrote:
Most C++ developers/shops have moved to C#.
Albeit at gunpoint in many cases. Since C# is essentially VB in sheep's clothing (or is that redundant?), most C++ folks will miss the power and control that comes from an unrestricted language. However, since we do this for a living and must keep our skills current with whatever trend the job market is currently bending to, then C# it is.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
ednrgc wrote:
Most C++ developers/shops have moved to C#.
Albeit at gunpoint in many cases. Since C# is essentially VB in sheep's clothing (or is that redundant?), most C++ folks will miss the power and control that comes from an unrestricted language. However, since we do this for a living and must keep our skills current with whatever trend the job market is currently bending to, then C# it is.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
Since C# is essentially VB in sheep's clothing
Actually, C# is a merge of C++ and Delphi. Anders brought the best of Delphi with him when he left Borland. It is definitely not VB. In fact, many VB programmers are fuming that they have to leave the kiddie table and use a "grown up" language now. :-D
-
Jeffry J. Brickley wrote:
I don't know... is this[^] significant?
Is this the megaapp you're working on?
-- Rules of thumb should not be taken for the whole hand.
dan neely wrote:
Is this the megaapp you're working on?
That's the only child I will ever raise from birth.... ;) It was just me, and help from a part-time mathematician who didn't understand graphics (but I could tell him what I wanted and what I had, and he would help me get there) back in the days of the 1st generation project. "The Virtual Test Range (VTR)" in 1994 on a top-of-the-line SGI box, By 1999 it was the Common Console Advanced Graphics Engine, which was the first desktop product, though it still required $50,000.00 ea. boxes (which still beat 1 million $ ea. for the VTR). RAGE, with the Real-Time Advanced Graphics Engine with RAVE (Real-Time Augmented Video Engine) and other plugins are where we are now. Team of one and a half to a team of half a dozen plus twice that in part-time experts to call upon for ideas/assistance. -- modified at 15:13 Wednesday 10th January, 2007
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
As has been pointed out, MC++ was deprecated and it's now C++/CLI. Unfortunately, the latter is still rather convoluted. It does have the advantage that you can compile regular C++ code and it sometimes, smartly, produces native code. In some very limited testing, I was able to get an tight algorithm run twice as fast in C++/CLI than in C# (it ran 4x faster in pure native code than C#.) I still prefer the cleaner syntax of C#. As for "mainstream Windows development activities", it all depends what market you're talking about. For internal corporate apps, unless you have an overwhelming reason to use C++, I feel C#.NET is the best choice. For commercial shrink-wrapped apps, I still lean toward C++/MFC--the framework, third parties libraries (like CodeJock and so forth) are just too plentiful and rich. Plus it's still easier to find C++ experts than C# experts (no matter what those claiming C# expertise may say--note that I believe that with few exceptions you can't be an expert in anything in less than seven years.) (I am hopeful that .NET 4.0 will finally add all the missing pieces so you don't have to resort to bloated third party libraries like Infragistics [didn't like it, but your mileage may vary] and even my own MRU class posted here on CodeProject.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
For commercial shrink-wrapped apps, I still lean toward C++/MFC--the framework, third parties libraries (like CodeJock and so forth) are just too plentiful and rich.
I have to disagree here, I wrote many commercial apps in c++ and one of the happiest benefits of moving to c# was the plethora of cheap, small and infinitely better support and more functional 3rd party component libraries for .net. The day I consigned Crystal Reports to the burial grounds was a happy day for me. Many of the 3rd party apps and libraries that I ever used with c++ / MFC stuff were things that are integrated in .net now anyway.
-
Thinking of the MSDN magazine posts (John Cardinal's post in particular) and the sad loss of Paul DiLascia's C++ column, does anyone here use MC++ for any significant aspects of "commercial" software development? I am/was a committed C++ guy, but strangely, when doing .NET development (and indeed when first starting .NET) I automaticallly went for C#, not even considering MC++ :confused: I suppose the question I'm sub-consciously asking is "is C++ now in or destined for niche markets, for mainstream Windows development activities"
Frankly I'm very surprised at the attitudes reflected in the replies you got, just a year ago this would have turned into a major flame war of some kind. Personally I think it's just a "right tool for the job" situation. .Net is the best choice right now for business application development which is what I mostly do. When I first laid eyes on it it felt like Microsoft had designed it specifically for me so there was no question about moving to it and in turn c# because though I had written millions of lines of code in c++ I was perfectly happy to embrace C#, my feeling at the time was that I could finally get on with the job which was producing software and spend less time constantly worrying about niggly aspects like memory management, pointers, tortuous syntax etc which are jobs which I'm happy to delegate to the computer itself, life is too short to be forced to screw with that stuff. I'm sure it's a big paradigm shift for those programmers that are in love with the technical aspects of how processors and memory work, but though I've always had a good knowledge of that aspect of it I'm far more interested in what I can actually *do* with the computer than micromanaging how it works.
-
dan neely wrote:
Is this the megaapp you're working on?
That's the only child I will ever raise from birth.... ;) It was just me, and help from a part-time mathematician who didn't understand graphics (but I could tell him what I wanted and what I had, and he would help me get there) back in the days of the 1st generation project. "The Virtual Test Range (VTR)" in 1994 on a top-of-the-line SGI box, By 1999 it was the Common Console Advanced Graphics Engine, which was the first desktop product, though it still required $50,000.00 ea. boxes (which still beat 1 million $ ea. for the VTR). RAGE, with the Real-Time Advanced Graphics Engine with RAVE (Real-Time Augmented Video Engine) and other plugins are where we are now. Team of one and a half to a team of half a dozen plus twice that in part-time experts to call upon for ideas/assistance. -- modified at 15:13 Wednesday 10th January, 2007
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
