|
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
|
|
|
|
|
GOSUB? ooooh, la-de-da Mister Fancy Pants.
8" floppies? be gone ya lazy git!
Back in my day, we didn't have subroutines... or persistant storage. I'd enter the program in the morning, one long string of code, and when the machine powered off at night it'd be gone & i'd have to start all over. And i liked it, no, i LOVED it, kept typing 'till my fingers were worn down to nubs & then used my tongue until i wore my head down to my navel, all the while spitting out a constant stream of code.
Peh. Indolent VB monkey...
Shog9
Let your mercy spill / On all these burning hearts in hell
If it be your will / To make us well...
|
|
|
|
|
Shog9 wrote:
Peh. Indolent VB monkey...
He asked for it! And once again, Shog has provided a most appropriate response.  
Chris Meech
"what makes CP different is the people and sense of community, things people will only discover if they join up and join in." Christian Graus Nov 14, 2002.
"And when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks." Joel on Software Nov 11, 2002.
|
|
|
|
|
What, you mean you actually got to enter stuff ON the computer? Why, when I was your age, we didn't get to sit at the fancy pants computer. We had to enter all our stuff on a deck of punch cards! THen wait for a week to get the results. Realize you had one bit of code wrong, and have to enter all of 'em in again!
And you know what? The old timers would break us newbies in by taking our decks and playing poker with them! I don't know how many times I've been told, never draw to an inside FOR loop. It's always a losing bet.
"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
|
|
|
|
|
I'm happy Vc++ 6 coder and I feel no need to use .NET.
1. now I see it has big runtime and AFAIK can't make applications for W95
2. I can't see any advantage, maybe only HTML dialog
3. I'm lazy to learn it
rrrado
|
|
|
|
|
See my response to your previous posting.
|
|
|
|
|
Everyone writing Windows software will eventually use .NET, at least through MC++ rather than C# or oh!  my goddish VB.NET or whatever esotheric language.
Why? at least because soon Microsoft won't offer any other alternative. They are turning off, silently slowly and firmly, all "WIN32" SDKs off from their download sites.
The CLR has an amazing amount of classes you can rely on. They let you build software without having to rewrite everything from scratch. So, the software is quicker out. My concern is demoware versus reliable software (when you read CLR's architect take about CLR reliability, you can question it. Really).
That said, there are bottlenecks :
- Winforms totally suck. The 1.x implementation is really poor, so everyone writing projects.
- huge memory overhead because of the GC
- huge start time
- code made obsolete quickly once it is out (see my post below)
- ...
What's also important is the perception that complex projects is still a hard job that no developing world people can tackle.
For instance, everything regarding COM interop and P/Invoke is so lousily managed in the CLR 1.x that it leaves the door open for us people in our 30s to be able to sell our knowledge to solve problems that VB-people won't ever. That's good news.
|
|
|
|
|
"Free me from DLL Hell" was one of ms's early .NET ads... ironic isnt it? I just installed VS .NET and besides fiddling with C# (which lacks any basic support for interactio w/ the file system) I still have vc 6 open 99.9% of the time.
|
|
|
|
|
I think you haven't use c# at all. Lack of support for interaction with the file system?
Before saying such things bother to read the docs or a simple google search would be enough.
Anyway, the vs.net ide for c++ (managed and unmanaged) it is way better than version 6.0
I compile my vc 6 projects on .net now, unmanaged code.
|
|
|
|
|
Talking about the IDLE for the C++ development, lets say VS6 and VS7 to understand, the VS7 is too different from the VS6, MFC seems improved (for sample the HTML help file format), but the developing environment seems a bit messy for who is developing big projects with the VS6.
Keyboard mapping, windows positioning and functional concepts are changed and they require a bit of time for the "old" programems to move in this new environment.
I don't want to say that it's best of worse, but who uses VS6 knowing a lot of basic shortcut key's will find the new VS7 a bit difficult to use.
Another point is the starting time of the VC IDLE environment. Normally I moove from 1 poject to another really fast to copy and paste of code here and there. The VS7 is really heavy to start.
Talking about C#, for a C++ programmes it seems a new king of VB where the machine is quite "far" from what a C++ programmer is aspecting. Most of the people of the "old" programmes are asking "why a new language?".
In my case, honestly if go back in time, I must reconyze that I was considered a genios because I was the first programmer in C/C++ of my company, and I've converted everybody... but if I think it well, C/C++ was a big challange in the beginning to make the application "do what I want to do!"; the pointer concept was so difficult to understand, and know I'm not able to program without these things: "ok I'm old!".
Lets say that going to work in JAVA or C# gives me the impression that I'm "going back".
So, to move from VS6 C++ to VS7 C# is not a easy process, and requires time for a person like me and others that answered to this survey.
Now as now, I have the impression that for the application I'm making and my overall productivity, I prefer to keep working on my "old" VS6 with C++ for the "Windows based application".
I have to add that 80% of my customers are still working with W98 or W/NT, and it will be difficult for them to migrate, because in their case they have to change the base machines (a lot of money!). I don't feel to tell them to change their machines. But all of them have a common point: a web browser!
So, for the "new applications", I'll do my best to convince my customers to go on a web based application and not work with C# Windows frame based application. But let's clear one point: this is "my interest", I don't want to discuss that C++ is better than C# or viceversa, but I don't have time and interest to move in C#!
Reading here and there, there are 2 kind of answers: "C# if cool and easy to redistribute" and "why do I have to move in C#?".
Probably both of these kind of answer must be analyzed in their context!
Andy
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
