But the southern sky is more interesting anyway. We have a centaur with a sword, a clock, a ship, a scorpion,..., you only have crappy Greek heroes and bears
How do they overcome the problem of the phone being lost or stolen, and somebody else just using up all the person's available Paypal account? This is a pretty serious concern.
It's not the crash that kills you it's the sudden acceleration (your body going from 30 to 0 mph in a second).
No, that's not true either. It may have been true in the 1960s when cars were rigid steel and a crash produced very high accelerations. But modern cars are designed with "crumple zones" (in fact, in most countries, new car registrations must comply with crumple regulations). So in a frontal crash, the front of your car will be totally fucked up and the engine will be pushed under the rest of the car -- firstly, absorbing a lot of the kinetic energy, and secondly, making the deceleration occur over a longer time period.
The human body can withstand 30+ G's of deceleration, if you recall that guy who offered himself as a crash test dummy..
When brakes lock up and wheels don't spin anymore, the ABS reduces the force transmitted to the brakes until the wheels spin again.
Not quite. The ABS kicks in BEFORE the brakes lock up. By closely monitoring the wheel's angular velocity, they can detect when a lockup is a few milliseconds away. ABS would be totally ineffective if it waited until after a lock-up: in the wet, it can be 10 times harder, or more, for a tyre to regain traction once it is sliding, than it is for the tyre to lose traction in the first place (that's just a fact of rubber physics).
However, the benefits of ABS and being able to avoid the collision outweighs the costs of reduced stopping force. So for the untrained driver who simply hits the brakes and waits for impact, ABS can result in higher impact velocities. but used correctly, ABS can help you avoid a collision altogether.
Well said. Unfortunately, if you switch "ABS" for "speeding" [*], the statement is still absolutely true, but now we have thousands of people bleating about "ignorance of physics" and "crash energies are higher", "two legs good four legs bad", etc.
AFAIC the difference between being 95% likely to die in a 60MPH crash versus 99% likely to die in a 90MPH crash, does not outweigh the benefits of being much more likely to avoid the crash in the first place. (NB - I pulled those figures out of my ass, but you get the point).
[*] By 'speeding', I mean 'driving faster than the flow of traffic', I don't include reckless drivers who take a blind bend faster than they can stop if there is a deer around the corner, etc.
Hey now, in C++ the correct version is x = static_cast(y * 3);
Actually my code was correct. An alternative form would be:
x = static_cast(y * 3);
which is even uglier.
Seriously though, the cast is a reminder to a maintenance programmer that "hey, x is an unsigned int!". It's also a step in the self-documenting code process.
How about later when you decide you really did want x to be a float? Now you will have an obscure bug of the same sort that the OP was complaining about, which would not have been present had you not used the cast! There will be no compiler warning or error in either C++ or Java (which allows widening conversions without a cast).
As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object.
The "property" keyword lets you do the "private data, public accessor" thing without having trivial wart functions all over the place. Have you ever looked at a Java file? Half of it is " int getFoo() { return foo; } " .
Here's some syntax from the Borland compiler (which supports properties):
class X
{
int m_foo;
public:
__property int foo = { read=m_foo, write=m_foo };
};
Then, when you want to make the set-function do something non-trivial, you can change the class definition and not have to re-write any client code:
class X
{
int m_foo;
void set_foo();
public:
__property int foo = { read=m_foo, write=set_foo };
};
The major problem (for me) with properties is that it means a simple assignment can have side-effects, which might be unexpected. I'm not sure whether this means I should flame properties, or change my attitude.:)
Yes, "overriding" is only used when talking about polymorphic (virtual) functions in derived classes. The function in the derived class overrides the one in the base class.
in C++, overloading refers both to operator overloading and to function overloading, (which is what you were thinking of when you made the comment about the + operator, though + really is an operator, not a C++ function).
There is no semantic difference between a function and an operator that operates on at least one user-defined type. The "function" uses function-call syntax and the "operator" uses infix syntax. If foo is a user-defined type, then (foo + bar) is entirely the same as operator+(foo, bar) . In fact you can even use the latter form if you want (although that kind of defeats the purpose of operator "overloading").
I'll never understand why it's not possible to even enable bounds checking in STL arrays...
It is possible. STL vectors (I suppose that is what you mean) have two forms of syntax for member access: one with bounds-checking, and one without.
The C++ standard doesn't define what happens if you use the non-bounds-checking syntax and do an out of bounds access. It is then up to the individual compiler to decide what to do. For example, the Borland compiler suite (the non-free version) can catch out-of-bounds memory access and cause the debugger to stop and tell you what happened, etc.
Your points seem to be a list of syntax incompatibilities between C and C++. This misses the point of the OP, who said that to him, C++ works well as C with some extensions. He never claimed the syntax was identical and he wasn't claiming that he compiles C with a C++ compiler. Obviously if he ran into any of the issues you listed, he'd have to make a slight code modification.
C++ has synonyms for certain operators such and "and" for "&&", "not" for "!", etc. and the macro preprocessor "knows about" them.
Actually these were first defined in the 1994 revision of the C standard (also known as TC1), and then adopted by C++. Try #include <iso646.h> in your C program.
const qualifiers in C result in a variable that has external (static) linkage and therefore is visible to other modules; in C++, const items by default have internal linkage, and must be explicitly prefix by "extern" to behave as C const objects do.
Slightly odd way of writing that; as the C++ behaviour is far more desirable.
If you're talking about a header file, then defining an object with external linkage (const or not) causes undefined behaviour in both C and C++ if the header file is used in two or more units.
If you're talking about a non-header file, then it is a stupid idea to deliberately declare an object with external linkage without having an extern definition in a corresponding header file. (Either it will never be used by another TU, in which case it might as well have internal linkage; or the other TU will have to include an extern declaration, which is prone to error). And if there is an extern declaration in a header file then the definition is automatically extern, whether it's explicitly specified or not.
A "type-paranoid" language would generate a comple error. If I write:
unsigned int x;
float y;.....
x = y * 3;
then I want y to be multiplied by 3 and then assigned to x.
A "type unsafe" language (like C++) would auto-cast without telling you and leave you scratching your head for hours trying to figure out why the results are not what you expected.
What else could you possibly expect from the above code? If you wanted a float result you would have used a float variable.
For example, the string stream system in C++ was just dumb; the string stream approach was ridiculously cumbersome. Plus, it provided the prototypical example of operator overloading abuse
Stringstreams don't overload any operators that I/O streams don't. It is exactly same as a file stream except that it reads and writes to a memory buffer instead of to a file. Then you can access that memory buffer as a string at any time.
the fact that there was no mechanism to use STL containers to hold any auto_ptr-like mechanism was just ludicrous.
Huh? You can put auto_ptr-like mechanisms in STL containers. In fact people use boost::shared_ptr in vectors regularly, to name but one.
(But not auto_ptr itself, which is a design flaw due to it being rushed in to the last standard without being fully debated, which is something you are in favour of it seems).
This was clearly filmed in an underwater TV studio. Current meteor technology is not up to the task of successfully hitting the Moon, and why does the crosshair on the photo appear behind the meteor?
I think it's more likely that the height of the liquid (regardless of width) affects how much we think is in the glass. Once a tall thin glass is 3/4 full we think "Wow that's a lot of drink" and wouldn't fill it right up to the top. But a short fat glass is still a short glass and would probably end up being filled to nearly the brim.
Slashdot Mirror
[pinkie in mouth] One hundred and fifty ... THOUSAND ... DOLLARS!!!
It seems obvious to me that they meant "span" (the past tense of "spin"):
e rbs/spin.html
http://www.usingenglish.com/reference/irregular-v
But the southern sky is more interesting anyway. We have a centaur with a sword, a clock, a ship, a scorpion, ..., you only have crappy Greek heroes and bears
How do they overcome the problem of the phone being lost or stolen, and somebody else just using up all the person's available Paypal account? This is a pretty serious concern.
Theo deRaadt
O, the dead rat!
I think the time is appopriate:
#include <stdio.h>
#define SIX 1+5
#define NINE 8+1
int main(void)
{
printf("SIX times NINE is %d\n", SIX * NINE);
return 0;
}
Shouldn't we at least land on the Moon before we start talking about a moon base ?
More likely, they paid attention to the low UID
Take the train next time..
> 6. Get modded down for a tired joke.
This is Slashdot, tired jokes get modded up !
IN SOVIET RUSSIA, YOU JOKE ABOUT MODDED TIRES!
It's not the crash that kills you it's the sudden acceleration (your body going from 30 to 0 mph in a second).
No, that's not true either. It may have been true in the 1960s when cars were rigid steel and a crash produced very high accelerations. But modern cars are designed with "crumple zones" (in fact, in most countries, new car registrations must comply with crumple regulations). So in a frontal crash, the front of your car will be totally fucked up and the engine will be pushed under the rest of the car -- firstly, absorbing a lot of the kinetic energy, and secondly, making the deceleration occur over a longer time period.
The human body can withstand 30+ G's of deceleration, if you recall that guy who offered himself as a crash test dummy..
When brakes lock up and wheels don't spin anymore, the ABS reduces the force transmitted to the brakes until the wheels spin again.
Not quite. The ABS kicks in BEFORE the brakes lock up. By closely monitoring the wheel's angular velocity, they can detect when a lockup is a few milliseconds away. ABS would be totally ineffective if it waited until after a lock-up: in the wet, it can be 10 times harder, or more, for a tyre to regain traction once it is sliding, than it is for the tyre to lose traction in the first place (that's just a fact of rubber physics).
However, the benefits of ABS and being able to avoid the collision outweighs the costs of reduced stopping force. So for the untrained driver who simply hits the brakes and waits for impact, ABS can result in higher impact velocities. but used correctly, ABS can help you avoid a collision altogether.
Well said. Unfortunately, if you switch "ABS" for "speeding" [*], the statement is still absolutely true, but now we have thousands of people bleating about "ignorance of physics" and "crash energies are higher", "two legs good four legs bad", etc.
AFAIC the difference between being 95% likely to die in a 60MPH crash versus 99% likely to die in a 90MPH crash, does not outweigh the benefits of being much more likely to avoid the crash in the first place. (NB - I pulled those figures out of my ass, but you get the point).
[*] By 'speeding', I mean 'driving faster than the flow of traffic', I don't include reckless drivers who take a blind bend faster than they can stop if there is a deer around the corner, etc.
Hey now, in C++ the correct version is x = static_cast(y * 3);
Actually my code was correct. An alternative form would be:
x = static_cast(y * 3);
which is even uglier.
Seriously though, the cast is a reminder to a maintenance programmer that "hey, x is an unsigned int!". It's also a step in the self-documenting code process.
How about later when you decide you really did want x to be a float?
Now you will have an obscure bug of the same sort that the OP was complaining about, which would not have been present had you not used the cast! There will be no compiler warning or error in either C++ or Java (which allows widening conversions without a cast).
As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object.
s /2002/n1377.htm
This is called "move semantics" and is part of the plan for C++0x (although Bjarne's article didn't make mention of it). See http://www.open-std.org/jtc1/sc22/wg21/docs/paper
The "property" keyword lets you do the "private data, public accessor" thing without having trivial wart functions all over the place. Have you ever looked at a Java file? Half of it is " int getFoo() { return foo; } " .
:)
Here's some syntax from the Borland compiler (which supports properties):
class X
{
int m_foo;
public:
__property int foo = { read=m_foo, write=m_foo };
};
Then, when you want to make the set-function do something non-trivial, you can change the class definition and not have to re-write any client code:
class X
{
int m_foo;
void set_foo();
public:
__property int foo = { read=m_foo, write=set_foo };
};
The major problem (for me) with properties is that it means a simple assignment can have side-effects, which might be unexpected. I'm not sure whether this means I should flame properties, or change my attitude.
Yes, "overriding" is only used when talking about polymorphic (virtual) functions in derived classes. The function in the derived class overrides the one in the base class.
in C++, overloading refers both to operator overloading and to function overloading, (which is what you were thinking of when you made the comment about the + operator, though + really is an operator, not a C++ function).
There is no semantic difference between a function and an operator that operates on at least one user-defined type. The "function" uses function-call syntax and the "operator" uses infix syntax.
If foo is a user-defined type, then (foo + bar) is entirely the same as operator+(foo, bar) . In fact you can even use the latter form if you want (although that kind of defeats the purpose of operator "overloading").
I realise this is a joke, but don't you have to boot the kernel before you can even access the /dev file system?
I'll never understand why it's not possible to even enable bounds checking in STL arrays...
It is possible. STL vectors (I suppose that is what you mean) have two forms of syntax for member access: one with bounds-checking, and one without.
The C++ standard doesn't define what happens if you use the non-bounds-checking syntax and do an out of bounds access. It is then up to the individual compiler to decide what to do. For example, the Borland compiler suite (the non-free version) can catch out-of-bounds memory access and cause the debugger to stop and tell you what happened, etc.
Your points seem to be a list of syntax incompatibilities between C and C++. This misses the point of the OP, who said that to him, C++ works well as C with some extensions. He never claimed the syntax was identical and he wasn't claiming that he compiles C with a C++ compiler. Obviously if he ran into any of the issues you listed, he'd have to make a slight code modification.
C++ has synonyms for certain operators such and "and" for "&&", "not" for "!", etc. and the macro preprocessor "knows about" them.
Actually these were first defined in the 1994 revision of the C standard (also known as TC1), and then adopted by C++. Try #include <iso646.h> in your C program.
const qualifiers in C result in a variable that has external (static) linkage and therefore is visible to other modules; in C++, const items by default have internal linkage, and must be explicitly prefix by "extern" to behave as C const objects do.
Slightly odd way of writing that; as the C++ behaviour is far more desirable.
If you're talking about a header file, then defining an object with external linkage (const or not) causes undefined behaviour in both C and C++ if the header file is used in two or more units.
If you're talking about a non-header file, then it is a stupid idea to deliberately declare an object with external linkage without having an extern definition in a corresponding header file. (Either it will never be used by another TU, in which case it might as well have internal linkage; or the other TU will have to include an extern declaration, which is prone to error). And if there is an extern declaration in a header file then the definition is automatically extern, whether it's explicitly specified or not.
A "type-paranoid" language would generate a comple error.
.....
If I write:
unsigned int x;
float y;
x = y * 3;
then I want y to be multiplied by 3 and then assigned to x.
A "type unsafe" language (like C++) would auto-cast without telling you and leave you scratching your head for hours trying to figure out why the results are not what you expected.
What else could you possibly expect from the above code?
If you wanted a float result you would have used a float variable.
I, for one, find
x = y * 3;
far easier to read and maintain than
x = (unsigned int)(y * 3);
Yecch.
For example, the string stream system in C++ was just dumb;
the string stream approach was ridiculously cumbersome.
Plus, it provided the prototypical example of operator overloading abuse
Stringstreams don't overload any operators that I/O streams don't.
It is exactly same as a file stream except that it reads and writes
to a memory buffer instead of to a file. Then you can access that
memory buffer as a string at any time.
the fact that there was no mechanism to use STL containers to hold any auto_ptr-like mechanism was just ludicrous.
Huh? You can put auto_ptr-like mechanisms in STL containers.
In fact people use boost::shared_ptr in vectors regularly, to name but one.
(But not auto_ptr itself, which is a design flaw due to it being
rushed in to the last standard without being fully debated, which
is something you are in favour of it seems).
This was clearly filmed in an underwater TV studio. Current meteor technology is not up to the task of successfully hitting the Moon, and why does the crosshair on the photo appear behind the meteor?
I think it's more likely that the height of the liquid (regardless of width) affects how much we think is in the glass. Once a tall thin glass is 3/4 full we think "Wow that's a lot of drink" and wouldn't fill it right up to the top. But a short fat glass is still a short glass and would probably end up being filled to nearly the brim.
In all my life, I've eaten no animal meat, nor fish, nor eggs. :)
Ironic.
More likely: Iron-deficient.