You might be inlining the sort code but that's only if you are sorting classes.
Huh? First, the most speed doesn't come from inlining the sort code, but from inlining the (usually quite trivial) comparison code into the sort routine. And since when is usage of std::sort (or any optimization of it) restricted to classes?
std::vector<int> v; // fill v std::sort(a.begin(), a.end(), std::greater<int>);// sort to reverse order
is most likely faster than the corresponding qsort call (which needs a callback transferred via function pointer which is called for every single comparison).
Code written in C++ following the general conventions of C++ tends to be slower.
Following the general conventions of C++? Apart from some very general conventions which mostly are more or less speed-neutral (like "define your variables at the point of initialization", or the famous RAII pattern), or are even explicitly about better speed (like "pass complex objects by const reference rather than by value"), there are completely different conventions for different coding styles, e.g. the conventions for OOP with C++ are quite different from the conventions for GP with C++ (and sometimes even contradictory, after all, OOP is about tying behavious to objects, while GP is about maximal independence of algorithms from the objects they work on, correspondingly OOP strongly prefers virtual member functions, and GP strongly prefers free functions, and virtual isn't used at all here).
Note that properly written C code has abstraction layers as well, and therefore also suffers from some abstraction penalty.
That's complete nonsense. There's a C subset in C++ which should perform just as well as when compiled in C. Also, while there are features in C++ which have hidden cost, you'd not use them unless you need the functionality, and in that case you'd have to do something similar in C (therefore also having ther same cost, it's just that this cost is reflected by more programming work). For example, a non-virtual member function call in C++ should be the same speed as a normal function call in both C and C++. A virtual member function call is more expensive, but so would be emulating it in C.
And I'd guess calling std::sort is usually faster than using qsort in C, because due to it being a template, it can inline the actual comparison code. It's more powerful as well because it can also sort complicated objects which cannot be simply memcpyed for movement.
Yes, it's easier for an incompetent programmer to write inefficient C++ than it is to write inefficient C. But that doesn't mean that C++ itself is slower.
The existence of child pornography is a good sign, because it shows that there are still enough children so that child pornographers can find some to abuse!:-)
Of course you can use your text editor to do great images. Just type it in postscript. Ok, to actually see the images you'll need either a postscript viewer or a really great imagination (but then, to type postscript images directly in the editor, you probably need the latter anyway:-)).
You cannot use entanglement to do FTL communication because there's no way you can control the outcome of the measurement.
If Alice and Bob share an entangled pair, and both do a measurement, they both get a completely random result. It's just that both get the same result. But there's no way for Alice to influence the result which Bob gets. Think of it as a one-time pad which materializes only on observation.
Now, with quantum teleportation, Alice doesn't just measure her pair particle, but a combination of a pair particle and the particle the (possibly unknown) state of which she wants to transfer to bob. That measurement gives an (unpredictable) result, which describes, which transformation Bob has to do on his particle to get the state. However, Bob cannot know which transformation he has to do before he gets the measured (classical) information from Alice. Therefore Alice still cannot send FTL messages, unless she already knows another way to send classical information with FTL speed.
Or to say it another way: Even if the message appears to be transmitted with FTL, at the same time it gets perfectly encrypted, and Bob will not be able to read it until he gets the key from Alice. And that will have to happen another way, since otherwise it would get encrypted as well. But even this is not really accurate, because until Bob gets the message from Alice, he even cannot determine if Alice has sent anything, because any measurement he might do will get random results. Therefore FTL communication is not possible this way.
Will there be a Linux port for the quantum computer?:-) However I imagine debugging on a quantum computer will be no fun: After all, quantum programs will behave different when you look at them with a debugger!
Sorry to disappoint you, but as long as you want to be able to reliably retrieve the information previously stored, a 256 qubit disk will be able to store exactly 256 classical bits, and no single bit more. It could store something which classical disks cannot, which is quantum states. Which would make a quantum hard disk quite interesting, but not for storing more classical information, but for storing quantum information which you simply couldn't store on a classical disk at all.
Sorry, but the link you gave doesn't hint anything bout that FTL communication should be possible. And I can assure you the Many Worlds Interpretation (MWI) by itself doesn't allow you to do FTL. Indeed, one of the strengthes of the MWI is that it can explain entanglement and quantum teleportation completely without FTL effects.
Given that TFA makes exactly the same statement, it's not really the poster who's misunderstanding you're seeing. I guess what they managed is to do a measurement which behaves like an ideal quantum measurement: After you measured the system to be in state x, it really is in state x (unlike e.g. a typical photon measurement where after measuring the state of the photon, it isn't actually in any state because it doesn't exist any more). Which means that if the system is already in an eigenstate of the measurement, it isn't changed by the measurement. Which is as close to non-disturbance as you can get in quantum mechanics.
The problem of course is that the editor can only indent based on syntax, which will be fine in most cases, but not in all of them. For example, my "n plus 1/2" loops generally look like this (underscores used for spaces, to prevent slashdot from eating them:
while (true) { __code(); if (condition) break; __morecode(); }
Note that the if line is not indented because it logically belongs to the loop structure. I doubt that an on-the-fly auto-indenting editor would let me do that. Of course an auto-indenting editor feature which just changes the text and allows me to manually change it afterwards is a different point (and I indeed do use the xemacs auto-indentation). And another problem, of course, is that the editor is by far not the only tool you use to look at source code. And I'd bet that even the editor would usually be confused by prefixed source code (e.g. diff output).
The idea of using tabs only for block-indentation solves the relative alignment problem, but doesn't solve any of the other problems. It doesn't solve the problem that there isn't a global setting of the tab stop, but only settings local to the respective tools. It doesn't solve the problem that not every file is a program, and setting tab stops to anything but the default of 8 might break viewing non-program material. And it certainly doesn't solve the problem that a tab, by design, is not equivalent to a fixed series of spaces (or to a fixed amount of horizontal space), leading to problems with prefixing.
Another problem is that it doesn't fit well with additional indentation/prefixing from outside tools (e.g. diff, or quoting in emails/usenet). After all, a tab is not equivalent to n spaces, but it's equivalent to as many spaces as needed to get to the next tab stop. For example, take a simple tool which adds line numbers. And, say, the original code looks like
void foo() {
bar(); }
Then if you have used spaces, the tool will give you:
1: void foo() 2: { 3: bar(); 4: }
However if you used tab indentation with a 4-space tab size, it will instead look like:
1: void foo() 2: { 3: bar(); 4: }
That's because the program now begins at column 3, but the first tab stop is still at column 4, which is just one space away. Now I think you'll agree that this result is, well, not really optimal.
And of course if the number of errors with 8 space indentation convinces me of anything, then it's that 8 space indentation is just too much. But that's probably because I'm convinced of that anyway:-) Note that for 2 space indentation, the probability of doing 1 of 3 spaces on accident without recognicing it is quite low, because the relative difference is large (half an indentation level).
Well, if you use proportional font, I understand that you don't spot two-space indentation. Proportional font spaces are usually much smaller than fixed font spaces. However, I very much depend on the ability of lining up certain things to each other (esp. function arguments), therefore proportional fonts will not work too well for me.
The auto-indenting editor would not be sufficient, because there's still the problem of saving changed code. Unless of course you say the code may well be saved in any form as long as it looks nice on the editor. But then, the editor is hardly the only program you use with the code, there's also e.g. things like less, version control (esp. in diffs changes in whitespace can cause lots of visual clutter), and finally if your compiler gives error messages with column information, you pretty much want the columns in your editor to match the columns reported by the compiler (BTW another place where tabs can hurt).
Auto-converting spaces into tabs on saving will also kill alignments if you view with another tab size than what you saved with. After all, the editor cannot distinguish spaces used for indenting from spaces used for alignment.
Don't worry, you'll not live forever. 6 times 120 years are just 720 years. Less, because you already lived some of your years. And of course, this will not protect you from illness. Probably you'll die long before your natural end anyway. Remember, the longer you live, the more likely you get a lethal illness.
And how is it different to just taking a walk through the city? Of course, there are places in the city which are safe because there's police, but in many large cities there are also places which you should better avoid, and if you don't know it, there may be no sign that you are leaving the safe district. Usenet isn't much different, there are also well-policed regions (moderated newsgroups), regions where the neighbourhood manages to keep most bad people out (good unmoderated newsgroups with active regulars), and regions which you better avoid (unmoderated newsgroups where the majority of postings are spam, trolls etc.).
I never have problems to immediatly spot two-space indentation. But maybe it depends also on other parts of the coding standards. For example, I usually put the opening brace on a line of it's own (the only exception is if the closing brace is in the same line, which can be useful for empty and one-statement functions), which causes indented blocks to be separated from unindented by an almost-empty line.
Larger spacing makes the effective line length shorter (I keep my lines below 80 characters, so it will not wrap in non-resized editor and terminal windows), which leads to more many-line statements (if you use descriptive variable names, even relatively simple expressions can get quite long), which I again consider less readable.
Hard tabs can make it problematic to align certain parts of a statement relative to each other (e.g. aligning arguments to functions so that they line up nicely). Also, changing the tab width from the default of 8 might break non-program texts like tables of data, while 8 space indentation is IMHO clearly too much. And with non-standard tabs, you'll have to remember to set the tab width everywhere (on the editor, when using less on the command line, on printing,...)
If the relevant systems had a simple and consistent way of setting file-type specific tab spacing globally for each user, then using tabs might be practicable. With the existing systems, it IMHO isn't.
Slashdot Mirror
No, by that time, everyone expected Longhorn.
Huh?
First, the most speed doesn't come from inlining the sort code, but from inlining the (usually quite trivial) comparison code into the sort routine. And since when is usage of std::sort (or any optimization of it) restricted to classes?is most likely faster than the corresponding qsort call (which needs a callback transferred via function pointer which is called for every single comparison).
Following the general conventions of C++? Apart from some very general conventions which mostly are more or less speed-neutral (like "define your variables at the point of initialization", or the famous RAII pattern), or are even explicitly about better speed (like "pass complex objects by const reference rather than by value"), there are completely different conventions for different coding styles, e.g. the conventions for OOP with C++ are quite different from the conventions for GP with C++ (and sometimes even contradictory, after all, OOP is about tying behavious to objects, while GP is about maximal independence of algorithms from the objects they work on, correspondingly OOP strongly prefers virtual member functions, and GP strongly prefers free functions, and virtual isn't used at all here).
Note that properly written C code has abstraction layers as well, and therefore also suffers from some abstraction penalty.
That's complete nonsense. There's a C subset in C++ which should perform just as well as when compiled in C. Also, while there are features in C++ which have hidden cost, you'd not use them unless you need the functionality, and in that case you'd have to do something similar in C (therefore also having ther same cost, it's just that this cost is reflected by more programming work). For example, a non-virtual member function call in C++ should be the same speed as a normal function call in both C and C++. A virtual member function call is more expensive, but so would be emulating it in C.
And I'd guess calling std::sort is usually faster than using qsort in C, because due to it being a template, it can inline the actual comparison code. It's more powerful as well because it can also sort complicated objects which cannot be simply memcpyed for movement.
Yes, it's easier for an incompetent programmer to write inefficient C++ than it is to write inefficient C. But that doesn't mean that C++ itself is slower.
No, but it compiles Linux.
It only shows you have sex. It doesn't show you make babies.
The existence of child pornography is a good sign, because it shows that there are still enough children so that child pornographers can find some to abuse! :-)
Of course you can use your text editor to do great images. Just type it in postscript. :-)).
Ok, to actually see the images you'll need either a postscript viewer or a really great imagination (but then, to type postscript images directly in the editor, you probably need the latter anyway
You cannot use entanglement to do FTL communication because there's no way you can control the outcome of the measurement.
If Alice and Bob share an entangled pair, and both do a measurement, they both get a completely random result. It's just that both get the same result. But there's no way for Alice to influence the result which Bob gets. Think of it as a one-time pad which materializes only on observation.
Now, with quantum teleportation, Alice doesn't just measure her pair particle, but a combination of a pair particle and the particle the (possibly unknown) state of which she wants to transfer to bob. That measurement gives an (unpredictable) result, which describes, which transformation Bob has to do on his particle to get the state. However, Bob cannot know which transformation he has to do before he gets the measured (classical) information from Alice. Therefore Alice still cannot send FTL messages, unless she already knows another way to send classical information with FTL speed.
Or to say it another way: Even if the message appears to be transmitted with FTL, at the same time it gets perfectly encrypted, and Bob will not be able to read it until he gets the key from Alice. And that will have to happen another way, since otherwise it would get encrypted as well. But even this is not really accurate, because until Bob gets the message from Alice, he even cannot determine if Alice has sent anything, because any measurement he might do will get random results. Therefore FTL communication is not possible this way.
Well, it depends on how he was reading it. If he was reading a complementary observable, the original information got completely destroyed.
Will there be a Linux port for the quantum computer? :-)
However I imagine debugging on a quantum computer will be no fun: After all, quantum programs will behave different when you look at them with a debugger!
Sorry to disappoint you, but as long as you want to be able to reliably retrieve the information previously stored, a 256 qubit disk will be able to store exactly 256 classical bits, and no single bit more.
It could store something which classical disks cannot, which is quantum states. Which would make a quantum hard disk quite interesting, but not for storing more classical information, but for storing quantum information which you simply couldn't store on a classical disk at all.
Sorry, but the link you gave doesn't hint anything bout that FTL communication should be possible. And I can assure you the Many Worlds Interpretation (MWI) by itself doesn't allow you to do FTL. Indeed, one of the strengthes of the MWI is that it can explain entanglement and quantum teleportation completely without FTL effects.
Given that TFA makes exactly the same statement, it's not really the poster who's misunderstanding you're seeing.
I guess what they managed is to do a measurement which behaves like an ideal quantum measurement: After you measured the system to be in state x, it really is in state x (unlike e.g. a typical photon measurement where after measuring the state of the photon, it isn't actually in any state because it doesn't exist any more).
Which means that if the system is already in an eigenstate of the measurement, it isn't changed by the measurement. Which is as close to non-disturbance as you can get in quantum mechanics.
There is in general no reason to use C strings at all in C++, except where legacy interfaces demand them. Use std::string instead.
I at least managed to do a DoS attack on my computer using nothing but the power cord. The trick is to pull it.
Do you want it implanted at your forehead or at your right hand?
The idea of using tabs only for block-indentation solves the relative alignment problem, but doesn't solve any of the other problems. It doesn't solve the problem that there isn't a global setting of the tab stop, but only settings local to the respective tools. It doesn't solve the problem that not every file is a program, and setting tab stops to anything but the default of 8 might break viewing non-program material. And it certainly doesn't solve the problem that a tab, by design, is not equivalent to a fixed series of spaces (or to a fixed amount of horizontal space), leading to problems with prefixing.
Ok, here's my example again, this time with underscores instead of spaces:
Original code:Code with line numbers, assuming space indentationCode with line numbers, assuming tab indentation (tab spacing of 4):
For example, take a simple tool which adds line numbers. And, say, the original code looks likeThen if you have used spaces, the tool will give you:However if you used tab indentation with a 4-space tab size, it will instead look like:That's because the program now begins at column 3, but the first tab stop is still at column 4, which is just one space away. Now I think you'll agree that this result is, well, not really optimal.
And of course if the number of errors with 8 space indentation convinces me of anything, then it's that 8 space indentation is just too much. But that's probably because I'm convinced of that anyway
Well, if you use proportional font, I understand that you don't spot two-space indentation. Proportional font spaces are usually much smaller than fixed font spaces. However, I very much depend on the ability of lining up certain things to each other (esp. function arguments), therefore proportional fonts will not work too well for me.
The auto-indenting editor would not be sufficient, because there's still the problem of saving changed code. Unless of course you say the code may well be saved in any form as long as it looks nice on the editor. But then, the editor is hardly the only program you use with the code, there's also e.g. things like less, version control (esp. in diffs changes in whitespace can cause lots of visual clutter), and finally if your compiler gives error messages with column information, you pretty much want the columns in your editor to match the columns reported by the compiler (BTW another place where tabs can hurt).
Auto-converting spaces into tabs on saving will also kill alignments if you view with another tab size than what you saved with. After all, the editor cannot distinguish spaces used for indenting from spaces used for alignment.
Don't worry, you'll not live forever. 6 times 120 years are just 720 years. Less, because you already lived some of your years.
And of course, this will not protect you from illness. Probably you'll die long before your natural end anyway. Remember, the longer you live, the more likely you get a lethal illness.
Just don't carry alt.binaries.* and some other specific hierarchies and you're done.
For example news.individual.net does this.
And how is it different to just taking a walk through the city?
Of course, there are places in the city which are safe because there's police, but in many large cities there are also places which you should better avoid, and if you don't know it, there may be no sign that you are leaving the safe district. Usenet isn't much different, there are also well-policed regions (moderated newsgroups), regions where the neighbourhood manages to keep most bad people out (good unmoderated newsgroups with active regulars), and regions which you better avoid (unmoderated newsgroups where the majority of postings are spam, trolls etc.).
I never have problems to immediatly spot two-space indentation. But maybe it depends also on other parts of the coding standards. For example, I usually put the opening brace on a line of it's own (the only exception is if the closing brace is in the same line, which can be useful for empty and one-statement functions), which causes indented blocks to be separated from unindented by an almost-empty line.
...)
Larger spacing makes the effective line length shorter (I keep my lines below 80 characters, so it will not wrap in non-resized editor and terminal windows), which leads to more many-line statements (if you use descriptive variable names, even relatively simple expressions can get quite long), which I again consider less readable.
Hard tabs can make it problematic to align certain parts of a statement relative to each other (e.g. aligning arguments to functions so that they line up nicely). Also, changing the tab width from the default of 8 might break non-program texts like tables of data, while 8 space indentation is IMHO clearly too much. And with non-standard tabs, you'll have to remember to set the tab width everywhere (on the editor, when using less on the command line, on printing,
If the relevant systems had a simple and consistent way of setting file-type specific tab spacing globally for each user, then using tabs might be practicable. With the existing systems, it IMHO isn't.
Well, I'm sure there are a lot of places where birthday suit isn't accepted at work. Therefore you are limiting your choices quite a bit.