|
Don't forget now, managed C++ was written in non-managed C/C++
that along should tell you something
|
|
|
|
|
... and C++ was written in C and C was written in assembler ... but you don't use assembler anymore ...
Bye,
Orbital^
...the night is long ... but not long enought to do some real coding ...
|
|
|
|
|
Actually, some of us still do.. 
|
|
|
|
|
Except, C was written in C. 
|
|
|
|
|
Not exactly true. Please read:
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
it's very interesting
Bye,
Orbital^
...the night is long ... but not long enought to do some real coding ...
|
|
|
|
|
Well, you have to start somewhere! But still, the C language itself was created using increasingly powerful compilers written in C.
http://www.cs.bell-labs.com/who/dmr/primevalC.html[^]
At the bottom of the page there's a link to the C source code to a couple of the earliest C compilers. 
|
|
|
|
|
What's wrong with assembler?
|
|
|
|
|
Modern compiles are written in C++.
For example *nix gcc compiler is written in C++ and compiles itself.
|
|
|
|
|
...and when you're done, tell me what MC++ from C++ should be.
Anyway, as cool as it would be to have MC++ compile its own compiler, i doubt MS really cares that much right now.
Shog9
Let your mercy spill / On all these burning hearts in hell
If it be your will / To make us well...
|
|
|
|
|
I am working on a rather large (30,000+ lines) app written in non-managed C++ using the MFC library. I currently have no plans to move to .NET app building. From what I have seen (perhaps in some way I am mistaken?), when working with managed C++, the ISO is severely thrown out the back door because of the additional keywords such as __gc and __super. I have never felt the use in coding under .NET. I think that it is a waste of time to move to something that doesn't seem to serve any benefit to me from something that works just fine. With that said, what do you think the future of non-managed C++/MFC will be in regards to being supported in Microsoft Visual C++ in the future?
bn37
|
|
|
|
|
|
(adding to what I said recently) Also, the managed C++ wizards for adding events for controls place the implementation in the include file. What is up with that? One of the good things about non-managed C++ is that the implementation code is placed in the source file (*.cpp), so that clients using the classes don't have to worry about how it was built (unless they plan to extend the existing functionality). They just read the include file contents and then have the knowledge they need to efficiently use the class.
bneacetp
|
|
|
|
|
last month i attended to small workshop in Seatle. workshop was orginized by ms, intel and hp to promote hp itanium based computers running 64-bit windows.
there were a few software industry big names and some of ms high managment staff, so i'm sure they know what they were talking about (especially businesswise).
when ms guys started their presentation of "new ms approches", like .net, bla-bla-bla, it turned out that most of the attendees were not interested in .net at all.
They have tons of code written with standard c++ and mfc, and have no a little intention to swicth to .net technology.
so, ms guys repeated at least ten times that they have no intention to drop either c++ or mfc.
in addition, recent release of vc++ .net 2003 shows how seriosly ms takes C++ Standard.
|
|
|
|
|
Unmanaged C++ is going to be around for a long, long time. And them some. Most big desktop softwares are still (for the most part) in C/C++. Partly due to legacy, partly due to the power of the language.
Another thing to remember: Microsoft's "cool to crap" cycle is about 2 years. Remember:
- co-operative threading
- MFC?
- ATL?
- VB (now VB.Net, of course)
- etc.
There are people at MS right now talking crap about how obsolete .Net is, I assure you.
|
|
|
|
|
compiler wrote:
Unmanaged C++ is going to be around for a long, long time
Yes and no.
Yes, there are billions of C++ code out there. C++ is running a significant fraction of IT systems around the world. So yes, C++ will be around in a few decades.
No, MS can slash raw C++ and promote MC++ instead. Actually that's exactly what they have done lately. I don't buy the fact that their latest VC++ release is the most standard compliant compiler, at least more than ever. In the same time they have been introducing a lot of proprietary extensions (inline idl attributes for instance), and been promoting the de facto use of them : they are used by default with the project wizards. Of course, in marketing terms, everyone is free not to use the proprietary extensions.
Taking advantage of InternetExplorer to steal user's name and password.
Taking advantage of InternetExplorer to steal user's clipboard.
|
|
|
|
|
Stephane Rodriguez. wrote:
No, MS can slash raw C++ and promote MC++ instead.
Totally "slashing away" ISO C++ support would not be a wise choice for MSFT to make. Managed C++ lacks some of the major qualities of ISO C++ including an organized structure and vast portability.
|
|
|
|
|
|
|
bneacetp wrote:
when working with managed C++, the ISO is severely thrown out the back door
managed C++ != ISO C++.
bneacetp wrote:
the additional keywords such as __gc and __super.
Vendors are allowed to add extra keywords and identifiers that start with underline. This doesn't make them less standard compliant. It's obvious that if you use vendor specific keywords your program will be less portable.
The nice thing about C++ is that only your friends can handle your private parts.
|
|
|
|
|
Eddie Velasquez wrote:
Vendors are allowed to add extra keywords and identifiers that start with underline. This doesn't make them less standard compliant. It's obvious that if you use vendor specific keywords your program will be less portable.
That's all well and good as long as MSFT doesn't stop supporting ISO C++.
|
|
|
|
|
Anonymous wrote:
That's all well and good as long as MSFT doesn't stop supporting ISO C++.
I think that Microsoft has proven (at least I'm satisfied) their commitment to C++ and I think thing can only get better now.
The nice thing about C++ is that only your friends can handle your private parts.
|
|
|
|
|
I am pretty sure non-managed C++ is not going away. I am writing a GINA replacement and I don't believe it is possible to use managed C++. The same goes for device drivers and other low level code.
|
|
|
|
|
Message Closed
modified 22-Dec-15 8:13am.
|
|
|
|
|
gniemcew wrote:
Once a new, feature-rich language that can reduce problem complexity without hard hits on performance is created, C++ (at least as far as Windows o/s family is concerned) might be a goner
I don't know how, since language is not an end. Products are end, and languages are just able to deliver...or not.
Regarding .NET apps, half of them are Winforms apps (whether stand-alone, or smart clients), and I don't see C++ going away in the foreseeable future since Winforms is a thin wrapper around the WIN32 API (common controls, ...). With all the same traps, of course.
In terms of strict language comparison, I believe you have a good point in C# vs C++. Unfortunately, software companies don't care much about this, at least none I have worked for, and none I have heard about. May be that's just me.
I have a university background, and that's pretty much the only place where language grammars and semantics where being studied at length.
Taking advantage of InternetExplorer to steal user's name and password.
Taking advantage of InternetExplorer to steal user's clipboard.
|
|
|
|
|
There's also much more to C++ than just windows programming. I can't imagine any embedded systems or RT stuff ever using .NET...
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
