Say some cataclysm occurs that fries all microprocessors and scrambles the contents of all existing ROMs, disks, CD-ROMs, and any other machine-readable media in all computers.
The first thing I'd do is design a better surge supressor!
I don't think GC will be truly accepted in the hard-core, must-collect-manually community until it's predictable enough to be used in hard real-time applications.
We need to be able to say, "Automatic GC will not prevent us from guaranteeing allocation and deallocation times, and we will not fail if there's still N bytes available (that is, we can make solid predictions about fragmentation)"
Kids these days... Automatic register allocation isn't for real programmers!
Seriously, auto_ptr and template tricks are great, but you still need either careful management or an automatic collector to handle reference cycles. Reference counting misses those.
Admittedly, there are a lot of applications for which garbage collection in its current incarnations is inappropriate. However, there are even more applications for which it is. I also think it's quite likely that several years down the line we will look upon garbage collection the same way we look at register allocation now.
When C was first being developed, assembly programmers were very resistent to the compiler doing registry allocation. That's why the register keyword was put in the spec. How many people use it now? Not many, because the compiler (after a few iterations) did a really good job of register allocation.
Now that runtime systems (like Java) are being developed to do automatic garbage collection, C++ programmers are equally resistent. As runtime systems get better (and perhaps GC gets embedded in hardware, but that's a whole other debate), it's quite likely they will do a really good job.
I've developed a client as a school project. SSH isn't even in compliance with the RFCs.
It's just little things, like keys being sent
as SSH-strings instead of SSH-mpints, or headers being formatted slightly differently. It's a good thing you can peruse and play around with the source. Otherwise, figuring out the protocol would be damn near impossible!
Slashdot Mirror
Not so much worse than George Burns.
I got one that began with this little gem:
Interracialsex does not send unsolicited emails.
Funny, I don't recall soliciting...
Say some cataclysm occurs that fries all microprocessors and scrambles the contents of all existing ROMs, disks, CD-ROMs, and any other machine-readable media in all computers.
The first thing I'd do is design a better surge supressor!
I don't think GC will be truly accepted in the hard-core, must-collect-manually community until it's predictable enough to be used in hard real-time applications.
We need to be able to say, "Automatic GC will not prevent us from guaranteeing allocation and deallocation times, and we will not fail if there's still N bytes available (that is, we can make solid predictions about fragmentation)"
Not to worry, we're working on it :)
Kids these days... Automatic register allocation isn't for real programmers!
Seriously, auto_ptr and template tricks are great, but you still need either careful management or an automatic collector to handle reference cycles. Reference counting misses those.
Admittedly, there are a lot of applications for which garbage collection in its current incarnations is inappropriate. However, there are even more applications for which it is. I also think it's quite likely that several years down the line we will look upon garbage collection the same way we look at register allocation now.
When C was first being developed, assembly programmers were very resistent to the compiler doing registry allocation. That's why the register keyword was put in the spec. How many people use it now? Not many, because the compiler (after a few iterations) did a really good job of register allocation.
Now that runtime systems (like Java) are being developed to do automatic garbage collection, C++ programmers are equally resistent. As runtime systems get better (and perhaps GC gets embedded in hardware, but that's a whole other debate), it's quite likely they will do a really good job.
Can you do port forwarding in W2K (without 3rd party software)? If you can, I haven't been able to figure out how.
I've developed a client as a school project. SSH isn't even in compliance with the RFCs.
It's just little things, like keys being sent as SSH-strings instead of SSH-mpints, or headers being formatted slightly differently. It's a good thing you can peruse and play around with the source. Otherwise, figuring out the protocol would be damn near impossible!