In soviet russia, 98% of the population was satisfied with the current regime. But no matter who you speak to, you always encounter people in the other 2%
I'd think it was the other way around: 98% of the population was not satisfied with the regime, but whoever the police spoke to, they always encountered people in the other 2%.
This is very x86-centric. Most RISC CPUs don't have an extended precision, and some super computers have multiple extended precision modes.
You misunderstand. "Extended precision", in D, means "the highest precision type available". For most RISC processors, this would just be double precision; for some others, this might be quadruple precision. Of course, this means that extended precision should only ever be used if you don't plan on moving data between systems.
The reason the IEEE 754 standard does not specify exactness for transcendentals is because there are no provably known finite algorithms for computing them.
Of course. But consistency is more important than accuracy -- I'd like to see a standard which says "sin(x) is defined to be the result of running algorithm xyz, and will be within 1.5ulp of the mathematically correct value".
One of the changes since the last time we heard about D is the addition of floats and doubles (32 bit and 64 bit floating-point types, respectively) in addition to the "extended" type (as much precision as available). This is absolutely a Good Thing -- extra precision can be just as bad as insufficient precision, and adding these types allows people to ensure that they're using the right precision.
It would have been really nice to see the same thing for the math library functions; as it is, the only sin function is an extended -> extended function. IEEE doesn't require determinism on transcendental functions the way it does for arithmetic functions (which, I'm guessing, is why it isn't provided here), but there are times when it would be quite helpful.
Remember, there are times when getting the right wrong answer is more important than getting the right answer.
Of course it is a contrived example. But the point remains: As soon as you create a subclass which overrides some of the superclass' methods, encapsulation is broken -- you need to have some understanding of how the superclass is implemented, and changes in how the superclass is implemented can break your subclass.
Nonsense. That's what documentation is for. If you're really paranoid about having your methods overridden, do this:
Allow me to present an example from a paper by Jeremy Gibbons because I'm too lazy to come up with my own.
Consider the class CharArray:
public class CharArray {
protected char []chars; public CharArray(){ chars =new char [100 ]; chars [0 ]='\0 '; } public String getString(){ int i;for (i =0;chars [i ]!='\0 ';i++); return new String(chars,0,i); } public void insert (char c,int pos){ int i;for (i =0;chars [i ]!='\0 ';i++); for (;i>=pos;i--)chars [i+1 ]=chars [i ]; chars [pos ]=c; } public void prefix (char c){ insert (c,0); } }
Suppose you want to create a subclass CharArrayLength, which adds an attribute "Length", and a method "getLength".
Which functions do you override? Obviously, you create a new constructor which calls the old constructor and initializes Length to zero; but how do you update Length?
If you override both CharArray.insert and CharArray.prefix, you'll end up updating Length twice when CharArrayLength.prefix is called; but you have no way of knowing this unless you can see how CharArray.prefix is implemented. Even worse, if someone later changes the implementation of CharArray (for example, to make CharArray.prefix perform the insert itself, instead of calling.insert), it will break your subclass.
if you think inheritance is the biggest advantage of C++ over C, then you are (as politely as I can put this) completely ignorant of the language...
C++ provides:
* a string class that's far more resistant to buffer overflows than char*s; ...
I'm a bit confused here. Are you seriously suggesting that the addition of a heap-allocated dynamically-resized string type is more important than inheritance?
One of them is a few kilobytes of library code; the other is a fundamental change to the language semantics.
As far as your argument with exceptions, if checking return codes is better, people will use that; if exception code is better, why should you force them to check return codes?
Many libraries report errors only through their return codes. My complaint is that people get used to only checking for exceptions, and then don't check the return codes in places where that is the only indication of errors.
Ever consider your users might have more of an idea down the road what changes need to be made than you do at the moment?
I'm sure the people using my code will have more of an idea than I of what they want to use it for; however, I'm equally sure that they will have less of an idea than I of how my code works.
The whole idea behind encapsulation is to allow people to treat your code as a black box -- they don't need to know how your code works. Inheritance breaks this -- people need to know how your code works in order to know which functions need to be overridden.
There are plenty of no cost C++ features that are reasons to use C++, even if you are just using it as a "better C".
That depends upon exactly how you define "no cost". I consider overloading (of operators and functions) to be useful for little more than foot-shooting; and I have yet to see anything which can be done with templates which can't be done with either preprocessor code or more function pointers. I don't like exceptions either -- they seem to teach people to not check return codes.
Ok, anonymous unions are nice, and C++ style comments are sometimes useful. But there aren't many C compilers left which don't support those.
Anything which you can do with objects, I can do by passing function pointers around. The difference is that I'll be doing it deliberately, and as a result I'll be forced to think about what I'm doing.
If you know what you're doing, and you're the only person who is going to be using your code, objects are a very powerful tool; otherwise, objects are simply a very powerful way to shoot yourself in the foot.
Do you want your compiler saving registers and setting up stack frames behind your back?
Saving registers and setting up stack frames happens below the level of the language; the code which is inserted to do that will not effect the sequence of lines of code which get executed.
Inheritance and overriding functions is different: It allows other people to insert their code in the middle of my code. If I want to have people doing that, I'll allow them to pass me a function pointer; but in most cases I want to be able to make internal assumptions about how my code works without having inheritors break them.
As for regular C... I don't think anyone out there goes "I only know C, I don't use C++ because I hate OOP and all the new extensions and improvements and such."
I do. Inheritance breaks encapsulation. If I want to pass around function points, I'll pass around function pointers; I'll not have the compiler doing it behind my back.
You're missing a level of indirection. 2+2 is easy. Teaching kids that 2+2=4 is easy. Working out the best way of teaching kids that 2+2=4 is not easy.
A graduate degree in education isn't about being good at teaching; it's about being able to explain to other people how to be good at teaching.
Ask your supervisor. Unless I'm misreading the submission, you're a PhD student right now; your supervisor (and the university ethics committee) will be *far* more capable of answering this question than anyone on slashdot.
Personally, I'd just get parents to sign the same sort of forms as you'd have them sign right now (saying that they give permission for you to record proceedings, that they give permission for you to publish your research after removing any details which would identify the participants, and saying that they can withdraw at any point); but I'm sure your university can give you a much more detailed answer than this.
If I'm reading the story right (and it's 2:30 AM here, so maybe I'm not), the "news" here is that NASA has thrown a more efficient type of fuel cell onto a solar powered wing, thereby allowing it to store energy so that it can remain powered overnight.
Why don't they just use gravity instead? These wings already have motors and propellors; at night, these could be used as generators. The energy obtainable by dropping a few kilometers -- hardly a big deal for a wing 40km up -- would be just as much as could be stored in fuel cells, and the entire system would be much simpler and cheaper.
The NASA guys are pretty smart, so I'm sure I've missed something here; but what?
Re:Let's hope this means the end of veal
on
Lab-Grown Steak
·
· Score: 2
I'm sure human meat is even better for consumption.
I doubt it. Generally speaking, vegetarians make much better food than carnivores.
Given that galaxies take hundreds of millions of years to form -- the article describes this one as about 100 million years old and still in the early stages of formation -- I doubt that the galaxy has formed yet.
Saturday? Man, somebody needs a better proofreader.
No, it's quite true. Titan was indeed one of 30 moons orbiting Saturday. It was also orbiting on Sunday, Monday, Tuesday, Wednesday, Thursday, and Friday.
Slashdot Mirror
In soviet russia, 98% of the population was satisfied with the current regime. But no matter who you speak to, you always encounter people in the other 2%
I'd think it was the other way around: 98% of the population was not satisfied with the regime, but whoever the police spoke to, they always encountered people in the other 2%.
This is very x86-centric. Most RISC CPUs don't have an extended precision, and some super computers have multiple extended precision modes.
You misunderstand. "Extended precision", in D, means "the highest precision type available". For most RISC processors, this would just be double precision; for some others, this might be quadruple precision. Of course, this means that extended precision should only ever be used if you don't plan on moving data between systems.
The reason the IEEE 754 standard does not specify exactness for transcendentals is because there are no provably known finite algorithms for computing them.
Of course. But consistency is more important than accuracy -- I'd like to see a standard which says "sin(x) is defined to be the result of running algorithm xyz, and will be within 1.5ulp of the mathematically correct value".
now where are the library functions?
One of the changes since the last time we heard about D is the addition of floats and doubles (32 bit and 64 bit floating-point types, respectively) in addition to the "extended" type (as much precision as available). This is absolutely a Good Thing -- extra precision can be just as bad as insufficient precision, and adding these types allows people to ensure that they're using the right precision.
It would have been really nice to see the same thing for the math library functions; as it is, the only sin function is an extended -> extended function. IEEE doesn't require determinism on transcendental functions the way it does for arithmetic functions (which, I'm guessing, is why it isn't provided here), but there are times when it would be quite helpful.
Remember, there are times when getting the right wrong answer is more important than getting the right answer.
If you want to use a scientific analogy I suggest "dominant": If a program combines GPL'd code with other code, then the entire program is GPL'd.
No; if I combine GPL code with (for example) Apache code, the result isn't GPL -- the result is undistributable.
I'd say that the most appropriate description of GPL is "deliberately incompatible".
Of course it is a contrived example. But the point remains: As soon as you create a subclass which overrides some of the superclass' methods, encapsulation is broken -- you need to have some understanding of how the superclass is implemented, and changes in how the superclass is implemented can break your subclass.
I once actually dared say I -knew- HTML when I was still in college.
;)
Yes, but when you were still in college, HTML was much simpler.
To go so far as to lock the black box is ridiculous.
You seem to be obsessed with the idea that I'm evil. Why?
Allow me to present an example from a paper by Jeremy Gibbons because I'm too lazy to come up with my own.
Consider the class CharArray:
Suppose you want to create a subclass CharArrayLength, which adds an attribute "Length", and a method "getLength".
Which functions do you override? Obviously, you create a new constructor which calls the old constructor and initializes Length to zero; but how do you update Length?
If you override both CharArray.insert and CharArray.prefix, you'll end up updating Length twice when CharArrayLength.prefix is called; but you have no way of knowing this unless you can see how CharArray.prefix is implemented. Even worse, if someone later changes the implementation of CharArray (for example, to make CharArray.prefix perform the insert itself, instead of calling
if you think inheritance is the biggest advantage of C++ over C, then you are (as politely as I can put this) completely ignorant of the language...
C++ provides:
* a string class that's far more resistant to buffer overflows than char*s;
...
I'm a bit confused here. Are you seriously suggesting that the addition of a heap-allocated dynamically-resized string type is more important than inheritance?
One of them is a few kilobytes of library code; the other is a fundamental change to the language semantics.
As far as your argument with exceptions, if checking return codes is better, people will use that; if exception code is better, why should you force them to check return codes?
Many libraries report errors only through their return codes. My complaint is that people get used to only checking for exceptions, and then don't check the return codes in places where that is the only indication of errors.
Ever consider your users might have more of an idea down the road what changes need to be made than you do at the moment?
I'm sure the people using my code will have more of an idea than I of what they want to use it for; however, I'm equally sure that they will have less of an idea than I of how my code works.
The whole idea behind encapsulation is to allow people to treat your code as a black box -- they don't need to know how your code works. Inheritance breaks this -- people need to know how your code works in order to know which functions need to be overridden.
There are plenty of no cost C++ features that are reasons to use C++, even if you are just using it as a "better C".
That depends upon exactly how you define "no cost". I consider overloading (of operators and functions) to be useful for little more than foot-shooting; and I have yet to see anything which can be done with templates which can't be done with either preprocessor code or more function pointers. I don't like exceptions either -- they seem to teach people to not check return codes.
Ok, anonymous unions are nice, and C++ style comments are sometimes useful. But there aren't many C compilers left which don't support those.
Anything which you can do with objects, I can do by passing function pointers around. The difference is that I'll be doing it deliberately, and as a result I'll be forced to think about what I'm doing.
If you know what you're doing, and you're the only person who is going to be using your code, objects are a very powerful tool; otherwise, objects are simply a very powerful way to shoot yourself in the foot.
Do you want your compiler saving registers and setting up stack frames behind your back?
Saving registers and setting up stack frames happens below the level of the language; the code which is inserted to do that will not effect the sequence of lines of code which get executed.
Inheritance and overriding functions is different: It allows other people to insert their code in the middle of my code. If I want to have people doing that, I'll allow them to pass me a function pointer; but in most cases I want to be able to make internal assumptions about how my code works without having inheritors break them.
As for regular C... I don't think anyone out there goes "I only know C, I don't use C++ because I hate OOP and all the new extensions and improvements and such."
I do. Inheritance breaks encapsulation. If I want to pass around function points, I'll pass around function pointers; I'll not have the compiler doing it behind my back.
That was quick. Here's the important part (without the table tags):
Number of Job Listings by Programming Language (January 3, 2003)
monster.com hotjobs.com dice.com %
Java 2739 1000* 1957 27.82%
C++ 2103 1000* 1534 22.65%
Visual Basic 2070 969 1127 20.35%
Perl 955 517 577 10.01%
Javascript 925 455 498 9.17%
C# 290 235* 183 3.46%
Ada 384 175 57 3.01%
Fortran 124 68 48 1.17%
Scheme 39* 138* 46* 1.09%
Python 58 43 33 0.65%
Smalltalk 42 27 32 0.49%
Lisp 12 4 9 0.12%
9741 4631 6101
* hotjobs.com changes a search of "C#" to a search of "C", so I averaged monster and dice.
* hotjobs.com limits the number of results that a query can return to 1000.
* Searching on the term "scheme" may result in false positives.
To teach 2+2 to kids?
You're missing a level of indirection. 2+2 is easy. Teaching kids that 2+2=4 is easy. Working out the best way of teaching kids that 2+2=4 is not easy.
A graduate degree in education isn't about being good at teaching; it's about being able to explain to other people how to be good at teaching.
Ask your supervisor. Unless I'm misreading the submission, you're a PhD student right now; your supervisor (and the university ethics committee) will be *far* more capable of answering this question than anyone on slashdot.
Personally, I'd just get parents to sign the same sort of forms as you'd have them sign right now (saying that they give permission for you to record proceedings, that they give permission for you to publish your research after removing any details which would identify the participants, and saying that they can withdraw at any point); but I'm sure your university can give you a much more detailed answer than this.
You ever try to fly 40km up using a propeller?
Hint: Not much air up there for such things.
Ok, s/40/30/. This (propellor-driven) wing has been tested at that altitude.
If I'm reading the story right (and it's 2:30 AM here, so maybe I'm not), the "news" here is that NASA has thrown a more efficient type of fuel cell onto a solar powered wing, thereby allowing it to store energy so that it can remain powered overnight.
Why don't they just use gravity instead? These wings already have motors and propellors; at night, these could be used as generators. The energy obtainable by dropping a few kilometers -- hardly a big deal for a wing 40km up -- would be just as much as could be stored in fuel cells, and the entire system would be much simpler and cheaper.
The NASA guys are pretty smart, so I'm sure I've missed something here; but what?
I'm sure human meat is even better for consumption.
I doubt it. Generally speaking, vegetarians make much better food than carnivores.
Or rather, threaten to countersue (for lost time and costs) unless they provide evidence and help you.
Given that galaxies take hundreds of millions of years to form -- the article describes this one as about 100 million years old and still in the early stages of formation -- I doubt that the galaxy has formed yet.
"... Titan, one of 30 moons orbiting Saturday ..."
Saturday? Man, somebody needs a better proofreader.
No, it's quite true. Titan was indeed one of 30 moons orbiting Saturday. It was also orbiting on Sunday, Monday, Tuesday, Wednesday, Thursday, and Friday.
FTP? C'mon!
FTP is perfectly secure if you run it over IPSec.
I doubt they're actually using IPSec here, but I'm sure they have some form of encryption built into the lower protocol layers.