I want to see the airplane problem solved by taking away the entire motive.
Great idea. Unfortunately that's not so easy...
Rip out the ENTIRE cockpit and have the plane flown on autopilot from takeoff to landing.
Great. Them the terrorists don't actually have to enter the plain, they just have to hack into it. However, I guess it's a great way to reduce cost for the airlines, and security would be a great excuse to make the passengers accept it:-)
Work on the technology needed to make it work and put the computers needed to do it somewhere that can not be accessed in flight by any means. No remote access either.
But the computers must be accessible somehow. After all, it's not uncommon that there are problems either on the plain or on the destination airport, and the plane must be redirected to another airport. And as long as there's an interface for that, there's a possibility that terrorists will be able to use it, some way or another.
You program the plane to take off, flight to the destination and land.
And in case of an emergency (or just bad weather), you cannot redirect it to another airport, or even just tell it to wait until the runway is clear. Well, bad luck for the passengers...
At that point you won't have terrorist attacks anymore since there is no way to negotiate.
At that point you won't have any terrorist attack anymore because no sane person would fly in such a plane. Ok, that would probably be good for the environment:-)
The worse they can do is just blow up the plane.
Which means that you would still need security checks anyway. Unless you think blowing up a plane is not much of a problem.
They can't ram it into a building,
Unless they manage to change the programming before the plane even starts (in which case, after the plane took off, your scenario means there's no way to stop that program, except by shooting the plane).
they can't take it somewhere to get hostages released
See above. And as I already said, this also means you can't get it somewhere to safely land when there's a problem.
and they can't threaten the pilots in any way.
Of course. Which means, they'll just instead threaten to blow up the plane if they don't get what they want. Or maybe just kill all passengers (shooting a hole into one window after sabotaging the oxygen mask system should be enough for that, or they just use some poison gas; OTOH killing the passengers one-by-one might be more effective from the terrorist's view).
But again, even if that would make the airplanes completely terror-safe, I wouldn't get onto such a plane. The probability of a plane having problems is much higher than the probability of a plane being highjacked. Therefore I'd prefer a plane where I have a good chance to survive simple problems than a plane where I'm completely safe from terror attacks, but every unforseen problem will cause a likely desaster.
Unless you manage to build an AI which is at least as reliable as a normal pilot even in unexpected situations, I'm not going to fly on a plane which cannot be controlled by humans in any way. And even if you manage to build such an AI, it will have to rely on outside information for even such simple things as avoiding a thunderstorm or waiting for the runway to be clear.
To actually detect lies, you have to know everything the person making a statement knows
Of course if you know everything the person making a statement knows, there's no point in using a lie detector, because then you already know if what the person said is a lie (after all, that's one of the things the person certainly knows).
int main() { while (!wall.empty()) { bottle_of_beer current_beer = wall.front(); wall.pop_front(); current_beer.drink(); } std::cout << "Oops, no beers left, better get some you drunken bastard!" << std::endl; return EXIT_SUCCESS; }
If messages_processed is a relatively good name, totalMessages is a misleading name: The variable doesn't count all messages, but only those which were processed. totalMessagesProcessed (or total_messages_processed) would be a better name. So would be messages_processed_counter, numofMessagesProcessed or cnt_msg_processed.
FOUR_HUNDRED_FIFTY_SIX is a bad name, because it still doesn't tell you anything about the value. Better use a descriptive name like MAGIC_VALUE or VALUE_THAT_WORKS.
Of course x should get a better name, too. what is x? Well, I guess it's a variable, but then, it could also be a macro expanding to whatever. Therefore an improved version could look like this:
if (variable == MAGIC_VALUE)// check if step motor reached final position
Now it's clear what's going on: You compare a variable with a magic value in order to find out if the step motor has reached its final position.
He didn't assert that it should be read left-to-right, but that it should be written in a way that reading it left-to-right makes sense. And a bad example violating it cannot ever demonstrate the invalidity of a general rule to follow (e.g. you cannot disprove the rule "don't kill" by saying that Jack the Ripper has already set a killing precedent).
He just said "not buying". He didn't say "stealing" (or "copying", for that matter). I haven't bought any laser printer up to now. Must I now fear to go to jail for stealing a laser printer?
No, Sony would have been ok if they had installed a README with their rootkit explaining that their digital rights management solution contained code distributed under the LGPL license, and direct users of the software to a website containing the source code.
Moreover, the gcc runtime libraries (the only part of gcc which ends up in gcc compiled code, and therefore could affect the licensing) all have special exceptions to the GPL, so that they don't cause the programs they are linked to to be covered by the GPL.
The fact that C declaration syntax is bad isn't in any way affected by the fact that it's also used in C++. Please read the quoted sentence again. Note that the word "C++" doesn't actually appear in it. My side remark was just preventive against the wrong argument that since C++ has not changed the C declaration syntax (except for adding syntax for C++-only features) would somehow imply that there's something good about the C declaration syntax.
THe shared library would have to be loaded at the exact same memory location for virtual pointers to work. What you're suggesting might be doable, but it would not be very easy, or very efficient.
Read again what I wrote as example implementation (I've added emphasis to help you understanding):
instead of the pointer to a VMT, it would contain an offset into the constant data section of the shared library, and something to identify the library with, say a system-wide unique active library index which is generated by the dynamic linker.
So you see, no pointer in the object.
And yes, it would be less efficient than a simple virtual function call (it would certainly only be used for objects meant to be shared). Basically there would be a lookup of the unique library index in some table (probably a hash table) to get the base pointer of the library (local to the current process), followed by adding the offset. But I doubt you can get equivalent functionality much more efficiently (apart from obvious optimizations like taking advantage of the fact that in the context of a process the VMT pointer is constant during the life time of the object, and therefore doesn't need to be recalculated if several virtual functions of the same object are called in a row).
There's also the problem of subclasses. If class Foo is in the shared library, but the app makes an instance of Bar (a child of Foo), that overrides any of the virtual functions you'd be in trouble.
Of course you only can share objects if you also share their code. I guess it's obvious that for shared objects, the code would also have to be in shared libraries. Although I guess one could even get around this limitation if one designed an executable format with "sharable sections", together with system calls to load those in other programs based on e.g. the process ID. The code for sharable classes, together with the vtbl, would then go into such sharable sections.
All in all, it just doesn't seem worth the trouble. Just put your data in a stuct with no virtual functions. If you're an OO purist and absolutely need to have your hierarchies and member functions, use a wrapper class with a constructor that takes tghe struct as an input to instantiate the object.
Maybe it's not worth the trouble. But that was not my point. The point was that you could design a system where it works, but I don't believe a portable implementation is possible.
Actually, foo is an immutable pointer to a possibly immutable integer (it can also point to a mutable integer).
Now, you hopefully don't think C++ declaration syntax (which is this way due to C backwards compatibility) is something you should imitate. Indeed, Bjarne Stroustrup himself said: "I consider the C declarator syntax an experiment that failed." (in the answer to question 3, paragraph 4)
while (true)// while(1) for C {
x = foo(); if (x == -1) break; ... }
I consider this cleaner than the combined assignment/compare in the while condition. YMMV. Note that if you ever need to replace the simple call to foo() by something more complex, you'll have to switch to this form anyway, or it will become unreadable quite quickly.
And yes, it's still single entry/single exit - it's just that the exit is syntactically in the middle of the loop body.
consider the backwards comparison to be good C style. It turns a certain broad class of typo from a silent logic error into a compiler error. How many times have you seen
Doesn't MS code use CWhatever? I guess the author is coming from a Java background (I for Interface).
BTW, the very first file is not valid C++: All identifiers which contain double underscores are everywhere and under all circumstances reserved for the implementation. This also includes __COMMON_H__. Change it to e.g. COMMON_H to get valid C++.
It can place complex objects and STL-like containers in shared memory.
Depends on your definition of "complex objects".
From the documentation:
Virtuality forbidden
This is not an specific problem of Shmem, it is a problem for all shared memory object placing mechanisms. The virtual table pointer and the virtual table are in the address space of the process that constructs the object, so if we place a class with virtual function or inheritance, the virtual function pointer placed in shared memory will be invalid for other processes.
Basically, I would have been surprised if they had found a solution for that. But I guess it cannot be portably solved. Instead, the system would have to be prepared for it. I could imagine that objects in a shared library (so the same code is guaranteed to be shared to both processes) could be placed in shared memory, if the compiler/runtime system provided the means for it (say, instead of the pointer to a VMT, it would contain an offset into the constant data section of the shared library, and something to identify the library with, say a system-wide unique active library index which is generated by the dynamic linker).
Slashdot Mirror
Great idea. Unfortunately that's not so easy
Great. Them the terrorists don't actually have to enter the plain, they just have to hack into it. However, I guess it's a great way to reduce cost for the airlines, and security would be a great excuse to make the passengers accept it
But the computers must be accessible somehow. After all, it's not uncommon that there are problems either on the plain or on the destination airport, and the plane must be redirected to another airport. And as long as there's an interface for that, there's a possibility that terrorists will be able to use it, some way or another.
And in case of an emergency (or just bad weather), you cannot redirect it to another airport, or even just tell it to wait until the runway is clear. Well, bad luck for the passengers
At that point you won't have any terrorist attack anymore because no sane person would fly in such a plane. Ok, that would probably be good for the environment
Which means that you would still need security checks anyway. Unless you think blowing up a plane is not much of a problem.
Unless they manage to change the programming before the plane even starts (in which case, after the plane took off, your scenario means there's no way to stop that program, except by shooting the plane).
See above. And as I already said, this also means you can't get it somewhere to safely land when there's a problem.
Of course. Which means, they'll just instead threaten to blow up the plane if they don't get what they want. Or maybe just kill all passengers (shooting a hole into one window after sabotaging the oxygen mask system should be enough for that, or they just use some poison gas; OTOH killing the passengers one-by-one might be more effective from the terrorist's view).
But again, even if that would make the airplanes completely terror-safe, I wouldn't get onto such a plane. The probability of a plane having problems is much higher than the probability of a plane being highjacked. Therefore I'd prefer a plane where I have a good chance to survive simple problems than a plane where I'm completely safe from terror attacks, but every unforseen problem will cause a likely desaster.
Unless you manage to build an AI which is at least as reliable as a normal pilot even in unexpected situations, I'm not going to fly on a plane which cannot be controlled by humans in any way. And even if you manage to build such an AI, it will have to rely on outside information for even such simple things as avoiding a thunderstorm or waiting for the runway to be clear.
Of course if you know everything the person making a statement knows, there's no point in using a lie detector, because then you already know if what the person said is a lie (after all, that's one of the things the person certainly knows).
Previewed twice, and still an error: <stdlib> should of course be <cstdlib> (or at least <stdlib.h>)
#include <iostream>
#include <stdlib>
#include <deque>
#include "beer.h"
int const initial_number_of_bottles = 99;
std::deque<bottle_of_beer> wall(initial_number_of_bottles, bottle_of_beer::full_bottle())
int main()
{
while (!wall.empty())
{
bottle_of_beer current_beer = wall.front();
wall.pop_front();
current_beer.drink();
}
std::cout << "Oops, no beers left, better get some you drunken bastard!" << std::endl;
return EXIT_SUCCESS;
}
If messages_processed is a relatively good name, totalMessages is a misleading name: The variable doesn't count all messages, but only those which were processed. totalMessagesProcessed (or total_messages_processed) would be a better name. So would be messages_processed_counter, numofMessagesProcessed or cnt_msg_processed.
Why do you consider indenting by 2 spaces as stupidity?
And how can the result of this rule be that developers use tabs?
FOUR_HUNDRED_FIFTY_SIX is a bad name, because it still doesn't tell you anything about the value. Better use a descriptive name like MAGIC_VALUE or VALUE_THAT_WORKS.
// check if step motor reached final position
Of course x should get a better name, too. what is x? Well, I guess it's a variable, but then, it could also be a macro expanding to whatever. Therefore an improved version could look like this:
if (variable == MAGIC_VALUE)
Now it's clear what's going on: You compare a variable with a magic value in order to find out if the step motor has reached its final position.
Actually it's calculated by dividing your weight by the square of your height.
He didn't assert that it should be read left-to-right, but that it should be written in a way that reading it left-to-right makes sense. And a bad example violating it cannot ever demonstrate the invalidity of a general rule to follow (e.g. you cannot disprove the rule "don't kill" by saying that Jack the Ripper has already set a killing precedent).
Hey, that's a lame joke! :-)
He just said "not buying". He didn't say "stealing" (or "copying", for that matter). I haven't bought any laser printer up to now. Must I now fear to go to jail for stealing a laser printer?
What if they had installed a $Sys$README?
Moreover, the gcc runtime libraries (the only part of gcc which ends up in gcc compiled code, and therefore could affect the licensing) all have special exceptions to the GPL, so that they don't cause the programs they are linked to to be covered by the GPL.
To put it in short: Sony breaks copyright in a software intended to prevent breaking copyright. Great!
If you need a great headline, reformulate it as:
Sony anti-piracy software is pirated!
No, they edit it. If they would read it, they would be called readers.
Hey, sigs are valuable IP. Stop copying them, or maybe Slashdot will be shut down for hosting evil sig pirates!
The fact that C declaration syntax is bad isn't in any way affected by the fact that it's also used in C++. Please read the quoted sentence again. Note that the word "C++" doesn't actually appear in it.
My side remark was just preventive against the wrong argument that since C++ has not changed the C declaration syntax (except for adding syntax for C++-only features) would somehow imply that there's something good about the C declaration syntax.
Read again what I wrote as example implementation (I've added emphasis to help you understanding):
instead of the pointer to a VMT, it would contain an offset into the constant data section of the shared library, and something to identify the library with, say a system-wide unique active library index which is generated by the dynamic linker.
So you see, no pointer in the object.
And yes, it would be less efficient than a simple virtual function call (it would certainly only be used for objects meant to be shared). Basically there would be a lookup of the unique library index in some table (probably a hash table) to get the base pointer of the library (local to the current process), followed by adding the offset. But I doubt you can get equivalent functionality much more efficiently (apart from obvious optimizations like taking advantage of the fact that in the context of a process the VMT pointer is constant during the life time of the object, and therefore doesn't need to be recalculated if several virtual functions of the same object are called in a row).
Of course you only can share objects if you also share their code. I guess it's obvious that for shared objects, the code would also have to be in shared libraries. Although I guess one could even get around this limitation if one designed an executable format with "sharable sections", together with system calls to load those in other programs based on e.g. the process ID. The code for sharable classes, together with the vtbl, would then go into such sharable sections.
Maybe it's not worth the trouble. But that was not my point. The point was that you could design a system where it works, but I don't believe a portable implementation is possible.
Actually, foo is an immutable pointer to a possibly immutable integer (it can also point to a mutable integer).
Now, you hopefully don't think C++ declaration syntax (which is this way due to C backwards compatibility) is something you should imitate. Indeed, Bjarne Stroustrup himself said: "I consider the C declarator syntax an experiment that failed." (in the answer to question 3, paragraph 4)
And yes, it's still single entry/single exit - it's just that the exit is syntactically in the middle of the loop body.
The programmer actually meant:
Doesn't MS code use CWhatever? I guess the author is coming from a Java background (I for Interface).
BTW, the very first file is not valid C++: All identifiers which contain double underscores are everywhere and under all circumstances reserved for the implementation. This also includes __COMMON_H__. Change it to e.g. COMMON_H to get valid C++.
Well, at least his main function returns int.
Well, that should be a safe choice, because no sane person would use 0x1234, therefore this key is still unused.
Depends on your definition of "complex objects".
From the documentation:
Virtuality forbidden
This is not an specific problem of Shmem, it is a problem for all shared memory object placing mechanisms. The virtual table pointer and the virtual table are in the address space of the process that constructs the object, so if we place a class with virtual function or inheritance, the virtual function pointer placed in shared memory will be invalid for other processes.
Basically, I would have been surprised if they had found a solution for that. But I guess it cannot be portably solved. Instead, the system would have to be prepared for it. I could imagine that objects in a shared library (so the same code is guaranteed to be shared to both processes) could be placed in shared memory, if the compiler/runtime system provided the means for it (say, instead of the pointer to a VMT, it would contain an offset into the constant data section of the shared library, and something to identify the library with, say a system-wide unique active library index which is generated by the dynamic linker).
That's nothing against my pending patent on receiving money. I look forward to your new revenue, because half of it will go to me as licensing fee.