I think they forgot a "not" on the GNU Pascal site. My old Turbo Pascal 6.0 manual says for "Inc" that the argument must be an ordinal type, which doesn't include pointers. Unfortunately I don't have a copy ready to run in order to try it.
Which implementation? Normally the STL should not need any threading constructs at all because it doesn't use shared data structures. Locking shared use of the same STL data structure is the user's job.
Turbo Pascal 3.0 had a different overlay mechanism which worked on a function basis (at that time, units didn't yet exist). It just compiled several functions to occupy the same address range, and loaded them in to that address when needed. However the Turbo Pascal executable didn't use that mechanism.
In my opinion, the Pascal syntax for pointers was less intuitive because the chaps who developed Pascal were not the sort of people who actually liked to have pointers in a HLL - or at least, who liked to use them there. Nikolaus Wirth was more interested in higher level concepts, but pointers had to be there for the language to be more of a plaything (remember LOGO?), so they were added. Without much love being lost on them in the process.
For DMR, on the other hand, pointers were part of a proper language ecosystem right from the get-go. It's no surprise that they feel more natural in C (the world's favourite macro assembler) than they do in Pascal...:-)
The Pascal syntax for pointers was much more intuitive.
First: It's a pointer. It points somewhere. What ASCII character looks most like something pointing to somewhere? Well, there are '' and '^'. '' were already taken for less than and more than, therefore '^' is the natural choice. Now C reused the star for it. Why the star? I have no idea. Other than by C/C++ training, I see no relation between the star and dereferencing. Note that, since there's no unary '^' operator in C, and C also uses a bniary '*' for multiplication, there's absolutely no reason why C couldn't have taken the more natural '^' here.
Next: I still don't understand why on earth C made dereferencing a prefix operator. It only complicates things. Think about why there's the -> operator in C, which is nothing but syntactic sugar for dereferece, then access member, i.e. p->m is exactly the same as (+).m (well, it came quite handy in C++, but at the time it was introduced to C nobody could have guessed that). All other accessors (member access, array access) are postfix. Therefore whenever pointer dereferences come into the mix, you need parentheses (and you need to know your preferences table by heart).
So in C, *foo.bar accesses the member bar of foo and then dereferences it. If you want to dereference foo and access the member bar of whatever it points to, you have to write (*foo).bar (or the syntactic sugar version, foo->bar). Compare this to Pascal: foo.bar^ vs foo^.bar -- there's absolutely no question what is dereferenced here, no parentheses and no precedence table needed to figure it out. The same is true for arrays: Does *a[10] dereference a, then take the tenth element? Or does it dereference the 10th element of a? In Pascal there's no question: a^[10] vs. a[10]^.
And don't get me started about C pointer declaration syntax.
The pointer syntax in Pascal was much more reasonable than that of C. C pointers are more flexible (with pointer arithmetics, void* etc.), but there's no way they are more intuitive.
However, pointer arithmetic was/is usually easier in C.
Pascal doesn't have pointer arithmetic. Even Turbo Pascal didn't have it. You could, of course, implement it yourself by taking the pointer apart (Seg, Ofs), doing arithmetic on the offset, and putting it back together (Ptr).
It was the same with me. I learned Turbo Pascal and knew about pointers, but only when I switched to C I realized that pointers are numbers, like indexes in an array.
In other words, you never learned pointers, you just learned the implementation of pointers on a flat memory model. I bet you wrote lots of code which broke (or would have broken) when strict aliasing as introduced.
The STL is exactly the wrong target here (and BTW, string is not part of the STL, its interface was "STLized" after the fact). The STL is completely made out of templates, and even if you include everything from it, the only thing which increases is the compile time (that one can massively increase, though). Only the parts you actually use get instantiated.
Having said that, using the STL on many different types can indeed increase your memory footprint because it generates new code for different types, in order to maximize speed. However, for most things few programmers write generic C code (with void pointers and functions to pass in) anyway, so for most things the code duplication would have been there anyway. It would just have been hand-duplicated (most likely copy&paste, maybe macros).
Note that a good STL implementation will factor out the type-independent parts so you get no "unnecessary" bloat. That is, it's not so much bloat, but optimizing speed over memory.
In short: If you speak about bloat, don't take the STL as example. Because the STL doesn't produce bloated code (assuming a reasonably good compiler, of course).
google.de has address 74.125.39.106 google.de has address 74.125.39.147 google.de has address 74.125.39.99 google.de has address 74.125.39.103 google.de has address 74.125.39.104 google.de has address 74.125.39.105 google.de mail is handled by 10 google.com.s9a1.psmtp.com. google.de mail is handled by 10 google.com.s9a2.psmtp.com. google.de mail is handled by 10 google.com.s9b1.psmtp.com. google.de mail is handled by 10 google.com.s9b2.psmtp.com.
Do those IP addresses look familiar? Well, OK, both are in Europe, so let's try google.com:
google.com has address 74.125.39.99 google.com has address 74.125.39.103 google.com has address 74.125.39.104 google.com has address 74.125.39.105 google.com has address 74.125.39.106 google.com has address 74.125.39.147 google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com. google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com.
And google.com.au:
google.com.au has address 74.125.39.147 google.com.au has address 74.125.39.99 google.com.au has address 74.125.39.103 google.com.au has address 74.125.39.104 google.com.au has address 74.125.39.105 google.com.au has address 74.125.39.106 google.com.au mail is handled by 10 google.com.s9a1.psmtp.com. google.com.au mail is handled by 10 google.com.s9a2.psmtp.com. google.com.au mail is handled by 10 google.com.s9b1.psmtp.com. google.com.au mail is handled by 10 google.com.s9b2.psmtp.com.
OK, so maybe it's just the local DNS (I don't know how one would get different DNS records from different countries, but then, I'm no DNS expert). Therefore let's try an online resolver: It gives me:
google.com. A 74.125.127.147
Ah, indeed, another address! I didn't know that was possible.
But then, my main point still remains: The TLD tells you exactly nothing about where the server is located. Note that all of.com,.com.sa,.de,.com.au ended up at the same servers for my local lookups.
Tab between multiple windows of same program with Alt-` (that's a backtick).
I assume that the backtick on US keyboard layout is on a place so that Alt-backtick is easy to type, right? But there are people in the world which do not use US keyboard layout.
There is actually *no* screen clutter *at all* when running a program fullscreen (which you are doing most of the time anyway).
No, I don't. Indeed, it's the exception rather than the rule. Almost always I have several programs on my screen, visible at the same time, and move seamlessly between them thanks to focus-follows-mouse.
Every time I log into Gmail, it passes thru google.com.sa for authentication i.e. my password and authentication info are stored on a server with a local address!
The TLD of course doesn't tell you where the server actually is. This is what this domain resolves to:
google.com.sa has address 74.125.39.103 google.com.sa has address 74.125.39.104 google.com.sa has address 74.125.39.105 google.com.sa has address 74.125.39.106 google.com.sa has address 74.125.39.147 google.com.sa has address 74.125.39.99 google.com.sa mail is handled by 10 google.com.s9b2.psmtp.com. google.com.sa mail is handled by 10 google.com.s9a1.psmtp.com. google.com.sa mail is handled by 10 google.com.s9a2.psmtp.com. google.com.sa mail is handled by 10 google.com.s9b1.psmtp.com.
The question is whether you consider the support necessary.
If you do so, try to convince the CIO about the necessity; and if you don't succeed, make sure that your dissenting opinion is recorded, so they cannot blame you when things go horribly wrong and support would indeed have been needed.
If you don't consider support necessary, just accept that the CIO is right.
It does attribute mass to rest energy. For example, while the single photon has no mass (and no rest energy), a photon gas does have mass. And it indeed adds to what you see on your scales for the containing box (although in reality you'll never be able to actually measure such a small contribution).
Yes, this also means that mass doesn't just add up.
But mass and rest energy are equal. And since the energy in the stored information is in the rest energy (it doesn't depend on the movement of the observer), it indeed adds to the mass. If you had a sufficiently precise scale, you could in principle even measure it.
Neither makes really intuitive sense. Both just tell you intuitively "extremely little". The only difference is that the "billionth of a billionth" says "extremely little" to a lot more peoppe than "1e-18" does. For me "1e-18" is the easier one, but then, on one hand I'm a scientist who is used to such, and on the other hand, I'm non-American, therefore "billionth of a billionth" for me includes an extra step of "scale correction" (i.e. recognizing that "billionth" means what I'd consider a "milliardth", and therefore "a billionth of a billionth" is far more than it initially sounds (a million times that, indeed). Indeed, with the long scale, this would be accurately described as just a "trillionth" which actually is much easier than both alternatives. Of course with the short scale, one could say a "quintillionth", but I guess few would understand that.
There is a theoretical limit on the amount of energy you need to erase a bit (in order to store new information in). It depends on the temperature, though. At room temperature it's about 2.8×10^(-21) joules, or the energy equivalent of 3.1×10^(-38) kilograms.
Only if you draw that energy you use to trap the electrons without permission. Then, while pirating, you are stealing from whoever supplies that energy. Of course that theft will remain even if you acquire a copyright license for the work.
So you say smoking does not cause cancer? In the usual definition of causality it does.
Say I plan to shoot three people, one each with one shot. But since I'm a terribly bad shooter, I miss two of them, In other words, if I aim a gun on someone and pull the trigger, there's only a one-in-three chance that the person I'm aiming at dies. According to your logic, me aiming at that person and pulling the trigger therefore is not the cause of that person dying because, after all, there was only a one-in-three chance that pulling the trigger resulted in that person's death.
I think you mix up the definition of causality with our means to inductively infer it from statistical data in cases where statistical data is all we got.
Slashdot Mirror
I think they forgot a "not" on the GNU Pascal site. My old Turbo Pascal 6.0 manual says for "Inc" that the argument must be an ordinal type, which doesn't include pointers. Unfortunately I don't have a copy ready to run in order to try it.
Which implementation? Normally the STL should not need any threading constructs at all because it doesn't use shared data structures. Locking shared use of the same STL data structure is the user's job.
Did you strip that executable? By default, all symbol names are included in the executable, and C++ symbols are generally quite large.
Turbo Pascal 3.0 had a different overlay mechanism which worked on a function basis (at that time, units didn't yet exist). It just compiled several functions to occupy the same address range, and loaded them in to that address when needed. However the Turbo Pascal executable didn't use that mechanism.
For me it was the reverse. After having coded in Pascal, C's syntax was a pain.
Oops, got tripped with HTML ... if there seems something missing, it's < and > signs (and a comma or "and" in between :-))
In my opinion, the Pascal syntax for pointers was less intuitive because the chaps who developed Pascal were not the sort of people who actually liked to have pointers in a HLL - or at least, who liked to use them there. Nikolaus Wirth was more interested in higher level concepts, but pointers had to be there for the language to be more of a plaything (remember LOGO?), so they were added. Without much love being lost on them in the process.
For DMR, on the other hand, pointers were part of a proper language ecosystem right from the get-go. It's no surprise that they feel more natural in C (the world's favourite macro assembler) than they do in Pascal... :-)
The Pascal syntax for pointers was much more intuitive.
First: It's a pointer. It points somewhere. What ASCII character looks most like something pointing to somewhere? Well, there are '' and '^'. '' were already taken for less than and more than, therefore '^' is the natural choice. Now C reused the star for it. Why the star? I have no idea. Other than by C/C++ training, I see no relation between the star and dereferencing. Note that, since there's no unary '^' operator in C, and C also uses a bniary '*' for multiplication, there's absolutely no reason why C couldn't have taken the more natural '^' here.
Next: I still don't understand why on earth C made dereferencing a prefix operator. It only complicates things. Think about why there's the -> operator in C, which is nothing but syntactic sugar for dereferece, then access member, i.e. p->m is exactly the same as (+).m (well, it came quite handy in C++, but at the time it was introduced to C nobody could have guessed that). All other accessors (member access, array access) are postfix. Therefore whenever pointer dereferences come into the mix, you need parentheses (and you need to know your preferences table by heart).
So in C, *foo.bar accesses the member bar of foo and then dereferences it. If you want to dereference foo and access the member bar of whatever it points to, you have to write (*foo).bar (or the syntactic sugar version, foo->bar). Compare this to Pascal: foo.bar^ vs foo^.bar -- there's absolutely no question what is dereferenced here, no parentheses and no precedence table needed to figure it out. The same is true for arrays: Does *a[10] dereference a, then take the tenth element? Or does it dereference the 10th element of a? In Pascal there's no question: a^[10] vs. a[10]^.
And don't get me started about C pointer declaration syntax.
The pointer syntax in Pascal was much more reasonable than that of C. C pointers are more flexible (with pointer arithmetics, void* etc.), but there's no way they are more intuitive.
Pascal doesn't have pointer arithmetic. Even Turbo Pascal didn't have it. You could, of course, implement it yourself by taking the pointer apart (Seg, Ofs), doing arithmetic on the offset, and putting it back together (Ptr).
In other words, you never learned pointers, you just learned the implementation of pointers on a flat memory model. I bet you wrote lots of code which broke (or would have broken) when strict aliasing as introduced.
The STL is exactly the wrong target here (and BTW, string is not part of the STL, its interface was "STLized" after the fact). The STL is completely made out of templates, and even if you include everything from it, the only thing which increases is the compile time (that one can massively increase, though). Only the parts you actually use get instantiated.
Having said that, using the STL on many different types can indeed increase your memory footprint because it generates new code for different types, in order to maximize speed. However, for most things few programmers write generic C code (with void pointers and functions to pass in) anyway, so for most things the code duplication would have been there anyway. It would just have been hand-duplicated (most likely copy&paste, maybe macros).
Note that a good STL implementation will factor out the type-independent parts so you get no "unnecessary" bloat. That is, it's not so much bloat, but optimizing speed over memory.
In short: If you speak about bloat, don't take the STL as example. Because the STL doesn't produce bloated code (assuming a reasonably good compiler, of course).
OK, I just checked out the IPs of google.de:
Do those IP addresses look familiar?
Well, OK, both are in Europe, so let's try google.com:
And google.com.au:
OK, so maybe it's just the local DNS (I don't know how one would get different DNS records from different countries, but then, I'm no DNS expert). Therefore let's try an online resolver:
It gives me:
Ah, indeed, another address! I didn't know that was possible.
But then, my main point still remains: The TLD tells you exactly nothing about where the server is located. Note that all of .com, .com.sa, .de, .com.au ended up at the same servers for my local lookups.
I assume that the backtick on US keyboard layout is on a place so that Alt-backtick is easy to type, right?
But there are people in the world which do not use US keyboard layout.
No, I don't. Indeed, it's the exception rather than the rule. Almost always I have several programs on my screen, visible at the same time, and move seamlessly between them thanks to focus-follows-mouse.
Every time I log into Gmail, it passes thru google.com.sa for authentication i.e. my password and authentication info are stored on a server with a local address!
The TLD of course doesn't tell you where the server actually is. This is what this domain resolves to:
Now looking up the first address reveals:
So much about that server with local address.
I haven't checked the others, but with the IPs so close to each other I'm pretty sure they are in the same data center.
The question is whether you consider the support necessary.
If you do so, try to convince the CIO about the necessity; and if you don't succeed, make sure that your dissenting opinion is recorded, so they cannot blame you when things go horribly wrong and support would indeed have been needed.
If you don't consider support necessary, just accept that the CIO is right.
It does attribute mass to rest energy. For example, while the single photon has no mass (and no rest energy), a photon gas does have mass. And it indeed adds to what you see on your scales for the containing box (although in reality you'll never be able to actually measure such a small contribution).
Yes, this also means that mass doesn't just add up.
But mass and rest energy are equal. And since the energy in the stored information is in the rest energy (it doesn't depend on the movement of the observer), it indeed adds to the mass. If you had a sufficiently precise scale, you could in principle even measure it.
Neither makes really intuitive sense. Both just tell you intuitively "extremely little". The only difference is that the "billionth of a billionth" says "extremely little" to a lot more peoppe than "1e-18" does. For me "1e-18" is the easier one, but then, on one hand I'm a scientist who is used to such, and on the other hand, I'm non-American, therefore "billionth of a billionth" for me includes an extra step of "scale correction" (i.e. recognizing that "billionth" means what I'd consider a "milliardth", and therefore "a billionth of a billionth" is far more than it initially sounds (a million times that, indeed). Indeed, with the long scale, this would be accurately described as just a "trillionth" which actually is much easier than both alternatives. Of course with the short scale, one could say a "quintillionth", but I guess few would understand that.
There is a theoretical limit on the amount of energy you need to erase a bit (in order to store new information in). It depends on the temperature, though. At room temperature it's about 2.8×10^(-21) joules, or the energy equivalent of 3.1×10^(-38) kilograms.
Only if you draw that energy you use to trap the electrons without permission. Then, while pirating, you are stealing from whoever supplies that energy. Of course that theft will remain even if you acquire a copyright license for the work.
So you say smoking does not cause cancer? In the usual definition of causality it does.
Say I plan to shoot three people, one each with one shot. But since I'm a terribly bad shooter, I miss two of them, In other words, if I aim a gun on someone and pull the trigger, there's only a one-in-three chance that the person I'm aiming at dies. According to your logic, me aiming at that person and pulling the trigger therefore is not the cause of that person dying because, after all, there was only a one-in-three chance that pulling the trigger resulted in that person's death.
I think you mix up the definition of causality with our means to inductively infer it from statistical data in cases where statistical data is all we got.
No, an intelligent fish designed its offspring to be resistant. :-)
wrong analogy. unless you mean to say that hiv causes aids even if you got 3 hiv's and only one of them developed into aids.
Of course I would say it. Cause and effect is not about statistics.
No, he died from a segmentation fault. Someone was saying some very long sentence to him, and he forgot to check the length of his input buffer.
AOL :-)