It's "man-in-the-middle" because it requires a javascript injection. That might be possible through vulnerabilities in particular websites (eg embedded ads with javascript, or a crafted link, etc). It could also be injected by an ISP.
I can't believe that a site like Tom's Hardware is scared of a little criticism. And it seems obvious that you would do the benchmark on the current Ubuntu release, if only because of its relative popularity.
Any of these systems can be tweaked, not just Linux; if that was an argument, then no-one would ever benchmark anything.
Some years back I heard Microsoft representatives at a firmware conference describe WinCE as a real-time operating system. They seemed to think that real-time meant fast scheduling and interrupt response times. It is a common misunderstanding (real-time actually means consistent completion times for task activities), and now makes me wary about any products (particularly Microsoft ones) that claim to be "real-time". Other presenters at the conference (Green Hills, QNX, etc) were far more knowledgable.
Yes, there are real-time solutions for Windows, but there is more to a real-time operating system than just a few scheduling mods; for example, the interaction between drivers and the operating system also plays a significant part. That is why Windows (or Linux) would not normally be the first choice for a genuine real-time system.
Microsoft may well disagree, but I would suggest that Microsoft marketing claims should be taken with a grain of salt.
Because the language models are the same in both directions, the two translation processes actually have a reasonable chance of getting back to the original. It is quite possible for a serious translation error to get reversed in the back-translation; the two-way translation processes can be deceptively good.
There are plenty of wikipedia pages in other languages to test it out on. Translations between closely related and well studied languages such as German and English are usable. Other combinations are, well, better than nothing...
The Google translation is impressive, but we are reaching diminishing returns on these database methods; they enabled a big jump in machine translation abilities, but the real work of understanding texts is still many many years away. The primary requirement for good translation is artificial intelligence, and that goal is far enough away that it is foolish to make predictions.
Why do you think the auto keyword was chosen? Are you suggesting it would break compatibility less by adding adding a new keyword, or that one of the other keywords would have been a better choice?
And since when does deprecation break existing code? Deprecation is just an advance warning that the feature will be removed some time in the future.
It is not clear if you are arguing for more radical change, or less.
Sounds more like an opinion than having reasoned it out. Whether or not to have a garbage collector is not an oversight, but a deliberate decision in most languages for decades now. There are good reasons for not including one (such as unpredictability of memory usage and cpu time at run-time, difficulties of determining what is a pointer and what isn't, etc), and good reasons for including one (to remove a potential source of errors, to reclaim memory more efficiently than the application program might do so, and so on). On balance, the decision to not include a garbage collector in C++ is appropriate for this language, but isn't for others.
why the hell does operator new() return a "dumb pointer"
Because why have the overhead of a smart pointer if it is not always required? Smart pointers are quite useful, but that doesn't mean everyone should be forced to use them in every situation. This is a language that is sometimes used in bare metal contexts.
why is argv an array of char arrays rather than a std::vector
For the obvious reason that changing things like this would break existing compatibility with legacy C code. Clearly a language designed from scratch would not do this, but you are talking about a single declaration (of main) out of many thousands of lines in a typically application.
Why does "std::string fullpath = path + "/" + filename " work for std::string path and char* filename, but fails for char* path and std::string filename?
Because there never was any functionality to concatenate two char pointers. The prime reason that STL strings allow concatenation with a char pointer string is to support string literals; so if you are going to find fault, it is that there is no easy way to define std::string literals apart from initializing with a char * literal.
Why, in short, is your language such a Goddamn mess?
Because sometimes pragmatic considerations beat idealism.
Ok, first, what? I thought standard library string implementations were supposed to be efficient, and include some sort of copy-on-write semantics, which would (I would hope) make the above a shuffle-pointer-around instruction instead of a copy-data-around instruction.
The string implementation is just an example. The current problem is that it is difficult to implement move semantics without having a special case for every class. The introduction of rvalue references enables a class to implement both copy and move semantics in a way that lets other classes transparently move the objects around. The move semantics are that the content is copied but the original need not be preserved (since often the original is a temporary). It enables other code (template libraries for containers and algorithms as an example) to be significantly more efficient.
Ok, cool... But where is this used in the "moveswapstr" example? Does this make the "naiveswap" example automagically faster? Or is there some other syntax? It doesn't really say:
Unfortunately parts of the article appear to have been completely munged. It looks like some of the angle brackets didn't get turned into entities, and the html parsing has just swallowed up chunks. So I can understand your confusion.
...right... Still, unless I actually know what this means, it's useless.
It means that STL functionality can be made as fast as possible, since the copying of temporaries was one of the few potential places for improvement. This doesn't make require large changes when you are using the STL from the outside, apart from defining move semantics for your item classes if you wish to take advantage of these improvements.
...what? Am I missing something, because this doesn't seem to be about type inference at all. Did we switch to another topic without me noticing? Nope, it continues:
The second part of the type inference section is not about using auto, but about declaring a type from an expression (rather than just defining it from another type). This is can be useful in a statically typed language, especially in templates where it might be difficult to indirectly access types.
If I'm alarmed, it's because C++ was already bloated from the first attempt at this -- backporting objects and exceptions to C.
If by bloated you mean a rich feature set that takes time to learn, then yes. If by bloated you mean a syntax that is sometimes convoluted because of the need for backward compatibility, then yes. But I'm not sure if this is what you mean. The design of C++ was deliberately done to maintain the performance and efficiency of C. Adding objects has no effect on that (apart from a single pointer indirection in some circumstances, and an additional pointer where a hierarchy has virtual methods). Exceptions are of zero impact if you choose not to use them, and even if you do, are inefficient only when thrown. C++ does not force you to use all of the different constructs; there are many cases where it is quite sensible to use a subset (such as in embedded programming).
as these are mostly taking the good ideas from other languages and backporting them to C++
I think you'll find that all languages borrow ideas for each other, and C++ is no exception. But a lot of these ideas have been on the table for many years now, it isn't like they are that new in the C++ world. It is just that C++ is an important language, and no-one wants to break it, or introduce poorly thought out features that we will be stuck with. C++ doesn't have the luxury of redefining the language completely, it is both a strength and a weakness.
Having looked into the info tech post-grad courses at both RMIT and CSU, I noticed that while connectivity might not have been an issue, the RMIT course was heavily Windows oriented (ie, in order to complete the coursework, a student had to make extensive use of particular Windows only applications). On the other hand, at CSU (which is more geared towards distance education), using Linux has been much easier; there is an emphasis on using online applications (such as shared documents, wikis, etc) that are platform agnostic, and the only issue has been dealing with messy DRM on some materials from the library (which is not something I imagine that the university can do much about).
Consciousness seems to play a role in this, as it seems our measurement of either the momentum or the position of an electron seems to fundamentally change its properties.
Saying that the measurement 'changes' the properties is an interpretation. There is an interesting correlation between the measurement and the change in properties; using terms implying causation is starting to move into the area of interpretation. These different interpretations are philosophically interesting, but it is hard to come up with ways to distinguish them experimentally.
For example, in a many-worlds interpretation, the different particle states 'cause' the multiplicity of conscious states. Or there is even the time-symmetric interpretation, where there is 'retro-causality' as well as 'causality'.
While the ARM is perhaps harder to write assembler for, it has a beautifully orthogonal instruction set, great for a compiler (and lets face it, if you are writing more than 10% of your code in assembler, you must have some horribly stringent requirements).
Having said that, the AVR is one of the nicer 8 bit instruction sets, and not a bad introduction to assembler. Since the AVR chips don't have some of the memory and I/O complexity of the more powerful microcontrollers, they are great for light projects. But once you have any amount of calculations, there just isn't the processing power. It isn't an apples vs apples comparison, these architectures are in different classes.
You might be thinking of uv erasable eproms, which could only handle a few thousand cycles. But that would have been about the time "The Godfather" was showing in the cinemas.
I think we are in agreement, though you perhaps described it better. Keeping details of the system secret involves an 'obscurity' that is difficult to measure; exactly how hard is it to guess the architecture or algorithms? It is poor security because it is ill-defined.
On the other hand, the GP was pointing out that a credential is a form of data 'obscurity'. But while that is true in some literal sense, it isn't the generally accepted meaning of the term 'security through obscurity'.
An interesting discussion example would be the idea of putting ssh onto a non-standard port. Although this relies on a 'random' piece of data (which port), it still tends to be thought of as security through obscurity.
While you have a point that many security methods such as passwords rely on 'obscurity', one can still make a distinction between methods which rely on poorly measured (and typically low) entropy and methods which rely on well defined entropy. Usually when people talk about the dangers of security through obscurity, they are talking of the former; the use of methods such as pass-phrases have well defined entropy, and the degree of difficulty ('obscurity') is controlled. Of course, pass-phrases are not a magic bullet if there are other ways to discover them (such as when they are sent plaintext over the network).
Slashdot Mirror
apart from decent working memory for each node, low inter-node latencies, and a filesystem
The earth isn't THAT big. The curvature over 732km is a good deal larger than 18m (ie, more like 20 times larger).
that could be one very expensive tunnel you are proposing there...
It's "man-in-the-middle" because it requires a javascript injection. That might be possible through vulnerabilities in particular websites (eg embedded ads with javascript, or a crafted link, etc). It could also be injected by an ISP.
a less likely null hypothesis
In 50 years, every language and instruction set used today could well be a long-forgotten joke.
hey man, are you dissin' COBOL?
I can't believe that a site like Tom's Hardware is scared of a little criticism. And it seems obvious that you would do the benchmark on the current Ubuntu release, if only because of its relative popularity.
Any of these systems can be tweaked, not just Linux; if that was an argument, then no-one would ever benchmark anything.
I'll take that as a compliment :-)
Greenpeace revenue:
0.4 billion
ExxonMobil revenue:
383 billion
I think you missed AC's British humour:
http://en.wikipedia.org/wiki/Geiger-Marsden_experiment
Some years back I heard Microsoft representatives at a firmware conference describe WinCE as a real-time operating system. They seemed to think that real-time meant fast scheduling and interrupt response times. It is a common misunderstanding (real-time actually means consistent completion times for task activities), and now makes me wary about any products (particularly Microsoft ones) that claim to be "real-time". Other presenters at the conference (Green Hills, QNX, etc) were far more knowledgable.
Yes, there are real-time solutions for Windows, but there is more to a real-time operating system than just a few scheduling mods; for example, the interaction between drivers and the operating system also plays a significant part. That is why Windows (or Linux) would not normally be the first choice for a genuine real-time system.
Microsoft may well disagree, but I would suggest that Microsoft marketing claims should be taken with a grain of salt.
and is commonly known in the industry as a pseudolite...
Because the language models are the same in both directions, the two translation processes actually have a reasonable chance of getting back to the original. It is quite possible for a serious translation error to get reversed in the back-translation; the two-way translation processes can be deceptively good.
There are plenty of wikipedia pages in other languages to test it out on. Translations between closely related and well studied languages such as German and English are usable. Other combinations are, well, better than nothing...
The Google translation is impressive, but we are reaching diminishing returns on these database methods; they enabled a big jump in machine translation abilities, but the real work of understanding texts is still many many years away. The primary requirement for good translation is artificial intelligence, and that goal is far enough away that it is foolish to make predictions.
Why do you think the auto keyword was chosen? Are you suggesting it would break compatibility less by adding adding a new keyword, or that one of the other keywords would have been a better choice?
And since when does deprecation break existing code? Deprecation is just an advance warning that the feature will be removed some time in the future.
It is not clear if you are arguing for more radical change, or less.
to make up for a deficiency in the language
Sounds more like an opinion than having reasoned it out. Whether or not to have a garbage collector is not an oversight, but a deliberate decision in most languages for decades now. There are good reasons for not including one (such as unpredictability of memory usage and cpu time at run-time, difficulties of determining what is a pointer and what isn't, etc), and good reasons for including one (to remove a potential source of errors, to reclaim memory more efficiently than the application program might do so, and so on). On balance, the decision to not include a garbage collector in C++ is appropriate for this language, but isn't for others.
why the hell does operator new() return a "dumb pointer"
Because why have the overhead of a smart pointer if it is not always required? Smart pointers are quite useful, but that doesn't mean everyone should be forced to use them in every situation. This is a language that is sometimes used in bare metal contexts.
why is argv an array of char arrays rather than a std::vector
For the obvious reason that changing things like this would break existing compatibility with legacy C code. Clearly a language designed from scratch would not do this, but you are talking about a single declaration (of main) out of many thousands of lines in a typically application.
Why does "std::string fullpath = path + "/" + filename " work for std::string path and char* filename, but fails for char* path and std::string filename?
Because there never was any functionality to concatenate two char pointers. The prime reason that STL strings allow concatenation with a char pointer string is to support string literals; so if you are going to find fault, it is that there is no easy way to define std::string literals apart from initializing with a char * literal.
Why, in short, is your language such a Goddamn mess?
Because sometimes pragmatic considerations beat idealism.
Ok, first, what? I thought standard library string implementations were supposed to be efficient, and include some sort of copy-on-write semantics, which would (I would hope) make the above a shuffle-pointer-around instruction instead of a copy-data-around instruction.
The string implementation is just an example. The current problem is that it is difficult to implement move semantics without having a special case for every class. The introduction of rvalue references enables a class to implement both copy and move semantics in a way that lets other classes transparently move the objects around. The move semantics are that the content is copied but the original need not be preserved (since often the original is a temporary). It enables other code (template libraries for containers and algorithms as an example) to be significantly more efficient.
Ok, cool... But where is this used in the "moveswapstr" example? Does this make the "naiveswap" example automagically faster? Or is there some other syntax? It doesn't really say:
Unfortunately parts of the article appear to have been completely munged. It looks like some of the angle brackets didn't get turned into entities, and the html parsing has just swallowed up chunks. So I can understand your confusion.
...right... Still, unless I actually know what this means, it's useless.
It means that STL functionality can be made as fast as possible, since the copying of temporaries was one of the few potential places for improvement. This doesn't make require large changes when you are using the STL from the outside, apart from defining move semantics for your item classes if you wish to take advantage of these improvements.
...what? Am I missing something, because this doesn't seem to be about type inference at all. Did we switch to another topic without me noticing? Nope, it continues:
The second part of the type inference section is not about using auto, but about declaring a type from an expression (rather than just defining it from another type). This is can be useful in a statically typed language, especially in templates where it might be difficult to indirectly access types.
If I'm alarmed, it's because C++ was already bloated from the first attempt at this -- backporting objects and exceptions to C.
If by bloated you mean a rich feature set that takes time to learn, then yes. If by bloated you mean a syntax that is sometimes convoluted because of the need for backward compatibility, then yes. But I'm not sure if this is what you mean. The design of C++ was deliberately done to maintain the performance and efficiency of C. Adding objects has no effect on that (apart from a single pointer indirection in some circumstances, and an additional pointer where a hierarchy has virtual methods). Exceptions are of zero impact if you choose not to use them, and even if you do, are inefficient only when thrown. C++ does not force you to use all of the different constructs; there are many cases where it is quite sensible to use a subset (such as in embedded programming).
as these are mostly taking the good ideas from other languages and backporting them to C++
I think you'll find that all languages borrow ideas for each other, and C++ is no exception. But a lot of these ideas have been on the table for many years now, it isn't like they are that new in the C++ world. It is just that C++ is an important language, and no-one wants to break it, or introduce poorly thought out features that we will be stuck with. C++ doesn't have the luxury of redefining the language completely, it is both a strength and a weakness.
why store it all twice?
Having looked into the info tech post-grad courses at both RMIT and CSU, I noticed that while connectivity might not have been an issue, the RMIT course was heavily Windows oriented (ie, in order to complete the coursework, a student had to make extensive use of particular Windows only applications). On the other hand, at CSU (which is more geared towards distance education), using Linux has been much easier; there is an emphasis on using online applications (such as shared documents, wikis, etc) that are platform agnostic, and the only issue has been dealing with messy DRM on some materials from the library (which is not something I imagine that the university can do much about).
What 'backs up' the dollar?
Apparently your government does. How much debt are they in again?
Consciousness seems to play a role in this, as it seems our measurement of either the momentum or the position of an electron seems to fundamentally change its properties.
Saying that the measurement 'changes' the properties is an interpretation. There is an interesting correlation between the measurement and the change in properties; using terms implying causation is starting to move into the area of interpretation. These different interpretations are philosophically interesting, but it is hard to come up with ways to distinguish them experimentally.
For example, in a many-worlds interpretation, the different particle states 'cause' the multiplicity of conscious states. Or there is even the time-symmetric interpretation, where there is 'retro-causality' as well as 'causality'.
While the ARM is perhaps harder to write assembler for, it has a beautifully orthogonal instruction set, great for a compiler (and lets face it, if you are writing more than 10% of your code in assembler, you must have some horribly stringent requirements).
Having said that, the AVR is one of the nicer 8 bit instruction sets, and not a bad introduction to assembler. Since the AVR chips don't have some of the memory and I/O complexity of the more powerful microcontrollers, they are great for light projects. But once you have any amount of calculations, there just isn't the processing power. It isn't an apples vs apples comparison, these architectures are in different classes.
You might be thinking of uv erasable eproms, which could only handle a few thousand cycles. But that would have been about the time "The Godfather" was showing in the cinemas.
I think we are in agreement, though you perhaps described it better. Keeping details of the system secret involves an 'obscurity' that is difficult to measure; exactly how hard is it to guess the architecture or algorithms? It is poor security because it is ill-defined.
On the other hand, the GP was pointing out that a credential is a form of data 'obscurity'. But while that is true in some literal sense, it isn't the generally accepted meaning of the term 'security through obscurity'.
An interesting discussion example would be the idea of putting ssh onto a non-standard port. Although this relies on a 'random' piece of data (which port), it still tends to be thought of as security through obscurity.
While you have a point that many security methods such as passwords rely on 'obscurity', one can still make a distinction between methods which rely on poorly measured (and typically low) entropy and methods which rely on well defined entropy. Usually when people talk about the dangers of security through obscurity, they are talking of the former; the use of methods such as pass-phrases have well defined entropy, and the degree of difficulty ('obscurity') is controlled. Of course, pass-phrases are not a magic bullet if there are other ways to discover them (such as when they are sent plaintext over the network).
Perhaps the null hypothesis is that there are no intelligent living things (at least in Texas). I propose that we call this 'Unintelligible Design'.