Trust me, vendor lock-in is never good for the consumer.
Right now, my phone, my wife's phone, my tablet, my e-reader, and more all have the same (micro-USB) connector. Audio output for all is a 3.5mm jack. Video (for those that have it) is HDMI.
No adapters, no special plugs, no nothing needed.
When I need to charge on the road, and don't have a cable (happened this month), someone always has a micro-USB.
And each device comes from a different manufacturer. Beautiful.
Apple is certainly making things much easier as it refines the design of its products. On the other hand, they also actively trying to prevent people from opening the things up (with specialized screws). It's an interesting dichotomy.
The only reasonable explanation I can think of is that they want to make things easier for themselves (refurbishing and repairing is cheaper), but at the same time they want to reduce competition and discourage the DIY crowd so they have to pay Apple for all fixes.
So, for your car analogy, it's like making everything under the hood easier to work with, but then locking the hood itself.
Well, at least now it's possible to obtain the key (screwdriver) without too much hassle, but the barrier still exists regardless, and it's the attitude that worries me more.
I don't know why people seem to think the iDevice batteries are hard to replace
History. ifixit's instructions for the original iPhone are illustrative: "Getting the iPhone open is a challenging feat, so don't get discouraged. Take a deep breath and make sure you have plenty of time to get the job done." The competition required just sliding a cover and pulling out the battery, which takes five seconds, tops.
But, it's gotten easier. Three or four screws (two on the outside, one or two on the inside) and you're done. Of course, they now use "penalobe" screws, which you usually have to replace because they strip so easily.
The point remains that Apple actively tries to prevent users from replacing the battery. This has nothing to do with making the battery bigger (which, at best, is a pleasant side effect).
Let me add two more: make room for others to merge, and don't force me to move around.
Some drivers think that's it's ok to force their way around as they change lanes, etc. Slowly pushing their way between two cars where no room exists, for example. Tailgating also fits in this category. So does slowing down to piss of the person tailgating you. Instead, let's just be courteous on the road... is that too much to ask?
Both C and C++ standards allow for other parameters to main():
The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters: int main(void) {/*... */ } or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared): int main(int argc, char *argv[]) {/*... */ } or equivalent;10) or in some other implementation-defined manner.
An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: int main() {/*... */ } and int main(int argc, char* argv[]) {/*... */ } In the latter form argc shall be the number of arguments passed to the program from the environment in which the program is run. If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbss) (17.5.2.1.4.2) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "". The value of argc shall be non-negative. The value of argv[argc] shall be 0. [ Note: It is recommended that any further (optional) parameters be added after argv. —end note ]
You're right that there are some minor differences here. The value of argv[argc], for example. Is a C implementation required to support both basic forms? I'm not sure.
In C, however, the parameters to main() can be just about anything the implementation wants. In C++, other parameters are allowed, with the recommendation that additional parameters be placed after argv.
Meaning, the implementation is free to add extra parameters like:
int main(int argc, char *argv[], char *envp[])
or not have a parameter specification like:
int main()
Or just about anything else, in both C and C++. However, a return type of int is required.
GCC is doing the right thing. BTW, if you're in a freestanding environment, -ffreestanding disables the warning about 'void main' (as well as doing a few other important things).
(However, your point about not using a compiler to verify the standard is very much correct, even if we disagree on this particular situation.)
C and C++ (from my reading of the latest standards) are virtually identical: they both require main to return an int in a hosted environment. In a freestanding environment, the startup function can be called by any name and with any return type that the implementation wants.
Thus, for hosted environments, 'void main' is specifically disallowed and GCC is doing the right thing.
Now, let's talk about freestanding environments. To say that void main() is "perfectly valid C" isn't quite right. It's certainly allowed under the C11 and C++11 standards, but by no means is GCC required to support it, as it's an implementation defined feature, and very target-dependent to begin with.
So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.
And the reason for this is, of course, efficiency. Creating space for local variables is as simple as moving a stack pointer. Initializing them to 0 just takes extra time. Uninitialized static variables belong to a special section of the executable (bss in elf format) that quickly and automatically initializes to 0. None of this is specified by the C standard, but the standard was written to accommodate these optimizations.
I believe there's one exception, which is the initialization of pointers declared as static. These are initialized to NULL, not 0. While generally the same, some bizarre architectures have a different bit pattern for NULL. The GP's idea of memset everything to 0 is technically a bad idea for any structure that has a pointer, although it should be fine for most any modern CPU.
It's always an employee's market for the top talent, who are usually in demand regardless of the rest of the job market. The trick is knowing whether or not you're in that special pool. A lot of people think they are... most are wrong.
No, I'm starting to think that text fields can be a form of CLI, but only when you add keyboard shortcuts into the mix. Keyboard shortcuts muddy the waters enough that I don't think you can consider that interface to be a pure GUI (though I don't think the term CLI quite applies, either).
The result of "c++ = c" depends on the type of c and whether the return value of the increment operator returns a value that is assignable from a value of the type of c. However, if c is an int or other primitive type, "c++ = c" gives a syntax error as c++ is not an l-value.
Operator overloading... wonderful if used right, but you can certainly do weird stuff with it, too.
In the case of "c++ == c"... I believe the standard specifies this as undefined behavior, since you're incrementing and reading the value of c in the same statement, and I don't believe there's a sequence point to make the statement valid.
Put it this way... when a C coder writes something in Java, it usually works even if it looks ugly. When a Java coder writes something in C, it's usually leaks memory like a sieve, only works with the specific inputs that they used to test, constantly walks off the ends of arrays, breaks when you cough too loudly, and took forever to write.
Here's why: you can pretty much translate C code into Java without too much hassle, as most of C is a simple subset. A few syntax changes here and there, and you're done. Any language or library features that Java doesn't have can be redone in a different way, which is something most C programmers are comfortable doing.
Translating Java to C is another matter. First you have to think about memory allocation, which is a concept that the original Java didn't have to worry about. But the bigger problem is the relatively thin standard library for C vs Java. You have to hand-code a lot of stuff that Java has by default. Like dynamic lists, for example. What a C coder has to do every day, many Java programmers haven't had to deal with at all. And the end result is ugly, buggy code.
Re:Maybe because it compiles down to the metal...
on
What's To Love About C?
·
· Score: 4, Insightful
One of the best features about C++ is that you can define your own subset that you'll use. Don't want to use RTTI? Then don't! Worried about exception handling? Then don't use them! This is why C++ can never be slower than C -- in the end, just reduce that subset until you get to C and you're done. Beware, though, some of the features you just left out might actually improve performance over the C equivalent!
However, this subset has to be defined on a project basis, and not left for individual programmers to decide for their own code.
For example: the STL iterators use the same interface as pointers, which then lets you use templated algorithms that can accept an STL iterator or pointers into an array.
Another example: your templated function needs to call fabs() on some variable of type T. Overloading lets the compiler pick the right one, even if it's a user-defined type.
Overloading doesn't deserve the bad reputation. As long as you use it as a tool for specific reasons, it's wonderful to have. The most commonly-cited problem people have is when people overload operators (although this problem extends to any overloaded function) to do weird and unexpected things. Fortunately, this problem is discussed enough that it's rare to see someone do bad things with overloading.
To exclude, I usually use something like: `find . -name '.svn' -prune -o -name '*.c' -print` (searches for all.c files, ignoring the ones in the.svn directories)
I don't have much experience with Total Commander, so forgive my ignorance here. But from my experience, most GUI tools recognize a need but can only provide a partial solution for very specific cases ("Oh, you want to rename a lot of files? Well, here's a batch rename utility! Oh, you want to append the current time into the file name? Well, here's a variable that will expand to the date! Oh, you want the time to be in WHAT format? A different Timezone? Well, let me provide a special menu for that..."). Anticipating every need and providing a GUI interface for each is impossible.
The beauty of a command line with a modern shell is that it makes very odd, one-off situations possible. I have yet to see a GUI utility that can do that without providing a textual interface.
To use a computer is to program it. This applies grandmothers just as much as it applies to software engineers.
I'd better explain myself, though.
If you think about it, clicking around a GUI is really just giving instructions to the computer on what you want it to do. For example, let's say someone opens a file in Word... load this file, change this text (by typing something in and clicking where it should be inserted), save the file. Most applications are little more than command interpreters. They just happen to abstract the command sequence out to something very high level like mouse clicks, and leave out more powerful features (like looping). You even get one variable to play with: the clipboard. Sometimes more complex things can be built-in (search/replace), but each of these tends to be a one-off solution for a specific problem.
That's one end of the programming spectrum. The other end is a full-fledged binary in a compiled language. Harder to create, of course, but for more complex things it's the only way to go. Tools like sed and awk fit somewhere in the middle. Definitely not tools for the novice user, and of course a user shouldn't have to resort to them to do their work, but they're also not solely used in scripts designed for an end user.
I use sed, awk, perl, etc. on a daily basis to do my personal job. I use them when i want to do something more complex than what a GUI would ever let me accomplish.
And because I know the value of these tools to a power user, I make sure that every application I write for other people includes some sort of command line interface, even if nobody but myself will ever use it.
That's exactly his point. The reason the Raspberry Pi can be hooked up to a TV via HDMI is because the HDMI is on a SoC, so no support peripherals are needed.
I would use it for the primary mirror, which tends to fog up when I take it outside without letting it acclimate. Maybe the other mirrors and lenses have the same problem, but it seems to be worse with the primary.
I want a shower door made of this stuff. No more squeegeeing after every shower, no more scrubbing to get the hard water stains off when I forget to squeegee.
My company has some crazy password policies, to the point that remembering all my passwords is quite a challenge. So, I tried the XKCD method, and this is what I found:
1. Typing four words is a lot of typing, but it's amazingly fast due to muscle memory! Just make sure your dictionary has relatively short words in it.
2. Changing passwords often isn't a problem, even when you have multiple accounts to deal with.
3. I think five short words with a smaller dictionary) is better than four words with a larger dictionary.
4. Different systems have different password requirements and capabilities. Some things have workarounds (like adding number or symbol somewhere), but others can't handle long passwords. Until certain software catches up, the XKCD method can't be used everywhere. What a shame.
A quote from the front page of boost.org is relevant here:
We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are included in the C++ Standards Committee's Library Technical Report (TR1) and in the new C++11 Standard. C++11 also includes several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2.
The goal of Boost is to provide libraries that will eventually become standardized. Yes, some changes (slightly different API, removal of features, addition of features, etc) will happen as part of this process, but they are still Boost. The fact that a compiler can (and probably will) write a different implementation of these libraries doesn't change that.
Or were you expecting the standards committee to require people to use the Boost implementation and namespace?
No, the problem is when you write C++ code as though it were Java. Seriously. "Nicely encapsulated objects" is certainly one way to write C++ code (and is the one usually taught by the books), but that isn't by any means the definition of good C++. What you're describing, however, is Java code, where there really isn't any other way to do things.
The C++ philosophy is not OOP. It's not templates. It's not exceptions. Those are simply tools provided in the language, and you can use them how you will. And if you have a 256bit wide SIMD registers, many of those tools are inappropriate. Good C++ code, then, will look completely different.
I think you're misunderstanding the relationship between C and C++. Backwards compatibility has nothing to do with it. On the other hand, most people go the other way and assume that C++ is C with a bunch of features bolted on, but that's not true either.
Nothing about C++ in itself is slow compared to C... it's not like going to Java where you have to consider the effects of garbage collection, running in a VM, etc. However, individual features (exception handling being a good example) have a very specific performance/ease of use trade off that a developer must consider before using this feature.
So, here's how it really works: you write your code in C++. Then you find the bottlenecks. And those you write specific libraries in C++ to optimize. Why still in C++? Because switching to C does absolutely nothing magical to make your code faster. (Now, if we were talking Java and writing a C library, you might have a point, but that's not the case here).
Why kind of bottlenecks are we talking about? Well, what's relevant to this discussion is overhead incurred by using exceptions, or maybe virtual functions and polymorphism is killing your performance. (Algorithmic complexity is not generally fixed by switching languages.) Well, the solution here is to not use those features. That's it. One of the key tenets of C++ is that a feature only introduces overhead if you actually use it! Anybody who says that C++ is slower than C is simply wrong.
Once I fully grokked that one concept, only then did I understand the true nature and power of C++.
One thing that you might not have considered, though, is that some C++ features can actually improve performance over C code. Used correctly, exceptions and templates can be very powerful tools for writing fast code very easily. Used incorrectly, however....
Now, that all said, I still mostly agree with your comments about scripting languages. Get things to run right first, in VBA if need be, and then make the key parts faster. And your last line is very true as well: C++ and C are very different languages in the end. Writing C code in C++ is generally a sign that you're not using the language to its fullest extent.
Oh really? Look at most of TR1 for plenty of examples of Boost libraries that are now part of the C++ standard.
Boost is a proving ground for many concepts that have since been adopted into the language as part of C++11. Some Boost libraries are no longer needed because of native language support rather than a library (BOOST_FOREACH is now a syntax feature, not to mention lambda expressions), and these language features are often clearly designed after the Boost equivalent (as far as I can tell). Others were imported with not much more than a namespace change (shared_ptr, anyone?). Then largest import was probably the threading library, followed by the random number generators and regular expressions.
Slashdot Mirror
Trust me, vendor lock-in is never good for the consumer.
Right now, my phone, my wife's phone, my tablet, my e-reader, and more all have the same (micro-USB) connector. Audio output for all is a 3.5mm jack. Video (for those that have it) is HDMI.
No adapters, no special plugs, no nothing needed.
When I need to charge on the road, and don't have a cable (happened this month), someone always has a micro-USB.
And each device comes from a different manufacturer. Beautiful.
Apple is certainly making things much easier as it refines the design of its products. On the other hand, they also actively trying to prevent people from opening the things up (with specialized screws). It's an interesting dichotomy.
The only reasonable explanation I can think of is that they want to make things easier for themselves (refurbishing and repairing is cheaper), but at the same time they want to reduce competition and discourage the DIY crowd so they have to pay Apple for all fixes.
So, for your car analogy, it's like making everything under the hood easier to work with, but then locking the hood itself.
Well, at least now it's possible to obtain the key (screwdriver) without too much hassle, but the barrier still exists regardless, and it's the attitude that worries me more.
I don't know why people seem to think the iDevice batteries are hard to replace
History. ifixit's instructions for the original iPhone are illustrative: "Getting the iPhone open is a challenging feat, so don't get discouraged. Take a deep breath and make sure you have plenty of time to get the job done." The competition required just sliding a cover and pulling out the battery, which takes five seconds, tops.
But, it's gotten easier. Three or four screws (two on the outside, one or two on the inside) and you're done. Of course, they now use "penalobe" screws, which you usually have to replace because they strip so easily.
The point remains that Apple actively tries to prevent users from replacing the battery. This has nothing to do with making the battery bigger (which, at best, is a pleasant side effect).
Let me add two more: make room for others to merge, and don't force me to move around.
Some drivers think that's it's ok to force their way around as they change lanes, etc. Slowly pushing their way between two cars where no room exists, for example. Tailgating also fits in this category. So does slowing down to piss of the person tailgating you. Instead, let's just be courteous on the road ... is that too much to ask?
Both C and C++ standards allow for other parameters to main():
The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters: /* ... */ } /* ... */ }
int main(void) {
or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) {
or equivalent;10) or in some other implementation-defined manner.
An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: /* ... */ } /* ... */ }
int main() {
and
int main(int argc, char* argv[]) {
In the latter form argc shall be the number of arguments passed to the program from the environment in which the program is run. If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbss) (17.5.2.1.4.2) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "". The value of argc shall be non-negative. The value of argv[argc] shall be 0. [ Note: It is recommended that any further (optional) parameters be added after argv. —end note ]
You're right that there are some minor differences here. The value of argv[argc], for example. Is a C implementation required to support both basic forms? I'm not sure.
In C, however, the parameters to main() can be just about anything the implementation wants. In C++, other parameters are allowed, with the recommendation that additional parameters be placed after argv.
Meaning, the implementation is free to add extra parameters like:
int main(int argc, char *argv[], char *envp[])
or not have a parameter specification like:
int main()
Or just about anything else, in both C and C++. However, a return type of int is required.
GCC is doing the right thing. BTW, if you're in a freestanding environment, -ffreestanding disables the warning about 'void main' (as well as doing a few other important things).
(However, your point about not using a compiler to verify the standard is very much correct, even if we disagree on this particular situation.)
C and C++ (from my reading of the latest standards) are virtually identical: they both require main to return an int in a hosted environment. In a freestanding environment, the startup function can be called by any name and with any return type that the implementation wants.
Thus, for hosted environments, 'void main' is specifically disallowed and GCC is doing the right thing.
Now, let's talk about freestanding environments. To say that void main() is "perfectly valid C" isn't quite right. It's certainly allowed under the C11 and C++11 standards, but by no means is GCC required to support it, as it's an implementation defined feature, and very target-dependent to begin with.
So, what we have is GCC supporting the standard, but whose implementation differs from other compilers. The devs made the choice to not support void main and that's perfectly fine. Nearly everybody who declares main as void are doing so in a hosted environment, and warnings/errors and completely justified.
And the reason for this is, of course, efficiency. Creating space for local variables is as simple as moving a stack pointer. Initializing them to 0 just takes extra time. Uninitialized static variables belong to a special section of the executable (bss in elf format) that quickly and automatically initializes to 0. None of this is specified by the C standard, but the standard was written to accommodate these optimizations.
I believe there's one exception, which is the initialization of pointers declared as static. These are initialized to NULL, not 0. While generally the same, some bizarre architectures have a different bit pattern for NULL. The GP's idea of memset everything to 0 is technically a bad idea for any structure that has a pointer, although it should be fine for most any modern CPU.
It's always an employee's market for the top talent, who are usually in demand regardless of the rest of the job market. The trick is knowing whether or not you're in that special pool. A lot of people think they are ... most are wrong.
No, I'm starting to think that text fields can be a form of CLI, but only when you add keyboard shortcuts into the mix. Keyboard shortcuts muddy the waters enough that I don't think you can consider that interface to be a pure GUI (though I don't think the term CLI quite applies, either).
Let's clean up some of that rust, shall we?
The result of "c++ = c" depends on the type of c and whether the return value of the increment operator returns a value that is assignable from a value of the type of c. However, if c is an int or other primitive type, "c++ = c" gives a syntax error as c++ is not an l-value.
Operator overloading ... wonderful if used right, but you can certainly do weird stuff with it, too.
In the case of "c++ == c" ... I believe the standard specifies this as undefined behavior, since you're incrementing and reading the value of c in the same statement, and I don't believe there's a sequence point to make the statement valid.
Put it this way ... when a C coder writes something in Java, it usually works even if it looks ugly. When a Java coder writes something in C, it's usually leaks memory like a sieve, only works with the specific inputs that they used to test, constantly walks off the ends of arrays, breaks when you cough too loudly, and took forever to write.
Here's why: you can pretty much translate C code into Java without too much hassle, as most of C is a simple subset. A few syntax changes here and there, and you're done. Any language or library features that Java doesn't have can be redone in a different way, which is something most C programmers are comfortable doing.
Translating Java to C is another matter. First you have to think about memory allocation, which is a concept that the original Java didn't have to worry about. But the bigger problem is the relatively thin standard library for C vs Java. You have to hand-code a lot of stuff that Java has by default. Like dynamic lists, for example. What a C coder has to do every day, many Java programmers haven't had to deal with at all. And the end result is ugly, buggy code.
One of the best features about C++ is that you can define your own subset that you'll use. Don't want to use RTTI? Then don't! Worried about exception handling? Then don't use them! This is why C++ can never be slower than C -- in the end, just reduce that subset until you get to C and you're done. Beware, though, some of the features you just left out might actually improve performance over the C equivalent!
However, this subset has to be defined on a project basis, and not left for individual programmers to decide for their own code.
+templates implies +overloading
For example: the STL iterators use the same interface as pointers, which then lets you use templated algorithms that can accept an STL iterator or pointers into an array.
Another example: your templated function needs to call fabs() on some variable of type T. Overloading lets the compiler pick the right one, even if it's a user-defined type.
Overloading doesn't deserve the bad reputation. As long as you use it as a tool for specific reasons, it's wonderful to have. The most commonly-cited problem people have is when people overload operators (although this problem extends to any overloaded function) to do weird and unexpected things. Fortunately, this problem is discussed enough that it's rare to see someone do bad things with overloading.
To exclude, I usually use something like: `find . -name '.svn' -prune -o -name '*.c' -print` (searches for all .c files, ignoring the ones in the .svn directories)
I don't have much experience with Total Commander, so forgive my ignorance here. But from my experience, most GUI tools recognize a need but can only provide a partial solution for very specific cases ("Oh, you want to rename a lot of files? Well, here's a batch rename utility! Oh, you want to append the current time into the file name? Well, here's a variable that will expand to the date! Oh, you want the time to be in WHAT format? A different Timezone? Well, let me provide a special menu for that..."). Anticipating every need and providing a GUI interface for each is impossible.
The beauty of a command line with a modern shell is that it makes very odd, one-off situations possible. I have yet to see a GUI utility that can do that without providing a textual interface.
To use a computer is to program it. This applies grandmothers just as much as it applies to software engineers.
I'd better explain myself, though.
If you think about it, clicking around a GUI is really just giving instructions to the computer on what you want it to do. For example, let's say someone opens a file in Word ... load this file, change this text (by typing something in and clicking where it should be inserted), save the file. Most applications are little more than command interpreters. They just happen to abstract the command sequence out to something very high level like mouse clicks, and leave out more powerful features (like looping). You even get one variable to play with: the clipboard. Sometimes more complex things can be built-in (search/replace), but each of these tends to be a one-off solution for a specific problem.
That's one end of the programming spectrum. The other end is a full-fledged binary in a compiled language. Harder to create, of course, but for more complex things it's the only way to go. Tools like sed and awk fit somewhere in the middle. Definitely not tools for the novice user, and of course a user shouldn't have to resort to them to do their work, but they're also not solely used in scripts designed for an end user.
I use sed, awk, perl, etc. on a daily basis to do my personal job. I use them when i want to do something more complex than what a GUI would ever let me accomplish.
And because I know the value of these tools to a power user, I make sure that every application I write for other people includes some sort of command line interface, even if nobody but myself will ever use it.
That's exactly his point. The reason the Raspberry Pi can be hooked up to a TV via HDMI is because the HDMI is on a SoC, so no support peripherals are needed.
Wait ... I thought Microsoft was suing B&N over the Nook Color.
Now, I realize that we're not talking about the Nook Color in this deal specifically, but this deal smells funny to me anyway.
I would use it for the primary mirror, which tends to fog up when I take it outside without letting it acclimate. Maybe the other mirrors and lenses have the same problem, but it seems to be worse with the primary.
I want a shower door made of this stuff. No more squeegeeing after every shower, no more scrubbing to get the hard water stains off when I forget to squeegee.
My company has some crazy password policies, to the point that remembering all my passwords is quite a challenge. So, I tried the XKCD method, and this is what I found:
1. Typing four words is a lot of typing, but it's amazingly fast due to muscle memory! Just make sure your dictionary has relatively short words in it.
2. Changing passwords often isn't a problem, even when you have multiple accounts to deal with.
3. I think five short words with a smaller dictionary) is better than four words with a larger dictionary.
4. Different systems have different password requirements and capabilities. Some things have workarounds (like adding number or symbol somewhere), but others can't handle long passwords. Until certain software catches up, the XKCD method can't be used everywhere. What a shame.
A quote from the front page of boost.org is relevant here:
We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are included in the C++ Standards Committee's Library Technical Report (TR1) and in the new C++11 Standard. C++11 also includes several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2.
The goal of Boost is to provide libraries that will eventually become standardized. Yes, some changes (slightly different API, removal of features, addition of features, etc) will happen as part of this process, but they are still Boost. The fact that a compiler can (and probably will) write a different implementation of these libraries doesn't change that.
Or were you expecting the standards committee to require people to use the Boost implementation and namespace?
No, the problem is when you write C++ code as though it were Java. Seriously. "Nicely encapsulated objects" is certainly one way to write C++ code (and is the one usually taught by the books), but that isn't by any means the definition of good C++. What you're describing, however, is Java code, where there really isn't any other way to do things.
The C++ philosophy is not OOP. It's not templates. It's not exceptions. Those are simply tools provided in the language, and you can use them how you will. And if you have a 256bit wide SIMD registers, many of those tools are inappropriate. Good C++ code, then, will look completely different.
I think you're misunderstanding the relationship between C and C++. Backwards compatibility has nothing to do with it. On the other hand, most people go the other way and assume that C++ is C with a bunch of features bolted on, but that's not true either.
Nothing about C++ in itself is slow compared to C ... it's not like going to Java where you have to consider the effects of garbage collection, running in a VM, etc. However, individual features (exception handling being a good example) have a very specific performance/ease of use trade off that a developer must consider before using this feature.
So, here's how it really works: you write your code in C++. Then you find the bottlenecks. And those you write specific libraries in C++ to optimize. Why still in C++? Because switching to C does absolutely nothing magical to make your code faster. (Now, if we were talking Java and writing a C library, you might have a point, but that's not the case here).
Why kind of bottlenecks are we talking about? Well, what's relevant to this discussion is overhead incurred by using exceptions, or maybe virtual functions and polymorphism is killing your performance. (Algorithmic complexity is not generally fixed by switching languages.) Well, the solution here is to not use those features. That's it. One of the key tenets of C++ is that a feature only introduces overhead if you actually use it! Anybody who says that C++ is slower than C is simply wrong.
Once I fully grokked that one concept, only then did I understand the true nature and power of C++.
One thing that you might not have considered, though, is that some C++ features can actually improve performance over C code. Used correctly, exceptions and templates can be very powerful tools for writing fast code very easily. Used incorrectly, however ....
Now, that all said, I still mostly agree with your comments about scripting languages. Get things to run right first, in VBA if need be, and then make the key parts faster. And your last line is very true as well: C++ and C are very different languages in the end. Writing C code in C++ is generally a sign that you're not using the language to its fullest extent.
Oh really? Look at most of TR1 for plenty of examples of Boost libraries that are now part of the C++ standard.
Boost is a proving ground for many concepts that have since been adopted into the language as part of C++11. Some Boost libraries are no longer needed because of native language support rather than a library (BOOST_FOREACH is now a syntax feature, not to mention lambda expressions), and these language features are often clearly designed after the Boost equivalent (as far as I can tell). Others were imported with not much more than a namespace change (shared_ptr, anyone?). Then largest import was probably the threading library, followed by the random number generators and regular expressions.
Stack Overflow has a great list to get you started.
The amount of Boost in C++11 is quite amazing.
It gets even more obvious if you use Plank units, where c = 1. Then, this equation becomes just E = m.
If the term "equivalence" bothers you, just think of it as a unit conversion.