Yes, that's fallacy number one. Java isn't necessarily slower (or faster). (Often, the VM is a bottleneck, but that's a QOI issue; it has nothing to do with the language per se.)
Fallacy number two, of course, is that Java doesn't have pointers.:-} (A rose, by any other name...)
Scratch that... that's fallacy number three. Fallacy number two is that Java is platform-independent. (Hint: the JVM is a platform.)
Well, first of all, there are sometimes valid reasons for breaking speed limits (emergencies, etc). Second of all, not all roads are public. Thirdly, no one would pay lots of money for a new machine unless it went faster, etc. At least, the enthusiasts wouldn't, and we all know who drives the market.
And the far, *far* more frequent scenario is that the gun owner safely uses his gun at a target range, maybe taking it once or twice a year for some real hunting, never hurting anything but deer and bales of hay.
Jesus, read what you wrote! Do you really believe that a gun is *more frequently* used dangerously than safely?
If you define the word "reference" to mean "exactly what Java's references do" and define "pointer" to mean "exactly what C's pointers do", you'd have a point. But that's not the language-independent definition of those terms. References predate Java, and pointers predate C.
As far as ensuring that a Java reference always refers to a valid object (or null), that's the business of the allocator. It's got nothing to do with the reference itself. You could design a free store allocator for your C runtime that does the exact same thing (so long as you don't use pointer arithmetic, of course). There's/nothing/ in the C standard that prevents this.
And as far as your example of the VM remapping memory, that meets the criteria for a pointer. Go read Knuth sometime. Really. Pointers have nothing to do with memory locations. (Nothing/precludes/ them for corresponding, but it's not necessary.)
If your class contains more than one pointer, it's not exception safe and therefor hasn't met the requirements for RAII. Any time you use a pointer, it should be wrapped in a class that controlls it (even if it's just an std::auto_ptr).
Part of RAII design means that you have to think about what to do when you copy your class. Not all classes are logically copyable; if so, just derive from boost::noncopyable and go on your merry way.
If you use the standard containers and boost (or other) smart pointers, there's really no excuse for naked pointers lying around in your code.
Not really. If there was a difference, why do "smart pointers" employ a "reference count"? Sometimes, the term "pointer" can imply an iterative functionality, but that is not strictly so (cf. "smart pointers").
It has nothing to do with whether they're managed or not. You can have managed pointers, even in C. Heck, you can even plug them into a full-blown garbage collector (or another type of allocator).
I was going to drop the first use of also, but I decided not to. Every object in Java is "dynamically allocated", so I left it in.
Again, you're confusing allocators with handles. Even the C++ free store allocator generally has that behavior. It's not uncommon that if you do
int *p = new int;
delete p;
p = new int;
then p will receive the same address it had before. Reuse of memory is, again, not a difference between C pointers and Java references.
Oh, and the designers at Sun must have misspelled "Reference" as "Pointer". Right. Because those keys are right next to each other. Oh, wait... they're not.
References in Java are pretty much the same thing as pointers in C except that you can't do arithmetic on them.
In C, pointers have three uses: dynamic memory allocation, aliasing, and array iterators. Java removed the last of those uses (which removed the need for pointer arithmetic), threw on some syntactic sugar (automatic dereference in most contexts) and called them "references" so people like you wouldn't be scared off by the big bad boogeyman.
Saying Java doesn't have pointers is disingenuous. It's like me saying I don't have a television because I watch TV using my TV tuner card.
Why would I/want/ GC? I use RAII. My code is exception-safe, let alone pointer-safe. GC only solves a subset of the problems that RAII solves, so why should I bother to use it at all?
Our disagreement centers around whether or not kernel modules can reasonably be considered independent works. In a legal context, I don't think they can, as they are useless without first being inserted into the kernel. nVidia's kernel module, by itself, does absolutely nothing. It simply extends the functionality of the kernel. As such, without Linus' clarifications/exceptions (whatever you choose to call them), I believe proprietary modules would be infringing.
No, you're mistaken. Distribution of the kernel has nothing to do with it: according to the vanilla GPL, if your program must be linked against a GPL program to achieve its functionality, then your program MUST be GPL. Without the kernel's exemption clause, nVidia drivers would need to be GPL.
Read the license that comes with the kernel. It is/not/ a vanilla GPL. If it were, proprietary kernel modules would be illegal.
I agree that those things are issues, but they have nothing to do with Linux (the kernel). This is a new release of/the kernel/. You should only get excited about it if you care what kernel you're running. Most people don't, and they shouldn't (as long as the kernel supports all their hardware).
Do they backport security fixes to stable code trees? Or do you have to install new (possibly unstable) versions of packages to fix newly-discovered vulnerabilities?
Slashdot Mirror
Power a computer with a self-contained nuclear rector. You have physical fuel, energy conversion, and resultant waste.
Next please.
What's your definition of metabolism? Receives energy, expends energy through performing work.
If you specify that the input and waste must be solids rather than energy, then we already have computers with a "water metabolism".
Thou shalt not make a machine in the likeness of a man's mind.
Yep, that'd do it.
1. Growth
I see no reason why an AI could not be self-modifying. Weather this refers to the physical housing or the codebase is up to the reader.
2. Metabolism - The uptake of food, conversion of food into energy and disposal of waste products
Check.
3. Motion - Moving itself or having internal motion
We've already got robots.
4. Reproduction - the ability to create more or less exact copies of itself
I see no reason why an AI could not be designed which could reproduce itself.
5. Stimulus response - the ability to measure properties of its surrounding environment and to act on certain conditions
Check.
As a footnote, that definition of "life" is somewhat limiting. According to those points, not all human beings are "alive".
No, you don't. You simply go into "power saver" mode.
Fifty years ago, the idea of cloning a human being was inconceivable.
Yes, that's fallacy number one. Java isn't necessarily slower (or faster). (Often, the VM is a bottleneck, but that's a QOI issue; it has nothing to do with the language per se.)
:-} (A rose, by any other name...)
Fallacy number two, of course, is that Java doesn't have pointers.
Scratch that... that's fallacy number three. Fallacy number two is that Java is platform-independent. (Hint: the JVM is a platform.)
Well, first of all, there are sometimes valid reasons for breaking speed limits (emergencies, etc). Second of all, not all roads are public. Thirdly, no one would pay lots of money for a new machine unless it went faster, etc. At least, the enthusiasts wouldn't, and we all know who drives the market.
We're talking about C++, not C. Try to keep up.
And the far, *far* more frequent scenario is that the gun owner safely uses his gun at a target range, maybe taking it once or twice a year for some real hunting, never hurting anything but deer and bales of hay.
Jesus, read what you wrote! Do you really believe that a gun is *more frequently* used dangerously than safely?
If you define the word "reference" to mean "exactly what Java's references do" and define "pointer" to mean "exactly what C's pointers do", you'd have a point. But that's not the language-independent definition of those terms. References predate Java, and pointers predate C.
/nothing/ in the C standard that prevents this.
/precludes/ them for corresponding, but it's not necessary.)
As far as ensuring that a Java reference always refers to a valid object (or null), that's the business of the allocator. It's got nothing to do with the reference itself. You could design a free store allocator for your C runtime that does the exact same thing (so long as you don't use pointer arithmetic, of course). There's
And as far as your example of the VM remapping memory, that meets the criteria for a pointer. Go read Knuth sometime. Really. Pointers have nothing to do with memory locations. (Nothing
If your class contains more than one pointer, it's not exception safe and therefor hasn't met the requirements for RAII. Any time you use a pointer, it should be wrapped in a class that controlls it (even if it's just an std::auto_ptr).
Part of RAII design means that you have to think about what to do when you copy your class. Not all classes are logically copyable; if so, just derive from boost::noncopyable and go on your merry way.
If you use the standard containers and boost (or other) smart pointers, there's really no excuse for naked pointers lying around in your code.
Not really. If there was a difference, why do "smart pointers" employ a "reference count"? Sometimes, the term "pointer" can imply an iterative functionality, but that is not strictly so (cf. "smart pointers").
It has nothing to do with whether they're managed or not. You can have managed pointers, even in C. Heck, you can even plug them into a full-blown garbage collector (or another type of allocator).
I was going to drop the first use of also, but I decided not to. Every object in Java is "dynamically allocated", so I left it in.
Again, you're confusing allocators with handles. Even the C++ free store allocator generally has that behavior. It's not uncommon that if you do
int *p = new int;
delete p;
p = new int;
then p will receive the same address it had before. Reuse of memory is, again, not a difference between C pointers and Java references.
Oh, and the designers at Sun must have misspelled "Reference" as "Pointer". Right. Because those keys are right next to each other. Oh, wait... they're not.
References in Java are pretty much the same thing as pointers in C except that you can't do arithmetic on them.
In C, pointers have three uses: dynamic memory allocation, aliasing, and array iterators. Java removed the last of those uses (which removed the need for pointer arithmetic), threw on some syntactic sugar (automatic dereference in most contexts) and called them "references" so people like you wouldn't be scared off by the big bad boogeyman.
Saying Java doesn't have pointers is disingenuous. It's like me saying I don't have a television because I watch TV using my TV tuner card.
In other news, the government should outlaw cars that can go faster than 65MPH. After all, it's the cars' fault that people speed.
Good point. Here's the solution:
... };
Foo tmparr[] = { foo1, foo2, foo3
std::vector foos(tmparr, tmparr + sizeof tmparr / sizeof *tmparr);
works every time, and it only requires one extra line of code.
Oh fercrissakes! Just don't use pointers in anything but library code!
It's not that hard.
Oh, and std::string. Really, people. *sheesh*
Why would I /want/ GC? I use RAII. My code is exception-safe, let alone pointer-safe. GC only solves a subset of the problems that RAII solves, so why should I bother to use it at all?
Java doesn't even have the concept of pointers, much less the ability to leave them dangling.
If you truly believe that, you really are a dumbass. Why do you think there's a NullPointerException in Java?
Our disagreement centers around whether or not kernel modules can reasonably be considered independent works. In a legal context, I don't think they can, as they are useless without first being inserted into the kernel. nVidia's kernel module, by itself, does absolutely nothing. It simply extends the functionality of the kernel. As such, without Linus' clarifications/exceptions (whatever you choose to call them), I believe proprietary modules would be infringing.
No, you're mistaken. Distribution of the kernel has nothing to do with it: according to the vanilla GPL, if your program must be linked against a GPL program to achieve its functionality, then your program MUST be GPL. Without the kernel's exemption clause, nVidia drivers would need to be GPL.
/not/ a vanilla GPL. If it were, proprietary kernel modules would be illegal.
Read the license that comes with the kernel. It is
Yes, but the kernel has an exception to the license, allowing people to link dynamically to the kernel without being bound by the GPL.
This is why nVidia's drivers are OK: they are linked dynamically. The problem is that Linksys' stuff is linked statically.
I agree that those things are issues, but they have nothing to do with Linux (the kernel). This is a new release of /the kernel/. You should only get excited about it if you care what kernel you're running. Most people don't, and they shouldn't (as long as the kernel supports all their hardware).
Works for me with a self-compiled Firebird 0.6.
Do they backport security fixes to stable code trees? Or do you have to install new (possibly unstable) versions of packages to fix newly-discovered vulnerabilities?