The big problem with the C++ committee is that most of the members don't want to admit the language has major problems. Neither does Strostrup, who has written that only minor corrections are needed.
In fairness, I think his view (at least as I've seen it expressed) is that only minor changes are needed to the language, as distinct from making changes to the library (where things like proper concurrency support etc. very much are on the cards).
C++ itself isn't that bad. The language could be fixed.
I agree and disagree, respectively.
C++ is actually pretty good at what it's meant for. The problem is usually that it's being used by the wrong people for the wrong job. The fact that half the C++ world is stuck in a time warp and insists on ignoring the past ten years of its development really doesn't help matters.
On the other hand, clearly it's vastly underpowered compared to some other popular languages today:
The STL is crippled without some genuine support for first-order functions/closures.
The text data support is a joke.
It doesn't have any real support for disjunctive types or pattern matching either.
You can get a library to do just about anything, but by God it's hard work, and some libraries are more portable than others.
And of course, the syntax is horrible: it tends towards Perl line noise, but without the power and conciseness that make Perl so useful.
But can this sort of problem be fixed yet still leave a language that is C++? I don't think so. You can't just bolt these things onto an existing framework. They have to be an integral part of the language design, its supporting libraries, and its programmers' mentality.
What C++ needs is some hardass in a position to slam a fist on the table and say "Fix it so our software doesn't crash all the time". It doesn't have one.
I don't believe anyone could do that effectively, starting from where we are. As you say, everyone's busy playing with templates, which are all very nice for the elite and may result in a few nice(r) libraries, but which are sod all use to the vast majority of programmers actually using C++ for their day-to-day development. That area is still suffering from readability problems, and silly limitations on basic tools (enumerations, for example).
I think what's really needed, in the medium term, is a replacement that goes up a level, learning from what has and hasn't worked well in C++. I don't think the next big language will be another variation on the C theme with extra bits added on: that was a smart move in C++'s infancy, but as Python shows so well, a language with a reasonably clean syntax can become useful and popular quite quickly, even if it's quite different from what went before, and commits a few "cardinal sins" (someone's sig around here used to read "Friends don't let friends use whitespace as punctuation" IIRC).
None of the direct competitors in recent years has really moved that far ahead of C++. I consider adding a GC to be an evolutionary or sideways move, not revolutionary. Several of the other much heralded changes in the Java and C# languages have been steps backwards, which they're now desperately trying to fix, or will given time.
No, the next big language for mainstream, mid- to large-scale development will look quite different to C++, Java and C#. It will have a clean, programmer-friendly syntax, but one supported by sound underlying models. In particular, it will learn from C++ and provide for "multi-paradigm design" or whatever it's called tomorrow, but with much better support for modular programming and arbitrary calling conventions (including distributed programming). It will have a small but high quality standard library, which will provide the essentials and then establish a framework for more powerful stuff to plug into. It will also
I think you misunderstood what I was trying to say..
So it would seem.:-)
I did not expect to do any "work in industry" with the outdated tools, but simply evaluate them to decide which I should be using to learn C programming with.
Fair enough, but your original post said that you wrote fairly standards-compliant code, which worked in all the C compilers but not in VC++. Since the latter is a C++ compiler (though IIRC some versions can also be switched to pure C) and there was no C++ standard at the time version 6 was released, there must be a flaw in this logic somewhere...
I was taking WPO into account. [...] But this is disabled by default.
OK, thanks, I think I understand your argument now. For some reason, I thought WPO was on by default in VC++.Net 2003, but having just tried it, you're right: it appears to be disabled in favour of the extra run-time checks, since you can't have both at once. In that case, comparing object files makes a lot more sense.
That said, I'm still not sure why it's more useful than comparing the executables at the end of the process. Even if WPO isn't enabled, unless you know more about the internals of the VC++ tool chain than I do, I don't see how we can be sure it's a fair test. Unless I've missed something (which is quite possible, of course) there's not even any guarantee that the object files produced by VC++ and GCC will have similar formats.
OK. Either I'm misunderstanding you, or we have different fundamental definitions of what "pass-by-reference" (as distinct from passing a reference in C++) means. Can you give a robust description of pass-by-value and pass-by-reference as you define them?
I realise GCC has some platform-specific support, but a lot of the optimisation code seems to be a distant second compared to dedicated Wintel compilers. I don't see any other explanation for the bloated and/or slow code that GCC seems to produce a significant amount of the time, compared to say Intel's own C++ compiler.
(As an aside, I've never particularly understood why this should be the case, since most optimisations apply far higher up the compilation process anyway. It appears, at least on the evidence I've seen myself, that it is the case, however.)
The fact is that I, today, believe that people should be free to rule themselves to the greatest extent possible.
And yet in forcing this belief upon others, you seek to rule them instead of letting them rule themselves, violating the very principle you claim to advocate.
My question wasn't nearly as transparent as you think.
Perhaps they're on dial-up and can't afford to spend four hours online downloading the most recent version, or they want to get a word in before the story falls off the front page.
That's funny, because I'm on dial-up and it takes me hours to download new versions of things, too. Strangely, I don't find myself posting crap based on knowledge seven years out of date in an effort to sound clever, though.
So, when comparing object files you compare the result of the compiler and not the whole tool-chain.
Sorry, but I think you're missing my point. In the new version of VC++, a significant amount of what we would normally call "compilation" isn't done in the compiler, it's done in the linker, because of the extra optimisation logic I mentioned. Comparing object files isn't a fair test in this case: it's apples and oranges.
Erm... You want a specific example of standards compliance?
OK: I can write
int i = 10;
and this creates an object of type int with the default value of 10.
Your response is meaningless. The only relevant examples here are places where VC++ 7.1 is not standards compliant, and it's up to you to find them. Off you go, now, and do please come back when you've got a constructive point to add to the conversation.
Really? Can you identify a concrete example where they have other semantics? Assuming you can, is your example in any way relevant to this discussion?
The standard implementation of references in damn near every C++ compiler on the planet is as a pointer that cannot have a NULL value. Obviously there are other semantic differences between references and pointers in theory, but issues like retargetting the pointer to refer to another object are irrelevant here -- we're talking about how to achieve pass-by-reference semantics in C, and pointers are the universal answer.
It runs in the same vein as their licensing and releasing Services for UNIX - essentially an admission that CMD.EXE is not everyone's cup of tea as a command interpreter and that, to be frank, for proper scripting, it's actually pretty shit.
And here I was thinking it was just an excuse to say SFU to all the *nix-heads.:-)
The compiler requires.Net, and hence only runs on platforms that.Net supports (though IIRC it can still produce output code targetting older platforms).
If I compare object sizes instead of final executable sizes, G++ in deed produces smaller code than vc++ compiler. Excellent.
Huh? What's the object size got to do with anything? Do you distribute.obj files for your application? Are they what get loaded into memory and executed when your program is run?
The current version of VC++ does some quite clever tricks with "whole program optimization". To do this, part of the compilation effectively moves to the linker. That means a lot more information has to be passed through in the object files, though of course it's still compiled down to finished code in the output.exe file.
It didn't just suck "5 versions ago". It continued to suck even in version 6 which many commercial products still use.
So it only sucked around 7-8 years ago, then?
I have not tried the 7.0/7.1 versions to see how well it fares now.
It's amazing how many people on this thread are slamming VC++ because of behaviour it had in the mid-90s (that's version 6 in case you've lost count) and freely admit to not having tried the most recent version, which is the subject here. I know people don't usually RTFA on Slashdot, but you might at least try to get the slightest bit of background information before wading in with absurdly incorrect extrapolations based on software nearly a decade old!
Just so you don't make even more of a fool out of yourself: VC++.Net is vastly more standards compliant than VC++6 (which was released before the ISO C++ standard was finished, incidentally). Microsoft have apparently been making a genuine effort to improve this aspect of their product, and have already recruited/bought out (depending on your personal philosophy) at least two big names in the C++ world.
The litigation stuff related to the standard library they were using back in version 6, and is ancient history.
And as for comparison with EDG, yes, they'll lose, because EDG is the only pretty much fully standards compliant game in town. VC++ is now close enough for most practical purposes, though; nobody uses things like export anyway.
Do I still want to write non-portable code in 2004? Apparently MSVC produces better code then gcc on Windows, but is that reason enough to use it rather than (e.g.) cygwin?
Yes, if your target market happens to be using Windows. There's nothing to stop you writing standard, portable code and simply using Microsoft's compiler to build it on that particular platform, of course.
(If you were including libraries and so on when you wrote "100% portable", then you're never going to reach that target anyway, and you do the same as everyone else who's played this game before: wrapper any external APIs in your own code, so that the effort to move to a different library on a different platform is minimized.)
How exactly is giving an industry-leading compiler away for free, knowing that doing so is going to promote development on your own platform, even possibly going to stave off a second round of an anti-trust case?
Microsoft's move makes a lot of business sense for them, for several reasons that I and others have pointed out elsewhere in this thread, but I can't see it having anything to do with their legal position.
One has to assume MS is worried they're losing their development community to run a scheme like this.
I'm guessing that's the case. For people playing at home, a copy of Visual Studio.Net costs several hundred new, so I'm betting that a very high proportion of home users don't have it. Since a lot of businesses have been nervous about upgrading -- the 2002 edition of VS.Net was a disaster, and while it's much better, there are a few quirks left in the 2003 one -- it's in Microsoft's interests to have the pro's playing at home, so they can go into the office and recommend an upgrade for all 100 developers at work afterwards.
On top of that, of course, it's also in Microsoft's interests to try and shift the Windows developer population towards.Net and away from things like MFC and COM. They clearly realise this won't happen overnight, and have repeatedly denied the imminent demise of MFC, but surely it must be their long term plan.
I'm still new to C (coming from a Pascal background), and this language scares me.. I feel as if I'm yielding [sic] just a little more power then a programmer _should_ have access to for writing queues, linked lists, and 50 different sorting algorithms (damn Algorithms class).
But that power is the whole point of C. If you don't need that level of control, you should probably be using another, higher-level language.
Of course, your situation is different because you're studying, and whether or not you choose to use such a powerful but dangerous language for real projects, you should certainly be aware of the issues raised by it. The number of people in this business who don't understand simple computer science concepts because they learned Java and can't grok pointers is scary; the number of bugs they produce is scarier; and their willingness to blame their lack of understanding on a particular programming language is scarier still.
Slashdot Mirror
In fairness, I think his view (at least as I've seen it expressed) is that only minor changes are needed to the language, as distinct from making changes to the library (where things like proper concurrency support etc. very much are on the cards).
I agree and disagree, respectively.
C++ is actually pretty good at what it's meant for. The problem is usually that it's being used by the wrong people for the wrong job. The fact that half the C++ world is stuck in a time warp and insists on ignoring the past ten years of its development really doesn't help matters.
On the other hand, clearly it's vastly underpowered compared to some other popular languages today:
But can this sort of problem be fixed yet still leave a language that is C++? I don't think so. You can't just bolt these things onto an existing framework. They have to be an integral part of the language design, its supporting libraries, and its programmers' mentality.
I don't believe anyone could do that effectively, starting from where we are. As you say, everyone's busy playing with templates, which are all very nice for the elite and may result in a few nice(r) libraries, but which are sod all use to the vast majority of programmers actually using C++ for their day-to-day development. That area is still suffering from readability problems, and silly limitations on basic tools (enumerations, for example).
I think what's really needed, in the medium term, is a replacement that goes up a level, learning from what has and hasn't worked well in C++. I don't think the next big language will be another variation on the C theme with extra bits added on: that was a smart move in C++'s infancy, but as Python shows so well, a language with a reasonably clean syntax can become useful and popular quite quickly, even if it's quite different from what went before, and commits a few "cardinal sins" (someone's sig around here used to read "Friends don't let friends use whitespace as punctuation" IIRC).
None of the direct competitors in recent years has really moved that far ahead of C++. I consider adding a GC to be an evolutionary or sideways move, not revolutionary. Several of the other much heralded changes in the Java and C# languages have been steps backwards, which they're now desperately trying to fix, or will given time.
No, the next big language for mainstream, mid- to large-scale development will look quite different to C++, Java and C#. It will have a clean, programmer-friendly syntax, but one supported by sound underlying models. In particular, it will learn from C++ and provide for "multi-paradigm design" or whatever it's called tomorrow, but with much better support for modular programming and arbitrary calling conventions (including distributed programming). It will have a small but high quality standard library, which will provide the essentials and then establish a framework for more powerful stuff to plug into. It will also
Fair point, but you can just tell VC++ to link the library statically for comparison purposes.
So it would seem. :-)
Fair enough, but your original post said that you wrote fairly standards-compliant code, which worked in all the C compilers but not in VC++. Since the latter is a C++ compiler (though IIRC some versions can also be switched to pure C) and there was no C++ standard at the time version 6 was released, there must be a flaw in this logic somewhere...
OK, thanks, I think I understand your argument now. For some reason, I thought WPO was on by default in VC++.Net 2003, but having just tried it, you're right: it appears to be disabled in favour of the extra run-time checks, since you can't have both at once. In that case, comparing object files makes a lot more sense.
That said, I'm still not sure why it's more useful than comparing the executables at the end of the process. Even if WPO isn't enabled, unless you know more about the internals of the VC++ tool chain than I do, I don't see how we can be sure it's a fair test. Unless I've missed something (which is quite possible, of course) there's not even any guarantee that the object files produced by VC++ and GCC will have similar formats.
OK. Either I'm misunderstanding you, or we have different fundamental definitions of what "pass-by-reference" (as distinct from passing a reference in C++) means. Can you give a robust description of pass-by-value and pass-by-reference as you define them?
I realise GCC has some platform-specific support, but a lot of the optimisation code seems to be a distant second compared to dedicated Wintel compilers. I don't see any other explanation for the bloated and/or slow code that GCC seems to produce a significant amount of the time, compared to say Intel's own C++ compiler.
(As an aside, I've never particularly understood why this should be the case, since most optimisations apply far higher up the compilation process anyway. It appears, at least on the evidence I've seen myself, that it is the case, however.)
Because first they came for the Jews, but I was not a Jew, and did nothing.
And then they came for the black men, but I was not a black man, and did nothing.
And then they came for the women, but I was not a woman, and did nothing.
...
And then they came for me, and there was no-one left to defend me.
And yet in forcing this belief upon others, you seek to rule them instead of letting them rule themselves, violating the very principle you claim to advocate.
My question wasn't nearly as transparent as you think.
That's funny, because I'm on dial-up and it takes me hours to download new versions of things, too. Strangely, I don't find myself posting crap based on knowledge seven years out of date in an effort to sound clever, though.
Sorry, but I think you're missing my point. In the new version of VC++, a significant amount of what we would normally call "compilation" isn't done in the compiler, it's done in the linker, because of the extra optimisation logic I mentioned. Comparing object files isn't a fair test in this case: it's apples and oranges.
Erm... You want a specific example of standards compliance?
OK: I can write
and this creates an object of type int with the default value of 10.Your response is meaningless. The only relevant examples here are places where VC++ 7.1 is not standards compliant, and it's up to you to find them. Off you go, now, and do please come back when you've got a constructive point to add to the conversation.
Really? Can you identify a concrete example where they have other semantics? Assuming you can, is your example in any way relevant to this discussion?
The standard implementation of references in damn near every C++ compiler on the planet is as a pointer that cannot have a NULL value. Obviously there are other semantic differences between references and pointers in theory, but issues like retargetting the pointer to refer to another object are irrelevant here -- we're talking about how to achieve pass-by-reference semantics in C, and pointers are the universal answer.
Obviously I was referring to something like this:
The semantics here are absolutely identical to passing a reference in C++, except for the additional & and *.
It's worth noting that Borland, too, only give away their command line compiler for free. You can't (legally) get the IDE without paying for it.
And here I was thinking it was just an excuse to say SFU to all the *nix-heads. :-)
The compiler requires .Net, and hence only runs on platforms that .Net supports (though IIRC it can still produce output code targetting older platforms).
Huh? What's the object size got to do with anything? Do you distribute .obj files for your application? Are they what get loaded into memory and executed when your program is run?
The current version of VC++ does some quite clever tricks with "whole program optimization". To do this, part of the compilation effectively moves to the linker. That means a lot more information has to be passed through in the object files, though of course it's still compiled down to finished code in the output .exe file.
So it only sucked around 7-8 years ago, then?
It's amazing how many people on this thread are slamming VC++ because of behaviour it had in the mid-90s (that's version 6 in case you've lost count) and freely admit to not having tried the most recent version, which is the subject here. I know people don't usually RTFA on Slashdot, but you might at least try to get the slightest bit of background information before wading in with absurdly incorrect extrapolations based on software nearly a decade old!
Just so you don't make even more of a fool out of yourself: VC++.Net is vastly more standards compliant than VC++6 (which was released before the ISO C++ standard was finished, incidentally). Microsoft have apparently been making a genuine effort to improve this aspect of their product, and have already recruited/bought out (depending on your personal philosophy) at least two big names in the C++ world.
The litigation stuff related to the standard library they were using back in version 6, and is ancient history.
And as for comparison with EDG, yes, they'll lose, because EDG is the only pretty much fully standards compliant game in town. VC++ is now close enough for most practical purposes, though; nobody uses things like export anyway.
You know that copying it over Kazaa from your mate down the corridor is illegal, right? ;-)
Yes, if your target market happens to be using Windows. There's nothing to stop you writing standard, portable code and simply using Microsoft's compiler to build it on that particular platform, of course.
(If you were including libraries and so on when you wrote "100% portable", then you're never going to reach that target anyway, and you do the same as everyone else who's played this game before: wrapper any external APIs in your own code, so that the effort to move to a different library on a different platform is minimized.)
How exactly is giving an industry-leading compiler away for free, knowing that doing so is going to promote development on your own platform, even possibly going to stave off a second round of an anti-trust case?
Microsoft's move makes a lot of business sense for them, for several reasons that I and others have pointed out elsewhere in this thread, but I can't see it having anything to do with their legal position.
I'm guessing that's the case. For people playing at home, a copy of Visual Studio .Net costs several hundred new, so I'm betting that a very high proportion of home users don't have it. Since a lot of businesses have been nervous about upgrading -- the 2002 edition of VS.Net was a disaster, and while it's much better, there are a few quirks left in the 2003 one -- it's in Microsoft's interests to have the pro's playing at home, so they can go into the office and recommend an upgrade for all 100 developers at work afterwards.
On top of that, of course, it's also in Microsoft's interests to try and shift the Windows developer population towards .Net and away from things like MFC and COM. They clearly realise this won't happen overnight, and have repeatedly denied the imminent demise of MFC, but surely it must be their long term plan.
OK, I give up. What did you mean by that?
But that power is the whole point of C. If you don't need that level of control, you should probably be using another, higher-level language.
Of course, your situation is different because you're studying, and whether or not you choose to use such a powerful but dangerous language for real projects, you should certainly be aware of the issues raised by it. The number of people in this business who don't understand simple computer science concepts because they learned Java and can't grok pointers is scary; the number of bugs they produce is scarier; and their willingness to blame their lack of understanding on a particular programming language is scarier still.