Yes: GCC has, in fact, been bootstrapped with a C++ compiler, and works the same that way as when compiled with a C compiler. It took some work, but that work has been done.
It arguably leads to more maintainable code, because you get C++'s stronger type checking.
You can't do non-trivial initialization in the constructor because initializer syntax is not turing complete. Most C++ style guides (such as Google's) suggest using a separate init() function, so it isn't really less lines of code.
A constructor can't fail without throwing an exception. Assuming you don't allow exceptions, your class now needs an internal dead state. This is the case even if you use a separate init(), because the destructor needs to know whether init() was successful (unless of course you use a separate destroy(), making this pointless.)
A destructor can't fail at all. There is no way to indicate failure; you can't throw an exception because the destructor might be called during stack unwinding from another exception. What if the destructor fails to flush a buffer? The C version can simply return a boolean to indicate this.
There is no way to indicate that MyClass should not be inherited, so to allow deletion through a base class pointer (a requirement to satisfy the Liskov substitution principle), your destructor should be virtual. This adds overhead to the class itself, and adds a lot of overhead at the call site if the runtime type cannot be statically inferred.
You now need implement (or at least declare private) copy constructors and operator=. Developers expect C++ objects to be copyable, and standard containers require it.
Don't you see what is going on here? Even the most trivial feature of C++, constructors, are horribly ridden with complications. C++ is a language of never-ending surprises, gotchas, land mines. It's a trap.
Let's knock those down one at a time.
From the constructor's initialization list you can call arbitrary functions. Whether you should or not is another matter, but it's certainly possible.
You can make your constructor take a bool& succeeded parameter if you really can't allow exceptions. (Or even an Error reference.) No worse than C, often better.
Destructors can and do fail, but if you want to detect failure instead of ignoring it you should call a function explicitly. No worse than C, often better.
You can indicate in a number of ways that MyClass cannot be inherited from; documentation should suffice, but there is also a silly trick you can use if you think that technical solutions to social problems are a good idea. Even without that, you don't need to allow deletion through the base class; just make its destructor protected.
If you use resource classes to hold resources (which, it turns out, makes your code cleaner and simpler) then you don't need to do anything about implementing copy operations; the compiler just does the right thing. For your resource classes, you do need to implement them, but there are relatively few such classes, and they're simple.
It is a library for generic algorithms, decoupled from data structures via STL's notion of iterators (which is rather different from GoF iterators). As a proof of concept it happens to provide some containers that work pretty well.
C makes bitwise copies. C++ makes memberwise copies (and in simple cases, can optimize that to a bit copy). In C++ you'd hold a smart pointer, and copying that would do the right thing (whatever the smart pointer defines it to do: ref counting, causing a compilation error, making a copy of the target).
Copy operations in C++ would probably not be implicit, if it weren't for the fact that they're implicit in C.
Different name mangling between different compilers is deliberate, and a good thing: it stops you linking together code that uses incompatible ABIs, and then getting strange crashes.
Now, if you want to complain that it took too long to standardize ABIs for C++, and that it's too hard, and that they're not stable enough, then you might well be able to make a pretty strong case, but that's a different thing. If your ABIs don't match, you shouldn't make your name mangling match.
(Incidentally, if you code in a sane way then the implicit copy operations _almost_ always do the right thing. It would still be better if we had to explicitly enable them, but that would have broken C compatibility, or made struct vs class into two different worlds.)
The ANSI C committee adopted const from C++ in time for the first ANSI C standard, 21 years ago (sadly not calling it "readonly").
(You make a valid point about not having to use every C++ feature to get benefits from using some, and I believe that the plan is to be conservative in introducing features that are helpful while avoiding more controversial or complex features.)
If you're using Firefox then this bug is/will be fixed in Firefox 3.6, so that it will report the correct website when things are slow instead of saying "Waiting for *.google-analytics.com. See https://bugzilla.mozilla.org/show_bug.cgi?id=487638 for the details; "status bar blames wrong resource when downloading slow responding resource" is the title of that bug.
If you're using other browser(s), let me know which.
Full disclosure: Google is my employer (and I care about making sure Google Analytics isn't slow).
It's been many years since most C++ compilers used C as an intermediate language. CFront did, and some EDG-based compilers do, but most current C++ compilers do not.
C does have its strengths, such as the relative simplicity of C90 and its lack of dependency on sophisticated compilers and runtimes, but its use as an IL is largely historical.
It can be GPL without allowing use to produce non-free software, as AdaCore's GPL releases of GNAT are. The trick is that the runtime library has a license, and is needed to run any generated code. If that library is GPL, then you can't use generated code other than in GPL products. You *could* write a replacement runtime library, and then use the GPL-licensed compiler for non-free software -- but normally that's too much work.
(And some opinions too; I'll leave you to work out which are facts and which are opinions.)
It's the UK's panel that has submitted this paper to ISO; the UK panel is part of BSI, the British Standards Institute, one of the NB's (National Bodies) making up ISO.
The biggest problem is that ISO should not publish two standards which are for such different languages with such similar names, and encourage the confusion. Standards are there to reduce confusion, not to contribute to it.
And make no mistake, C++/CLI is a huge departure from the core language. It introduces a whole new type of pointer, it adds generics to C++ templates, it abandons const-correctness for core using "ref" classes, it has yet another string type (this time somewhat integrated into the language rather than being a pure library entity), it adds mandatory garbage collection (C++ has always permitted, but not required, GC, though with some caveats) in a way not consistent with previous work with GC in C++, and there's more I'm sure.
It's also a concern that C++ may wish to expand into areas overlapping with those that are covered by Microsoft's language "C++/CLI", and may not wish to do so in the same way as C++/CLI, which is mostly just one of a pile of vendor-specific extensions to C++.
ISO is about standardizing existing practice. Some of the biggest problems with existing C++ and C standards has been when they got too inventive, and accepted into the standards things that were implemented in few (or no) compilers. So far as I know, there's still only one compiler that supports C++/CLI (though I've a feeling one other company is working on one).
Microsoft and the ISO C++ groups have been getting along a lot better in the last few years; Microsoft returned to attending committee meetings, and hired some great people, both names that get publicity and some that don't. However, Microsoft is still a large company with a monopoly in certain areas, and some history of anticompetitive practices, and it seems sensible for us to tread carefully.
Firstly, I'm going to thank you for the existence of Slashdot. Something over 100,000 people found the site before I did, but I've been a reader on and off for a few years, and Slashdot is my homepage on at least one browser. Whatever might be said about the signal:noise ratio, it's good enough for me to keep coming back.
Your point about it taking little time for a reader to cut+paste a URL when mailing you is a valid one; it saves much more time (that time happening to be yours) than it takes, and the time used is spread across all those who mail you, so each gives up very little. It's also a basic courtesy when taking up someone else's time to try to make things easy for them.
A similar argument can be applied to why it's more important than it might initially seem to work on grammar, spelling and typos. If it takes 5 minutes to check these for an article, or an hour, that might save a second or two for each of 10,000 or 100,000 people who might read the piece of Slashdot's front page. If it saves a second for each of 10,000 people, that's 30,000 seconds, or around 8 person-hours that it's saved. If it's a couple of seconds, and 100,000 people, then we're talking 200,000 seconds, or 55 person-hours. The typos often do make me do a double take, and make it hard to understand the meaning of a piece straight away. Even "its" or "it's" affects readability.
That's not even to mention that the time lost in dealing with complaints probably exceeds the time it would have taken to avoid them in the first place by eliminating the recurring errors (fix "its/it's" and "to/too" and most of the rest probably wouldn't disturb me) -- sure, people will still complain about things, but they'll complain about slightly fewer things.
Maybe you could offer grammatically correct versions to paid subscribers, and continue to torment the cheap *******s among us who read Slashdot for free?
Right, hence "could" rather than "does". The difference is that C has a broader definition of null pointer constant, allowing the zero-valued integral constant expression to be cast to void* -- and my point is that implicit conversions from void* to other pointer types is a red herring.
C++ doesn't have implicit conversions from int to pointer (or pointer-to-member-function) types either, however a null pointer constant (which is an integral constant expression evaluating to 0) can be converted to either precisely because of a special rule, which could just as easily apply to (void*)0 as well, making C++ match C in this one case.
So POSIX threads don't predate Java in this respect.
And pthreads aren't quite pervasive enough to count as "might as well be part of the language" -- I've worked on many C implementations that did not have pthreads capabilities, even though a good fraction of them did have some kind of threading.
Before telling people they're ignorant, it's good to be sure of your own information.
For example, I'm tempted to say that the POSIX committee is being disbanded, but I don't have official confirmation of that so I'll just mention it as a possibility at this time.
One mistake (Was: Re:Explanation)
on
Java Faster Than C++?
·
· Score: 2, Informative
Almost no C++ implementation calls the OS (kernel) for every memory request, precisely because that's too slow.
More to the point, C++ doesn't *have* to use dynamic allocation so often, but in badly written code it may well do so, and that will hurt performance. In C++ you can drop objects on the stack, in Java you can't. Heap/GC allocation can be pretty quick, but not quite as quick as stack allocation.
Seem to polarize people. I think "The C++ Programming Language" is very readable, and many agree -- but just as many find it opaque and unreadable.
Anyone who blindly tells people not to look at Stroustrup's "The C++ Programming Language" is commiting a grave disservice. The best thing to do is to look at it, and if it doesn't strike you as being readable, to look elsewhere.
My review of Thinking in C++
on
Practical C++
·
· Score: 1
It's good value at $0.00, but it's not a great book on C++.
I think it was the second edition I reviewed. My comments have been given to the folks who are to produce the next edition, so hopefully it'll do a better job of living up to the hype. It would be great to have a quality tutorial on C++ available online at no cost, and I do have to give Mr Eckel credit for using this distribution channel (which I'm sure gives him a lot of good publicity for the printed version).
If you've moved to a 64-bit platform, it's often because you need access to every bit of memory and performance you can get. Increasing cache misses and filling your memory by having larger datasets because of longer wordsizes isn't a trade-off to be taken without careful consideration.
On the other hand, most of the systems I know that use >= 4GB of RAM are databases, and pointers make up a tiny fraction of the memory footprint.
Read the article -- it has plenty of measurements of performance to keep you happy.
Sure, I find it absurd to spend thousands of dollars/pounds on cables -- but to me it's worth a hundred or so to connect my CD player to my amp, because I can hear the difference very clearly. I was surprised to find that I can also hear, quite clearly, the difference when my CD player is moved between different types of shelves.
The 'audiophile' world is mad, but not generally for lack of measurements. It's the insanely non-linear price/performance that's ludicrous.
Thank you for taking the time to respond. Certainly building all of the code with multiple compilers is a good step -- and a recent gcc with -ansi -Wall is a sensible choice for one of those compilers.
It's likely that I will do an extensive technical review of the Secure Programming Cookbook at some time, and have it posted to the ACCU website (http://www.accu.org/) as well as my own website (less publicized). I'll let you know of any bugs I find.
I bought a copy of the Building Secure Software book, and it wasn't a bad read -- but the one flaw I did see was the code examples, which had too many correctness issues to be considered secure. The first rule of writing secure code in C or C++ is to avoid reliance on undocumented behaviour. "void main" is a nonstandard extension, casting from a char* to an int* without knowing if the alignment is suitable is undefined behaviour, and so on. Unfortunately I don't have my review notes from this book with me, so I can't give all of the specific defects I found in the code snippets.
Could this code not be reviewed by a C or C++ "expert" before publication? At least someone who can spot things that could cause a compilation failure or a core dump?
Paying is reasonable, but paying the same for an upgrade from 10.2 to 10.3 as someone might pay to upgrade from Mac OS 9 to 10.3 is not.
It ought to be cheaper to get an upgrade of the same OS (Mac OS X) than to upgrade from a different OS (Mac OS 9, say).
I'll probably upgrade, as it won't be too long before software will not run on 10.2, but I'll be less likely to buy hardware from Apple again. I'll switch back to Linux. 10.2 was a big improvement on 10.1, which was frankly still of alpha quality (or beta if you want to flatter it). The biggest thing I'd like to see in 10.3 is that it would crash less often. I've seen far too many panic screens with 10.1 and 10.2.
Those who say "you don't have to upgrade" are missing one vital point: you don't have to, but if you don't you can't count on being able to run the applications software you want in a year or two.
Slashdot Mirror
Yes: GCC has, in fact, been bootstrapped with a C++ compiler, and works the same that way as when compiled with a C compiler. It took some work, but that work has been done.
It arguably leads to more maintainable code, because you get C++'s stronger type checking.
There are many problems with your example.
Don't you see what is going on here? Even the most trivial feature of C++, constructors, are horribly ridden with complications. C++ is a language of never-ending surprises, gotchas, land mines. It's a trap.
Let's knock those down one at a time.
It is a library for generic algorithms, decoupled from data structures via STL's notion of iterators (which is rather different from GoF iterators). As a proof of concept it happens to provide some containers that work pretty well.
C makes bitwise copies. C++ makes memberwise copies (and in simple cases, can optimize that to a bit copy). In C++ you'd hold a smart pointer, and copying that would do the right thing (whatever the smart pointer defines it to do: ref counting, causing a compilation error, making a copy of the target).
Copy operations in C++ would probably not be implicit, if it weren't for the fact that they're implicit in C.
Different name mangling between different compilers is deliberate, and a good thing: it stops you linking together code that uses incompatible ABIs, and then getting strange crashes.
Now, if you want to complain that it took too long to standardize ABIs for C++, and that it's too hard, and that they're not stable enough, then you might well be able to make a pretty strong case, but that's a different thing. If your ABIs don't match, you shouldn't make your name mangling match.
(Incidentally, if you code in a sane way then the implicit copy operations _almost_ always do the right thing. It would still be better if we had to explicitly enable them, but that would have broken C compatibility, or made struct vs class into two different worlds.)
The ANSI C committee adopted const from C++ in time for the first ANSI C standard, 21 years ago (sadly not calling it "readonly").
(You make a valid point about not having to use every C++ feature to get benefits from using some, and I believe that the plan is to be conservative in introducing features that are helpful while avoiding more controversial or complex features.)
(Reposting, logged in this time.)
If you're using Firefox then this bug is/will be fixed in Firefox 3.6, so that it will report the correct website when things are slow instead of saying "Waiting for *.google-analytics.com. See https://bugzilla.mozilla.org/show_bug.cgi?id=487638 for the details; "status bar blames wrong resource when downloading slow responding resource" is the title of that bug.
If you're using other browser(s), let me know which.
Full disclosure: Google is my employer (and I care about making sure Google Analytics isn't slow).
It's been many years since most C++ compilers used C as an intermediate language. CFront did, and some EDG-based compilers do, but most current C++ compilers do not.
C does have its strengths, such as the relative simplicity of C90 and its lack of dependency on sophisticated compilers and runtimes, but its use as an IL is largely historical.
It can be GPL without allowing use to produce non-free software, as AdaCore's GPL releases of GNAT are. The trick is that the runtime library has a license, and is needed to run any generated code. If that library is GPL, then you can't use generated code other than in GPL products. You *could* write a replacement runtime library, and then use the GPL-licensed compiler for non-free software -- but normally that's too much work.
(And some opinions too; I'll leave you to work out which are facts and which are opinions.)
It's the UK's panel that has submitted this paper to ISO; the UK panel is part of BSI, the British Standards Institute, one of the NB's (National Bodies) making up ISO.
The biggest problem is that ISO should not publish two standards which are for such different languages with such similar names, and encourage the confusion. Standards are there to reduce confusion, not to contribute to it.
And make no mistake, C++/CLI is a huge departure from the core language. It introduces a whole new type of pointer, it adds generics to C++ templates, it abandons const-correctness for core using "ref" classes, it has yet another string type (this time somewhat integrated into the language rather than being a pure library entity), it adds mandatory garbage collection (C++ has always permitted, but not required, GC, though with some caveats) in a way not consistent with previous work with GC in C++, and there's more I'm sure.
It's also a concern that C++ may wish to expand into areas overlapping with those that are covered by Microsoft's language "C++/CLI", and may not wish to do so in the same way as C++/CLI, which is mostly just one of a pile of vendor-specific extensions to C++.
ISO is about standardizing existing practice. Some of the biggest problems with existing C++ and C standards has been when they got too inventive, and accepted into the standards things that were implemented in few (or no) compilers. So far as I know, there's still only one compiler that supports C++/CLI (though I've a feeling one other company is working on one).
Microsoft and the ISO C++ groups have been getting along a lot better in the last few years; Microsoft returned to attending committee meetings, and hired some great people, both names that get publicity and some that don't. However, Microsoft is still a large company with a monopoly in certain areas, and some history of anticompetitive practices, and it seems sensible for us to tread carefully.
Firstly, I'm going to thank you for the existence of Slashdot. Something over 100,000 people found the site before I did, but I've been a reader on and off for a few years, and Slashdot is my homepage on at least one browser. Whatever might be said about the signal:noise ratio, it's good enough for me to keep coming back.
Your point about it taking little time for a reader to cut+paste a URL when mailing you is a valid one; it saves much more time (that time happening to be yours) than it takes, and the time used is spread across all those who mail you, so each gives up very little. It's also a basic courtesy when taking up someone else's time to try to make things easy for them.
A similar argument can be applied to why it's more important than it might initially seem to work on grammar, spelling and typos. If it takes 5 minutes to check these for an article, or an hour, that might save a second or two for each of 10,000 or 100,000 people who might read the piece of Slashdot's front page. If it saves a second for each of 10,000 people, that's 30,000 seconds, or around 8 person-hours that it's saved. If it's a couple of seconds, and 100,000 people, then we're talking 200,000 seconds, or 55 person-hours. The typos often do make me do a double take, and make it hard to understand the meaning of a piece straight away. Even "its" or "it's" affects readability.
That's not even to mention that the time lost in dealing with complaints probably exceeds the time it would have taken to avoid them in the first place by eliminating the recurring errors (fix "its/it's" and "to/too" and most of the rest probably wouldn't disturb me) -- sure, people will still complain about things, but they'll complain about slightly fewer things.
Maybe you could offer grammatically correct versions to paid subscribers, and continue to torment the cheap *******s among us who read Slashdot for free?
Right, hence "could" rather than "does". The difference is that C has a broader definition of null pointer constant, allowing the zero-valued integral constant expression to be cast to void* -- and my point is that implicit conversions from void* to other pointer types is a red herring.
C++ doesn't have implicit conversions from int to pointer (or pointer-to-member-function) types either, however a null pointer constant (which is an integral constant expression evaluating to 0) can be converted to either precisely because of a special rule, which could just as easily apply to (void*)0 as well, making C++ match C in this one case.
Not to be confused with the "shar" shell archive format.
So POSIX threads don't predate Java in this respect.
And pthreads aren't quite pervasive enough to count as "might as well be part of the language" -- I've worked on many C implementations that did not have pthreads capabilities, even though a good fraction of them did have some kind of threading.
Before telling people they're ignorant, it's good to be sure of your own information.
For example, I'm tempted to say that the POSIX committee is being disbanded, but I don't have official confirmation of that so I'll just mention it as a possibility at this time.
Almost no C++ implementation calls the OS (kernel) for every memory request, precisely because that's too slow.
More to the point, C++ doesn't *have* to use dynamic allocation so often, but in badly written code it may well do so, and that will hurt performance. In C++ you can drop objects on the stack, in Java you can't. Heap/GC allocation can be pretty quick, but not quite as quick as stack allocation.
Spec is a vague term. If you need to be clear, say whether you mean a specification of the requirements, or a specification of some aspect of design.
Seem to polarize people. I think "The C++ Programming Language" is very readable, and many agree -- but just as many find it opaque and unreadable.
Anyone who blindly tells people not to look at Stroustrup's "The C++ Programming Language" is commiting a grave disservice. The best thing to do is to look at it, and if it doesn't strike you as being readable, to look elsewhere.
It's good value at $0.00, but it's not a great book on C++.
i n- c++.txt
http://www.jamesd.demon.co.uk/reviews/thinking-
I think it was the second edition I reviewed. My comments have been given to the folks who are to produce the next edition, so hopefully it'll do a better job of living up to the hype. It would be great to have a quality tutorial on C++ available online at no cost, and I do have to give Mr Eckel credit for using this distribution channel (which I'm sure gives him a lot of good publicity for the printed version).
If you've moved to a 64-bit platform, it's often because you need access to every bit of memory and performance you can get. Increasing cache misses and filling your memory by having larger datasets because of longer wordsizes isn't a trade-off to be taken without careful consideration.
On the other hand, most of the systems I know that use >= 4GB of RAM are databases, and pointers make up a tiny fraction of the memory footprint.
Read the article -- it has plenty of measurements of performance to keep you happy.
Sure, I find it absurd to spend thousands of dollars/pounds on cables -- but to me it's worth a hundred or so to connect my CD player to my amp, because I can hear the difference very clearly. I was surprised to find that I can also hear, quite clearly, the difference when my CD player is moved between different types of shelves.
The 'audiophile' world is mad, but not generally for lack of measurements. It's the insanely non-linear price/performance that's ludicrous.
Answered in the comp.std.c++ FAQ.
http://www.jamesd.demon.co.uk/csc/faq.html
Thank you for taking the time to respond. Certainly building all of the code with multiple compilers is a good step -- and a recent gcc with -ansi -Wall is a sensible choice for one of those compilers.
It's likely that I will do an extensive technical review of the Secure Programming Cookbook at some time, and have it posted to the ACCU website (http://www.accu.org/) as well as my own website (less publicized). I'll let you know of any bugs I find.
I bought a copy of the Building Secure Software book, and it wasn't a bad read -- but the one flaw I did see was the code examples, which had too many correctness issues to be considered secure. The first rule of writing secure code in C or C++ is to avoid reliance on undocumented behaviour. "void main" is a nonstandard extension, casting from a char* to an int* without knowing if the alignment is suitable is undefined behaviour, and so on. Unfortunately I don't have my review notes from this book with me, so I can't give all of the specific defects I found in the code snippets.
Could this code not be reviewed by a C or C++ "expert" before publication? At least someone who can spot things that could cause a compilation failure or a core dump?
Paying is reasonable, but paying the same for an upgrade from 10.2 to 10.3 as someone might pay to upgrade from Mac OS 9 to 10.3 is not.
It ought to be cheaper to get an upgrade of the same OS (Mac OS X) than to upgrade from a different OS (Mac OS 9, say).
I'll probably upgrade, as it won't be too long before software will not run on 10.2, but I'll be less likely to buy hardware from Apple again. I'll switch back to Linux. 10.2 was a big improvement on 10.1, which was frankly still of alpha quality (or beta if you want to flatter it). The biggest thing I'd like to see in 10.3 is that it would crash less often. I've seen far too many panic screens with 10.1 and 10.2.
Those who say "you don't have to upgrade" are missing one vital point: you don't have to, but if you don't you can't count on being able to run the applications software you want in a year or two.