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"
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)
-
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.
I think this is largely dependent on what kinds of commercial applications you are writing. The ones I work on are not very database dependent and/or use an embedded specialized database. I do agree that things are being integrated into .NET. For the requirements of the apps I've worked on, they aren't all there yet, which is why I said I leaned toward C++/MFC. In a recent case when this issue came up, my question was "what's your release time line?" I said that if it was 18 months, I'd use C++/MFC, especially since it meant I could more easily canabilize parts of the existing app (which is when I did some of the C++/CLI testing to see if that was a solution; it almost was) and we wouldn't have to worry about customers having the .NET 2.0 runtime (this was when it was in beta so availability was a real issue.) If, on the other hand, the release was 3 to 4 years out, C# was the choice. Of course, in the end, they chose C# and wanted in 18 months and then laid off half the total team, including me. They'll get it in 3 to 4 years and it will probably be fine.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Wouldn't a dedicated supercomputer have been cheaper than distributing it over a million seperate machines?
-- Rules of thumb should not be taken for the whole hand.
dan neely wrote:
Wouldn't a dedicated supercomputer
I forgot the $ signs.... We moved from $1million graphics computer (1 box, 4 displays, 16 processors, 1 million dollars), to $50,000 workstation, to $8,000 and lower servers, to any dual core gaming platform now (if it runs the latest games well, and is dual core, it runs our software well).
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
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
ednrgc wrote:
Actually, C# is a merge of C++ and Delphi.
And this is one case where the hybrid is worse than the parents. The C++ world gained nothing but apparently enough people are swallowing the marketing hype. Microsoft learned well from Sun.
The evolution of the human genome is too important to be left to chance.
-
dan neely wrote:
Wouldn't a dedicated supercomputer
I forgot the $ signs.... We moved from $1million graphics computer (1 box, 4 displays, 16 processors, 1 million dollars), to $50,000 workstation, to $8,000 and lower servers, to any dual core gaming platform now (if it runs the latest games well, and is dual core, it runs our software well).
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
Ok, that makes a lot more sense. I didn't think hardware had grown quite that rapidly. FPU performance has gone up a few 1000x since the 486 era, but that was still 3 orders of magnitude short.:-D
-- Rules of thumb should not be taken for the whole hand.
-
Ok, that makes a lot more sense. I didn't think hardware had grown quite that rapidly. FPU performance has gone up a few 1000x since the 486 era, but that was still 3 orders of magnitude short.:-D
-- Rules of thumb should not be taken for the whole hand.
oh... I didn't tell you we are running on carbon nanotube prototype computers at 1 petahz? ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)