Never heared about rgba? Or about genetic manipulation?
His roses are solid red (with a very little green touch). Probably natural, but who knows. His violets are absolutely red, but almost transparent. For sure genetically manipulated.
On the other hand memory is there to be used, having loads of free memory on your system is just a waste, it may as well be used to cache something if there is no other demand on it.
Of course on modern operating systems, there's hardly any real "free" memory around. The reason is that the OS itself takes the same view, and uses the free memory for caching things, mostly files. So basically there's a tradeoff between a program using up memory for its own caching, or leaving that memory to the OS (and other programs) to use. Note that the OS can handle the memory much more intelligently, since it has complete knowledge of the system. For example, imagine you start a second program (say, acrobat reader to view some pdf from the web, or your favourite email program), the OS will immediatly free enough of it's caching in order to give that program the memory it needs. However, any memory the browser consumes won't be freed, because the OS can't know if it is needed just now. In the worst case, the system will be slowed down because several programs which all were written in a mindset of "all your memory belongs to us" separately use up unnecessary much memory in order to speed up their operations (which will be not too much, because if there's enough memory free, any "disk read" of recently written data would have come from the OS's memory cache anyway, while with too little memory, the "memory read" actually has to be swapped in, which can be slower because even the code to read the data may have been swapped out (i.e. in the worst case, you'll have the sequence "write some other stuff from memory to swap space to make room for the code; load the code page from swap; again write some other stuff from memory into swap to make room for the data to be accessed; load the data page from disk").
In short: Assuming you can just use all memory available was reasonable in DOS times (where there just weren't any other programs running besides yours), but generally isn't a good idea in multitasking operating systems (i.e. all current ones). And I've not even touched multi-user systems (imagine four users using firefox and each copy trying to use half of the available memory).
Of course, if you actually need the memory, then you should allocate it (for example, an image manipulation program can be expected to need the memory to hold the image (and probably a lot of other data about it) in memory. Also, there are certain types of programs where you just can expect that they will not run besides other huge memory-eating programs, or where the performance is so crucial that you can justify the extra memory anyway (and put the responsibility of making sure that no other program eats up the required memory to the user). But a browser isn't that type of program. Indeed, a browser is a program which quite often is left open besides your actual work, e.g. to be able to quickly look up things in the web if you need it (or to read slashdot:-)). Therefore it's the type of application which should affect the rest of the system as little as possible, which especially includes the memory used (imagine surfing while compiling a big program; you certainly don't want the system to swap because the compiler, rightfully, allocates lots of memory in order to optimize your code, while your browser, wrongly, eats up lots of memory just for a little bit of convenience through slightly faster reload of web pages by having them in RAM instead of disk).
C++ does not, because of a low-level language "feature": pointers, and specifically, pointer arithmetic.
Pointer arithmetic is irrelevant here, because it's undefined behaviour to move a pointer to outside the object through pointer arithmetic (exception: The one-past-end pointer, but that can be easily resolved by just allocating an extra byte at the end). Now pointers per se are relevant, because they are usually implemented as direct address of the object it points to. There is nothing in the C++ standard which forces this implementation, but I guess you would upset most low-level developers (e.g. OS or embedded) if you used another implementation. Now the implementation as direct address is problematic because there's no way the compiler could know what is a pointer and what isn't (you could have a normal integer which just happens to match the address of an allocated block; changing that integer on moving the block would of course be fatal).
However, a standard conforming pointer implementation could also consist of an index into an address table and an offset relative to that address (after all, the x86 protected mode segmented address is exactly that, just at processor level). Since now each access would go through that address table, moving blocks of memory around would be quite easy: You only would have to change that one entry (Ok, in multithreaded programs it would be more complicated because another thread could currently use the address; probably one would have to scan the stored register values of all threads for values matching the address range of the block to move, and don't move the block if it is found). The entries of the table would probably have to be GCed (without compacting, of course).
Of course that would slow down all memory use, even for programs where this wouldn't have a benefit, so it's unlikely to ever get implemented.
[Manual implementation through handle]
And if you don't mind the loss of performance due to using a handle allocator, why are you using C++ in the first place?
Not every part of a program needs the same performance. Indeed, in the high-level parts of your code it is often viewed as error to use raw pointers at all. Also note that if the handle is implemented the same way as the hypothetical pointer impementation above, but without the offset part (because in high-level code you usually won't use pointer arithmetics), and implement the index into the table just as normal pointer to the table entry, the overhead is just an extra indirection (basically you use **p instead of *p), which for high-level code isn't much of a performance hit. Of course the compaction pass itself costs performance, but you wouldn't do that if you wouldn't consider it worth that performance hit (after all, since you manually implement it, you have complete control over when this compaction pass is done). For freeing the table entries, you have the choice of using any memory management method you want, from explicitly freeing by function call through reference counting up to garbage collection. Of course for all objects managed this way, you should make sure that you can cheaply relocate them.
If this was proposed however, there would have been a lesser incentive to look for the more accurate theory that General Relativity provides.
AFAIK the main incentive for GR was not the motion of Mercury, but the fact that Newtonian Gravitation and Special Relativity just didn't fit together. A modified power law would not have changed that.
I think you confuse it with the cosmological constant (which today is linked to dark energy, which is something completely different than dark matter, except that we have even less of an idea what it actually is).
I agree with you that Dark Matter seems to be the 21st-century equivalent of searching for Vulcan, but trying to explain the observation without changing the theory of gravity was not necessarily a stupid thing to do, and it's a heck of a lot more straightforward than developing a new theory.
Note that the "Vulcan strategy" was already successful in the case of Neptune. So here we have one case where the additional-matter theory turned out right (Neptune), and another where it turned out wrong (Vulcan).
I've heared once that the original hebrew text reads "Thou shalt not murder." If that's true, the contradiction is easy to resolve: Just define that killing ordered by god is no murder.
You see here a robot. t What do you want to throw? [adfh or ?*] h In which direction? 6 The slime mold hits the robot. The slime mold takes control of the robot! The robot hits!
I think in this case I guess correctly when I assume you didn't really understand my post. Hint: I referred to what I quoted. Of course you just might have meant that you have a love/hate relationship to the 10 Euros:-)
You hear something from a friend, but you're skeptical, so you go look it up. You find ten other people that agree with what your friend said, but you're skeptical of them. Where does it end?
Solipsism?
But if you are truly sceptic, you of course must also doubt the rule that everything is to be doubted...
First, C++ / CLI is not compatible with C++. It's not even close. It's not a strict superset of C++, so old programs might behave differently under C++ / CLI, in much the same way that C programs can behave differently when compiled as C++.
I don't know much about C++/CLI, but this is different from what I've heared before (of course what I've heared before may be wrong). Could you please post a valid C++ program which would behave different under C++/CLI?
there are a couple of other languages derived from C++, like Embedded C++.
Embedded C++ is not an extended version of C++, but a crippled one. It was created basically by removing every feature from C++ which the inventors did not consider appropriate for embedded programming. They also use a modified library because the standard one cannot be implemented without those features.
AFAIU the GPL3 DRM clause is not about the code itself being DRMed (which I believe would already violate GPL2), but about the code being used to implement DRM.
Fork it if Linus doesn't like GPL3, and make sure all future contributions are GPL3-licensed. Linux-GPL2 can still use those patches, if it chooses.
You cannot put a fork of Linux under GPL3 because the Linux license doesn't have the "or, at your option, any later version" clause. Only the original developer can.
Also AFAIU you cannot mix GPL2-only code with GPL3 code, since the GPL3 DRM restriction violates the GPL2 "no further restrictions". For most GPL2ed software (notably for the FSF software) this is handled by the "upgrade-clause" above.
You could, of course, replace all GPL2 code from the Linux kernel with newly written GPL3 code. However, the result wouldn't be a fork, but basically a rewrite.
While this was commonly called "computed GOTO", only very few basic dialects allowed real computed GOTO. For example, on the ZX Spectrum, you could write e.g.:
GO TO 100*n
(note that the space in GO TO is no typo, but a ZX Spectrum speciality) Of course you were not restricted to simple multiplications, e.g. the following, while pointless, would have worked just as well:
Slashdot Mirror
In Korea, your module only creates old women.
Also: If you make money, you make love!
Or is it: When you make love, you make money?
But beware: When you make love, you make drugs, and making drugs is illegal!
Never heared about rgba? Or about genetic manipulation?
His roses are solid red (with a very little green touch). Probably natural, but who knows.
His violets are absolutely red, but almost transparent. For sure genetically manipulated.
Of course on modern operating systems, there's hardly any real "free" memory around. The reason is that the OS itself takes the same view, and uses the free memory for caching things, mostly files. So basically there's a tradeoff between a program using up memory for its own caching, or leaving that memory to the OS (and other programs) to use. Note that the OS can handle the memory much more intelligently, since it has complete knowledge of the system. For example, imagine you start a second program (say, acrobat reader to view some pdf from the web, or your favourite email program), the OS will immediatly free enough of it's caching in order to give that program the memory it needs. However, any memory the browser consumes won't be freed, because the OS can't know if it is needed just now. In the worst case, the system will be slowed down because several programs which all were written in a mindset of "all your memory belongs to us" separately use up unnecessary much memory in order to speed up their operations (which will be not too much, because if there's enough memory free, any "disk read" of recently written data would have come from the OS's memory cache anyway, while with too little memory, the "memory read" actually has to be swapped in, which can be slower because even the code to read the data may have been swapped out (i.e. in the worst case, you'll have the sequence "write some other stuff from memory to swap space to make room for the code; load the code page from swap; again write some other stuff from memory into swap to make room for the data to be accessed; load the data page from disk").
In short: Assuming you can just use all memory available was reasonable in DOS times (where there just weren't any other programs running besides yours), but generally isn't a good idea in multitasking operating systems (i.e. all current ones). And I've not even touched multi-user systems (imagine four users using firefox and each copy trying to use half of the available memory).
Of course, if you actually need the memory, then you should allocate it (for example, an image manipulation program can be expected to need the memory to hold the image (and probably a lot of other data about it) in memory. Also, there are certain types of programs where you just can expect that they will not run besides other huge memory-eating programs, or where the performance is so crucial that you can justify the extra memory anyway (and put the responsibility of making sure that no other program eats up the required memory to the user). But a browser isn't that type of program. Indeed, a browser is a program which quite often is left open besides your actual work, e.g. to be able to quickly look up things in the web if you need it (or to read slashdot
Pointer arithmetic is irrelevant here, because it's undefined behaviour to move a pointer to outside the object through pointer arithmetic (exception: The one-past-end pointer, but that can be easily resolved by just allocating an extra byte at the end).
Now pointers per se are relevant, because they are usually implemented as direct address of the object it points to. There is nothing in the C++ standard which forces this implementation, but I guess you would upset most low-level developers (e.g. OS or embedded) if you used another implementation. Now the implementation as direct address is problematic because there's no way the compiler could know what is a pointer and what isn't (you could have a normal integer which just happens to match the address of an allocated block; changing that integer on moving the block would of course be fatal).
However, a standard conforming pointer implementation could also consist of an index into an address table and an offset relative to that address (after all, the x86 protected mode segmented address is exactly that, just at processor level). Since now each access would go through that address table, moving blocks of memory around would be quite easy: You only would have to change that one entry (Ok, in multithreaded programs it would be more complicated because another thread could currently use the address; probably one would have to scan the stored register values of all threads for values matching the address range of the block to move, and don't move the block if it is found). The entries of the table would probably have to be GCed (without compacting, of course).
Of course that would slow down all memory use, even for programs where this wouldn't have a benefit, so it's unlikely to ever get implemented.
[Manual implementation through handle]
Not every part of a program needs the same performance. Indeed, in the high-level parts of your code it is often viewed as error to use raw pointers at all. Also note that if the handle is implemented the same way as the hypothetical pointer impementation above, but without the offset part (because in high-level code you usually won't use pointer arithmetics), and implement the index into the table just as normal pointer to the table entry, the overhead is just an extra indirection (basically you use **p instead of *p), which for high-level code isn't much of a performance hit. Of course the compaction pass itself costs performance, but you wouldn't do that if you wouldn't consider it worth that performance hit (after all, since you manually implement it, you have complete control over when this compaction pass is done). For freeing the table entries, you have the choice of using any memory management method you want, from explicitly freeing by function call through reference counting up to garbage collection. Of course for all objects managed this way, you should make sure that you can cheaply relocate them.
AFAIK the main incentive for GR was not the motion of Mercury, but the fact that Newtonian Gravitation and Special Relativity just didn't fit together. A modified power law would not have changed that.
With AJAX? Yes, I'm sure that will clean up the mess :-)
I think you confuse it with the cosmological constant (which today is linked to dark energy, which is something completely different than dark matter, except that we have even less of an idea what it actually is).
Note that the "Vulcan strategy" was already successful in the case of Neptune. So here we have one case where the additional-matter theory turned out right (Neptune), and another where it turned out wrong (Vulcan).
I've heared once that the original hebrew text reads "Thou shalt not murder." If that's true, the contradiction is easy to resolve: Just define that killing ordered by god is no murder.
In Korea, only old robots win.
You see here a robot. t
What do you want to throw? [adfh or ?*] h
In which direction? 6
The slime mold hits the robot.
The slime mold takes control of the robot!
The robot hits!
I only believe it when Netcraft confirms it. :-)
I think in this case I guess correctly when I assume you didn't really understand my post. Hint: I referred to what I quoted.
Of course you just might have meant that you have a love/hate relationship to the 10 Euros
Of course the problem is that people are usually not in doubt even when wrong. In which case your rule won't help.
I guess that one was not serious. Can I now have my 10 Euros please?
Well, compared to a maze, wall street is quite simple. I don't think a rat would have any problems investigating it.
Solipsism?
But if you are truly sceptic, you of course must also doubt the rule that everything is to be doubted
I don't know much about C++/CLI, but this is different from what I've heared before (of course what I've heared before may be wrong). Could you please post a valid C++ program which would behave different under C++/CLI?
Embedded C++ is not an extended version of C++, but a crippled one. It was created basically by removing every feature from C++ which the inventors did not consider appropriate for embedded programming. They also use a modified library because the standard one cannot be implemented without those features.
And that makes them different from the average western people
I'm sure if you offer them a few billion dollars for it, they will :-)
AFAIU the GPL3 DRM clause is not about the code itself being DRMed (which I believe would already violate GPL2), but about the code being used to implement DRM.
You cannot put a fork of Linux under GPL3 because the Linux license doesn't have the "or, at your option, any later version" clause. Only the original developer can.
Also AFAIU you cannot mix GPL2-only code with GPL3 code, since the GPL3 DRM restriction violates the GPL2 "no further restrictions". For most GPL2ed software (notably for the FSF software) this is handled by the "upgrade-clause" above.
You could, of course, replace all GPL2 code from the Linux kernel with newly written GPL3 code. However, the result wouldn't be a fork, but basically a rewrite.
Of course you were not restricted to simple multiplications, e.g. the following, while pointless, would have worked just as well:
(Actually quoted from http://sv-fortytwo.com/hhgttg42.html though)
And of course everyone knows what it is the ultimate question for (you can actually read it above). What know one knows is the question itself.
Ah, and did you look at the title of the Wikipedia page you just linked to?