Now matter how many addressed IPv6 supplies, we will run out eventually, and much sooner than we expect.
Based on my calculations, with the surface of the earth at 510 million square kilometers, and with IPv6 addresses at 128 bits (that is, about 256,000,000,000,000,000,000,000,000,000,000,000,00 0 addresses), there are about 300,000,000,000,000,000,000 addresses per square inch of the earth's surface. I don't think we need to worry about running out anytime soon. It's like realizing that eventually we'll have a Y10K bug, but none of our current hardware will be around for it.
I use both Gnome and KDE. Gnome strikes me as a more "UNIXy" kind of desktop environment, but KDE's strength could be that it feels more comfortable to people coming from Windows or Macintosh.
So... Gnome is for people who love Unix, and KDE is for people who hate Windows?
(Sorry. Couldn't resist.)
I can think of quite a few reasons why -- if I were Microsoft -- I wouldn't distribute GNU stuff with the OS:...
Good points, all of them. On the other hand, those weren't the reasons given in the article, so I'm guessing either someone really still doesn't get it, or someone oversimplified.
SFU is not shipped with Windows because SFU currently contains open-source software, such as the GNU C compiler, which cannot be distributed with commercial software.
Somebody still doesn't get it. Does Microsoft not realize they actually can distribute OSS software with commercial software as long as they're separate programs? Or are they just giving that excuse to the reporter because, for PR reasons, they don't want to be caught dead shipping the stuff?
Wow, I think this is a serious contender for hardest headline ever to parse.
WormRadar Node Volunteers Help Graph Attacks
Did a node spontaneously provide some "help graph" attacks? Did node volunteers assist in attacking a graph or several graphs? Did the help given by volunteers end up graphing an attack? Or did it perform a little known "graph attack" on something?
I think this is going to reduce these sites' hit rates, because people will stop browsing them during idle time at work when either they shouldn't be or they shouldn't be disturbing their neighbors. Sites with mandatory or default sound ought to have a good reason.
It would appear from this and the surrounding paragraphs that the Italian courts would take a less than favourable view of the enforcability of shrink-wrap/click-through agreements such as your average EULA.
Not necessarily. It isn't that hard to find a distinction between purchasing hardware (an actual physical device, where using it for the purchaser's intentions seems natural) and purchasing a license to use copyrighted materials (where the material is information only and usage of the materials is already subject to a lot of restrictions under copyright law).
Version 6 sucked A$$, but Vis c++.Net is actually pretty good. And wtf are you talking about, I've used templates before with.Net (2002 and 2003) and had no problem.
The areas where VC++ chokes on templates (both 6 and.net) are:
Partial template specialization (it doesn't do at all), and
Template member functions (it can't parse the syntax for defining the function body outside the class body, making the class definition really cluttered).
Those are the things I've commonly run into, and why I'm in the middle of switching to gcc. Someone else may know of other things, but I think these are the two big ones.
Of course, it also doesn't handle export, but almost no one does, and the standard is a bit foggy on it anyway.
The current version of C++ is often referred to as C++ 98 because it was finalized in 1998. The next standard should be finalized around 2007ish, so it's sometimes informally referred to as C++0x (think Windows 9x).
The original example of mapping -- onto ++ isn't very realistic. In real life, programmers will maintain the semantics of the operation in some at least semi-common-sensical way. If they didn't, they'd be fired, or shot, or something. A better example might be redefining assignment of references ("x=y", where x and y are references to an object) to mean constructing a new object instead ("x=y.copy()"). Then my code doesn't work because I modified y's fields in x, thinking they were the same thing when they weren't. If you make too much use of overloading operations, you end up always having to wonder whether things really mean what you think they mean.
Again, though, this applies just as well to functions as it does to operators. Changing the semantics of a defined function that is part of a class interface is plain-'n-simple a bad idea in working code.
And, yes, in Java, you always have reference semantics for assignment, so there's no worry that you might get value semantics when you were expecting reference semantics. I've always found this to be a weakness and one of the reasons I've stuck with C++ (despite all its flaws and caveats). In C++, you always have value semantics with assignment on the object level, so that never catches me by surprise. If your object represents a reference to another object, you better understand this about your object.
Anyway, never fear. If they do ever add operator overloading to Java (which I doubt), I don't believe they'll allow the redefinition of operators already defined by the language. But it goes both ways for me. The fact that I can recognize operators that are actually function calls in C++, doesn't seriously deter me from Java, knowing that I could just use function calls and it would still work, albeit more verbosely. The two things (among a fairly long list) that most keep me from Java are:
Deficiencies in the inheritance model. I've only used multiple inheritance a handful of times, but elsewhere knowing that I could use it if needed allowed my design decisions to be much simpler. And:
It is true that in C++ there are situations where you can overload an operator and alter the meaning the compiler would have generated without the code.
However, most of the time operator overloading is used (and I believe most of the time its advocates talk about using it) are situations where without the overload the code wouldn't compile at all. In C++, it's obvious that when you invoke the operator += on a "complex" or a "string" that an operator overload is being invoked, because the compiler itself doesn't provide that definition. At that point, to an experienced C++ programmer, it's not that much harder to recognize
string a; a+=b;
as a function call than it is to recognize
MyObject a=new MyObject(); a.incrementBy(b);
as a function call. If there were no overload, the thing wouldn't even compile.
Instead of adding new and experimental UI features, why not use a feature found on nearly every OS and that most end users will recognize - in this case, the lock symbol that indicates whether you're on a secure site or not. Obviously such a symbol would need to be something sufficiently different, but this is a well established (despite being lacking any standard specification) UI element that would require nearly no new training by the end user.
The point of this new UI element is that it needs to be difficult to spoof. If your machine is compromized in some way (via a trojan, perhaps) and an untrusted process attempts to masquerade as a trusted dialog, it can probably be convincing if the user interface element is the same on all or many machines. A lock icon would be easily spoofable. But if the appearance is visibly different on every machine and only applications with a certain type/level of trust can discover this appearance, then users can be more sure windows aren't masquerading.
A lot of things about the technology formerly known as Palladium scare me, but if it could be implemented in an open architecture where the machine owner has the keys, I think good things could happen.
What affects capacitance between the two? Well, the better the content is, the more people will want to show it to other people. The easier it is to show to other people, the more people will do so. P2P software today has cut the gap considerably. DRM is an attempt to add insulation and keep things from making the jump from casual copying to mass distribution.
I don't follow. If you can casual-copy it, generally speaking you can P2P-it. I don't see how someone capable of casually copying would be deterred by DRM from posting it on a network.
I've debated this workaround for a long time and it always scared me off. Aside from the minor fear stemming from the statement in the C++ standard saying that #define'ing keywords invokes undefined behavior, and the fear that this could cause different token sequences for class definitions in different translation units which also invokes undefined behavior, I've always been afraid that if this #define found its way above the inclusion of a standard header that it would break the template implementations in the header files, just like the compiler switch does.
It's also more difficult to port code that uses precompiled headers, since that is a Visual C++ extension. (I'm not saying that precompiled headers are bad, just nonportable.)
Microsoft Visual C++ has a few extensions to the language, mostly inherited from its extension to the C language, and nothing you can't get by without (unless you are looking at its "WinMain" function or other extensions designed specifically for programming under windows).
On the other hand, there are some problems with the language and libraries if you try to compile code ported from another compliant compiler.
for loops do not create a new scope (resulting in error messages if you reuse/redeclare for loop counters). I believe this is fixable with compiler flags in Visual Studio.NET. (Technically it's fixable with compiler flags in Visual C++ 6, but the header files won't compile if you try it.)
Visual C++ does not support Koenig lookup (good riddance IMHO, except the standard has it so I think Visual C++ should at least have a compiler option to use it). It is implemented for operator overloads, but not general functions.
Visual C++ doesn't support partial template specialization (which I've really missed from time to time when writing reusable templates).
Visual C++ can't parse the syntax for declaring a template member function and defining it outside the class body (not to be confused with a member function of a template). All such template member functions must be defined inline, causing some clutter in the class definition.
The auto_ptr implementation is missing a critical member function (causing me to use it with STLport to get proper functionality of pieces of the standard library). You may be able to solve this problem by purchasing the latest version of the Dinkumware libraries to use with Visual C++. (Dinkumware provided the version of the libraries that ship with VC6.)
I've probably missed stuff. This is just what I've generally run into.
Slashdot Mirror
I almost misread that as "Virtual Statemen Ready for Hollywood," which made me think "don't they have those in congress already?"
(Oh, and switching to Linux had something to do with it, too, in my case.)
WormRadar Node Volunteers Help Graph Attacks
Did a node spontaneously provide some "help graph" attacks? Did node volunteers assist in attacking a graph or several graphs? Did the help given by volunteers end up graphing an attack? Or did it perform a little known "graph attack" on something?
I think this is going to reduce these sites' hit rates, because people will stop browsing them during idle time at work when either they shouldn't be or they shouldn't be disturbing their neighbors. Sites with mandatory or default sound ought to have a good reason.
Wow! They have record players in their online games! I thought everybody switched to CDs a decade ago.
How about the sound of the CD in your PlayStation spinning up, a subtle hint that a new enemy fight might be loading?
- Partial template specialization (it doesn't do at all), and
- Template member functions (it can't parse the syntax for defining the function body outside the class body, making the class definition really cluttered).
Those are the things I've commonly run into, and why I'm in the middle of switching to gcc. Someone else may know of other things, but I think these are the two big ones.Of course, it also doesn't handle export, but almost no one does, and the standard is a bit foggy on it anyway.
The current version of C++ is often referred to as C++ 98 because it was finalized in 1998. The next standard should be finalized around 2007ish, so it's sometimes informally referred to as C++0x (think Windows 9x).
Well, "waiting" probably isn't the right word....
And, yes, in Java, you always have reference semantics for assignment, so there's no worry that you might get value semantics when you were expecting reference semantics. I've always found this to be a weakness and one of the reasons I've stuck with C++ (despite all its flaws and caveats). In C++, you always have value semantics with assignment on the object level, so that never catches me by surprise. If your object represents a reference to another object, you better understand this about your object.
Anyway, never fear. If they do ever add operator overloading to Java (which I doubt), I don't believe they'll allow the redefinition of operators already defined by the language. But it goes both ways for me. The fact that I can recognize operators that are actually function calls in C++, doesn't seriously deter me from Java, knowing that I could just use function calls and it would still work, albeit more verbosely. The two things (among a fairly long list) that most keep me from Java are:
However, most of the time operator overloading is used (and I believe most of the time its advocates talk about using it) are situations where without the overload the code wouldn't compile at all. In C++, it's obvious that when you invoke the operator += on a "complex" or a "string" that an operator overload is being invoked, because the compiler itself doesn't provide that definition. At that point, to an experienced C++ programmer, it's not that much harder to recognize
as a function call than it is to recognize as a function call. If there were no overload, the thing wouldn't even compile.A lot of things about the technology formerly known as Palladium scare me, but if it could be implemented in an open architecture where the machine owner has the keys, I think good things could happen.
Just my $0.02.
It's also more difficult to port code that uses precompiled headers, since that is a Visual C++ extension. (I'm not saying that precompiled headers are bad, just nonportable.)
On the other hand, there are some problems with the language and libraries if you try to compile code ported from another compliant compiler.
- for loops do not create a new scope (resulting in error messages if you reuse/redeclare for loop counters). I believe this is fixable with compiler flags in Visual Studio.NET. (Technically it's fixable with compiler flags in Visual C++ 6, but the header files won't compile if you try it.)
- Visual C++ does not support Koenig lookup (good riddance IMHO, except the standard has it so I think Visual C++ should at least have a compiler option to use it). It is implemented for operator overloads, but not general functions.
- Visual C++ doesn't support partial template specialization (which I've really missed from time to time when writing reusable templates).
- Visual C++ can't parse the syntax for declaring a template member function and defining it outside the class body (not to be confused with a member function of a template). All such template member functions must be defined inline, causing some clutter in the class definition.
- The auto_ptr implementation is missing a critical member function (causing me to use it with STLport to get proper functionality of pieces of the standard library). You may be able to solve this problem by purchasing the latest version of the Dinkumware libraries to use with Visual C++. (Dinkumware provided the version of the libraries that ship with VC6.)
I've probably missed stuff. This is just what I've generally run into.