Restrict keyword is not related to threading. C/C++ compilers have always assumed that data is not accessed from several threads without synchronization. It just wasn't standardized until the new memory model in C11 and C++11. So if you don't use mutexes, memory barriers etc, the compiler is allowed to assume a single thread of execution.
What restrict does is it guarantees that two pointers do not point to same area in memory (aliasing). Let's say a function takes two pointers (char* a, char* b). If you write to the data pointed by a, then the compiler has to emit code to re-read data pointed by b, because a and b might refer to the same location. With restrict pointers the compiler doesn't have to do this.
C/C++ have also always had the concept of strict aliasing, which basically says that pointers with different types may not be used to access the same memory location (char pointers are exception). It allows the same optimizations as the restrict keyword. However most compilers don't enforce the rule because programmers are stupid and use all kinds of noncompliant hacks with pointers.
That is true. However, it is not really a problem in the long run unless every last bitcoin is lost. You can divide bitcoin in infinity and trade with micro-bitcoins or pico-botcoins instead. So at first though this seems like an issue but I argue it isn't.
You can't divide it infinitely. The smallest unit ("satoshi") is 10^-8 bitcoins, so in total, there will only be 2.1*10^15 units of money. For reference, the total M1 money supply in the world is equivalent to about $25 trillion, or 2.5*10^15 dollar cents. If bitcoin becomes a major world currency and we assume a currency loss rate of couple of percent per year, it's gonna become a problem within couple of decades.
There could of course be a change in the protocol so that let's say any bitcoins not used in 50 years could be remined. But it's something that requires acceptance from majority of miners.
It's not quite correct. a == b is not a use of the argument that has been invalidated.
a was a variable containing an address of the object that was passed by value to the realloc() function.
I also thought this first, but the standard seems to be quite picky about it. It is undefined behavior if "The value of a pointer that refers to space deallocated by a call to the free or realloc function is used". I interpret this so that just using the address value is UB, even if the pointed memory block is not accessed.
Under C99 all machines must be both 2s-compliment and have 8-bit bytes. IIRC both fall out from inttypes.h. Word is this wasn't intentional, but it had been so long since anyone actually used other architectures that no one noticed that implication.
You are incorrect. C99 (and C11) still explicitly allow two's complement, one's complement and sign-and-magnitude repsesentation for signed types. You are probably confusing it with the type definitions int8_t, int16_t etc. which ARE required to be two's complement (if they exist). But the standard does not require those type definitions to exist.
From TFA, it appears that they are supporting IPv6 in dual-stack mode. Most users without IPv6 connectivity should still be able to access their sites on June 8th.
Yeah, that's kind of obvious. Nobody's abandoning ipv4 anytime soon.
Well done for defeating your own point, smartass. AAC is superior, but people still want to use MP3. That's exactly what the GP was talking about.
And AAC isn't exactly a new codec either like you're implying, which even more emphasizes the fact that old codecs are still used even when better ones are available. There are better alternatives to AAC, and the only reason it's is still used is because alpha geeks like you can't "get their finger out their ass" and switch to modern codecs.
Of course you won't find perfect examples of that because we do have some regulation preventing that. But even with regulation, that's the direction we're going towards. Each year top 100 companies in the world make up a bigger and bigger part of the world economy. And the entry barriers in pretty much any business today is so high, that new competitors don't just magically appear out of nowhere.
Have they managed to improve the quality of the VP8 codec? Last time I saw a comparison, VP8 was way behind H.264.
And don't even give me that crap about "it's free, it doesn't have to be as good" or "it's only a web codec so who cares". If there's a number of big companies supporting the project and they plan on making WebM some kind of industry standard, anything less than state of the art is unacceptable. We'll be using this for years to come, so doing it right is in everyone's best interest.
If they previously didn't consider the rising of the crust, but now they are considering it, then my logic says that the estimates for melting rate should have increased. Ok, it says in TFA that in some places the ground is actually subsiding, but it seems weird that this would happen in more places than rising of the ground.
None of the DirectDraw games I've tried have worked correctly in VMWare (6.5). I know it's supposed to support DirectX, but in practice there are all sorts of graphical glitches and everything runs slow as hell.
I'm also willing to bet that people in hard sciences, like physics, chemistry etc are far more likely to be atheists than for example sociologists or historians.
Those 276 bytes are quite useless, because they cannot (at least to my knowledge) be used for correcting errors in other sectors. So, all you need is one sector that is totally unreadable, and the whole disc might become useless.
The only reason why I haven't subscribed to WoW is because I don't see it worth the money. So, what we need is more competition on prices, not just better MMORPGs.
CSS algorithm sucked badly, and it was broken by using brute force! One doesn't even have to find out the player keys to decrypt DVDs.
I'm not trying to defend DRM or anything. In fact, I believe I hate it more than most people. My point was just that even though the consumer has both the encrypted content and the encryption key, it doesn't mean it will always cause the system to fail. It will fail, but not because of that. Just like you said, people won't buy it.
Yes, this is how current implementations of DRM work. But what if decrypting is done at the hardware level? Let's say, the data is encrypted with a device specific public key, and the corresponding private key is implemented in the hardware. If someone wants to decrypt the data, it would require reverse engineering the hardware. It's possible in theory, but in practice it's too expensive.
You're talking about total greenhouse effect here, which doesn't mean anything. It is the change that matters. Even small changes in the greenhouse effect, like the one caused by CO2, have a significant effect on earth's average temperature. Water vapor can be ignored, because its concentration levels have remained almost constant.
Data is stored in base 2. It only makes sense that you report the maximum storage of a storage device in base 2.
Even if the actual storage space (in bytes) is not a power of 2, as it usually isn't? Ok, I understand it when talking about memory modules for example, because the size really is like 2^29 or 2^30 bytes etc. But I'm not sure if there even is a technical reason for this.
Slashdot Mirror
Restrict keyword is not related to threading. C/C++ compilers have always assumed that data is not accessed from several threads without synchronization. It just wasn't standardized until the new memory model in C11 and C++11. So if you don't use mutexes, memory barriers etc, the compiler is allowed to assume a single thread of execution.
What restrict does is it guarantees that two pointers do not point to same area in memory (aliasing). Let's say a function takes two pointers (char* a, char* b). If you write to the data pointed by a, then the compiler has to emit code to re-read data pointed by b, because a and b might refer to the same location. With restrict pointers the compiler doesn't have to do this.
C/C++ have also always had the concept of strict aliasing, which basically says that pointers with different types may not be used to access the same memory location (char pointers are exception). It allows the same optimizations as the restrict keyword. However most compilers don't enforce the rule because programmers are stupid and use all kinds of noncompliant hacks with pointers.
That is true. However, it is not really a problem in the long run unless every last bitcoin is lost. You can divide bitcoin in infinity and trade with micro-bitcoins or pico-botcoins instead. So at first though this seems like an issue but I argue it isn't.
You can't divide it infinitely. The smallest unit ("satoshi") is 10^-8 bitcoins, so in total, there will only be 2.1*10^15 units of money. For reference, the total M1 money supply in the world is equivalent to about $25 trillion, or 2.5*10^15 dollar cents. If bitcoin becomes a major world currency and we assume a currency loss rate of couple of percent per year, it's gonna become a problem within couple of decades.
There could of course be a change in the protocol so that let's say any bitcoins not used in 50 years could be remined. But it's something that requires acceptance from majority of miners.
It's not quite correct. a == b is not a use of the argument that has been invalidated. a was a variable containing an address of the object that was passed by value to the realloc() function.
I also thought this first, but the standard seems to be quite picky about it. It is undefined behavior if "The value of a pointer that refers to space deallocated by a call to the free or realloc function is used". I interpret this so that just using the address value is UB, even if the pointed memory block is not accessed.
Under C99 all machines must be both 2s-compliment and have 8-bit bytes. IIRC both fall out from inttypes.h. Word is this wasn't intentional, but it had been so long since anyone actually used other architectures that no one noticed that implication.
You are incorrect. C99 (and C11) still explicitly allow two's complement, one's complement and sign-and-magnitude repsesentation for signed types. You are probably confusing it with the type definitions int8_t, int16_t etc. which ARE required to be two's complement (if they exist). But the standard does not require those type definitions to exist.
From TFA, it appears that they are supporting IPv6 in dual-stack mode. Most users without IPv6 connectivity should still be able to access their sites on June 8th.
Yeah, that's kind of obvious. Nobody's abandoning ipv4 anytime soon.
Well done for defeating your own point, smartass. AAC is superior, but people still want to use MP3. That's exactly what the GP was talking about.
And AAC isn't exactly a new codec either like you're implying, which even more emphasizes the fact that old codecs are still used even when better ones are available. There are better alternatives to AAC, and the only reason it's is still used is because alpha geeks like you can't "get their finger out their ass" and switch to modern codecs.
c) a company buys all the competitors
Of course you won't find perfect examples of that because we do have some regulation preventing that. But even with regulation, that's the direction we're going towards. Each year top 100 companies in the world make up a bigger and bigger part of the world economy. And the entry barriers in pretty much any business today is so high, that new competitors don't just magically appear out of nowhere.
Have they managed to improve the quality of the VP8 codec? Last time I saw a comparison, VP8 was way behind H.264.
And don't even give me that crap about "it's free, it doesn't have to be as good" or "it's only a web codec so who cares". If there's a number of big companies supporting the project and they plan on making WebM some kind of industry standard, anything less than state of the art is unacceptable. We'll be using this for years to come, so doing it right is in everyone's best interest.
If they previously didn't consider the rising of the crust, but now they are considering it, then my logic says that the estimates for melting rate should have increased. Ok, it says in TFA that in some places the ground is actually subsiding, but it seems weird that this would happen in more places than rising of the ground.
None of the DirectDraw games I've tried have worked correctly in VMWare (6.5). I know it's supposed to support DirectX, but in practice there are all sorts of graphical glitches and everything runs slow as hell.
I'm also willing to bet that people in hard sciences, like physics, chemistry etc are far more likely to be atheists than for example sociologists or historians.
That doesn't sound right to me. Must be at least ten times that.
Those 276 bytes are quite useless, because they cannot (at least to my knowledge) be used for correcting errors in other sectors. So, all you need is one sector that is totally unreadable, and the whole disc might become useless.
The only reason why I haven't subscribed to WoW is because I don't see it worth the money. So, what we need is more competition on prices, not just better MMORPGs.
Is 8500 pages really that much?Duh, 8500 pages ought to be enough for anyone!
You have performed an illegal operation and will be terminated!
But sometimes I manage to get the box over the menu. Doesn't happen always, though. Firefox 1.5.0.5.
Sometimes the number of hidden or abbreviated comments gets negative. Like "-5 Hidden". What the hell does that mean?
CSS algorithm sucked badly, and it was broken by using brute force! One doesn't even have to find out the player keys to decrypt DVDs. I'm not trying to defend DRM or anything. In fact, I believe I hate it more than most people. My point was just that even though the consumer has both the encrypted content and the encryption key, it doesn't mean it will always cause the system to fail. It will fail, but not because of that. Just like you said, people won't buy it.
Yes, this is how current implementations of DRM work. But what if decrypting is done at the hardware level? Let's say, the data is encrypted with a device specific public key, and the corresponding private key is implemented in the hardware. If someone wants to decrypt the data, it would require reverse engineering the hardware. It's possible in theory, but in practice it's too expensive.
You're talking about total greenhouse effect here, which doesn't mean anything. It is the change that matters. Even small changes in the greenhouse effect, like the one caused by CO2, have a significant effect on earth's average temperature. Water vapor can be ignored, because its concentration levels have remained almost constant.