|
|
(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
|
|
|
|
|
Another thing to remember is that Microsoft themself has invested a lot in the C++ language. Programs such as Windows, Internet Explorer, FrontPage, and Word are all written in C++. For them to stop supporting the language, that would be an extreme hit to them. Also, most other programmers in C++ are not anxious to move to any other language like C# or Visual Basic because they don't see the need or benefits great enough to do. When what you are using is all that you need for what you are doing, why look any further? It is just common sense. 
|
|
|
|
|
Microsoft will always release new API's in Win32 C/C++ first, then release .NET wrappers. Win32 C/C++ is not going anywhere and its rediculous to think it will be replaced by .NET. Microsoft will not be writing its key applications in .NET just like they never wrote them with MFC either.
Over time, yes, there will be more and more .NET programmers and applications but underneath it all, there is always Win32 and there will always be a demand for the smallest, light weight applications possible.
Others have already made the point about device drivers and real-time systems.
Where you will start to see lots of .NET development is for business logic and solutions. Much like how MS has always tried to position Visual Basic 6 and below: as a middle tier language. They are also positioning .NET so that it lowers the skill-level entry point for developers that never had access to advanced programming constructs such as threading.
I personally feel this is dangerous, especially in my company.. Now all the ASP developers are creating threads whenever it makes them happy on the web server and killing it. Kinda like how Win16 developers went thread happy when we went to Win32. At least VB6 kept the threading under control. But thats another story 
And UGH! I'm so irritated that MSDN focuses so heavily on .NET. It has become really b o r i n g.
|
|
|
|
|
Weren't 2 of the "big" benefits of .NET
1.) XCOPY installation
2.) Freedom from .DLL Hell
Shock  Horror  can it be  that it's not quite there yet 
Phil Harding
|
|
|
|
|
What's truely shocking is, how few people called MS on this - seriously, XCOPY deployment is a simple concept - eliminate non-standard dependancies & you're there. DOS had XCOPY deployment. Statically linking in Windows gets you most of the way there also. And once .NET has a wider install base, you'll be able to get XCOPY on that also... so long as you write to the right version.
You'd think no-one had ever used Java...
Shog9
Let your mercy spill / On all these burning hearts in hell
If it be your will / To make us well...
|
|
|
|
|
Phil Harding wrote:
1.) XCOPY installation
Two things kill this one:
1. The registry.
2. The .NET runtime (which still has to be installed on many, maybe even most, customer machines)
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Tried installing .NET on a W2K machine. Nothing worked. My client had to install that darn development environment just to get the app running. Who knows what magic it did, but installing just dotnetfx didn't do the trick. Yeah, we went through every service pack update you could think of that Microsoft suggested: IE, W2K SP6, ... Everything. Still no go until we installed the development tools. Good grief.
Now, we ship turnkey systems to our customers. How can you possibly expect a dance club owner to install all these service packs, upgrades, and redistributions?
Marc
Every line of code is a liability - Taka Muraoka
A doable project is one that is small enough to be done quickly and big enough to be interesting - Ken Orr
CPP Script Framework Design Page
Latest AAL Article
My blog
|
|
|
|
|
Marc Clifton wrote:
My client had to install that darn development environment just to get the app running.
It's a known issue. Having a .NET app to work requires [20MB, 180MB] of run-times before it works, depending on the application.
The bad news is that, often, the error message box, or exception, doesn't say anything about what's wrong. What else could we expect from a beta product anyway?
Marc Clifton wrote:
Who knows what magic it did, but installing just dotnetfx didn't do the trick.
Might be the app relying on some .NET SDK tool like gacutil only to flash the GAC or something. gacutil is not installed with dotnetfx.exe.
[Edit]Other tools that might be used when the app starts are : aximp.exe, tlbimp.exe, ...[/Edit]
If the machine does not have local admin priviledge, then you might consider tweaking the .NET config panel. For instance, if the app uses [DllImport] somehow on a non-admin session, then by default the app is not allowed to execute untrusted code. Failure.
[Edit]After double-checking, this is only an issue with apps running in web pages.[/Edit]
May be some Primary Interop Assemblies are wrecked, badly versioned, etc. How to figure it out ? Good question!
etc. the list goes on forever.
|
|
|
|
|
I hope...
Was out of blank CDs, so i copied it onto a stack of floppies & tied a stack to the legs of each one. Tossed 'em off of the the roof & they were on their way. Haven't gotten a one back yet though, so it must be a long trip... or maybe they're having some installation problems, never know. Hopefully they finish before too many service packs come out though, or their next trip's gonna be a heavy load...
Shog9
Let your mercy spill / On all these burning hearts in hell
If it be your will / To make us well...
|
|
|
|
|
|
Well you know, I think that .NET is just part of the greater move of Dumbing Down, by those unseen movers and shakers of society 
Seriously though .NET .SCHMET, it's all objects in it! object this, object that, toString this toString that! Whats wrong with proper capitalisation thats what I want to know 
And References  , References they're for girls they are (no sexual discriminatory detrementation intended, sexual meant in a purely asexual context), there's no way you can tell me they're easier to understand than void pointers to pointers to arrays of elements of pointers to structures!
You .NET boys don't know you're born, back in the day all we had was GOTO and GOSUB, and 8" floppy disks, and we wuz grateful for them too!
Phil Harding
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
