Regarding your fourth citation: Java's generics aren't "reified". If you care about what the means, here's a short article on the subject. I'm not trying to say I think Java's generics are entirely inferior, or anything like that -- just that what you've cited isn't really exactly the same thing.
Likewise, your fifth citation regards dynamic classes. The other post was about dynamic methods. A dynamic class means you can create a new class at run time. A dynamic method means you can create a new method for an existing class at run time. While there's certainly similarity between the two, they're just as certainly not the same thing.
To give a really simplified (but hopefully not to the point that's it's actively misleading) explanation: for Java, think of a grid with classes along one axis, and interfaces along the other axis. A dynamic proxy class lets you put an 'X' at a more or less arbitrary box in that grid, setting up the connections so that class implements that interface. On the C# side, think of a class as having a row of boxes, one for each method in that class. A dynamic method allows you to add an entirely new box to the row, so it now has a method that didn't previously exist at all.
Unfortunately, if the method for that "box" is really completely new, you won't have other code that knows how to use it, and it won't necessarily accomplish a lot. One obvious use is about like in Java, to add methods that some existing code already knows how to use. OTOH, it certainly is possible to use it other ways. For one example, another program sends some previously unknown message, and you connect things up so that message ends up invoking your entirely new function. Taken to an extreme, you could define your "program" as little more than a tiny framework, for defining functions and connecting them to be invoked by messages (collecting appropriate data from dynamically generated forms).
Yes. Did you bother to read what I said? The "even if" part fairly explicitly states that I was not commenting on the "comparison" that's currently provided, but on the possibility that "even if" they did write a comparison with enough depth to be meaningful, that there was a hint of a possibility that such a comparison might be somewhat biased.
Such bias is hard to avoid even under the best of circumstances. Even an author who really tries to be objective still tends to have rather set attitudes about the familiar versus the unfamiliar. I don't use either regularly, and don't care for either one, but I'm still enough more familiar with Java that I'd probably have difficulty comparing the two entirely fairly. For somebody who knows Java far better and uses it a great deal more, a truly unbiased comparison becomes simply impossible.
In this case, the problem is compounded considerably though: even if (somehow) they managed to write a comparison that was both meaningful and unbiased, the people to whom it could be useful would have no way of verifying its lack of bias. The only people who could/would know such a thing would be those with sufficient knowledge of both languages and platforms that they no longer needed any such comparison.
I stand by my original comment: the cited comparison is completely meaningless, and even if it did mean something, nobody who needs it would know enough to be certain whether they could trust it.
Personally, I don't care one way or the other (I don't care for either one), but I'm left wondering: could anybody honestly consider the "comparison" on the cited site useful in any way, shape, form, or fashion? Even if it provided a comparison that was deep enough to have a hope of meaning something, do you think there's just a hint of a possibility that a web site hosted on "javacamp.org" might have (and provide) a slightly biased view in a comparison between Java and any perceived competitor?
But HP's and Dell's prices are either comparable (for the 73 GB SAS drive) or $200 to $250 higher (for the 1 TB SATA and 300 GB SAS drives).. . . To sum up, there are multiple good reasons why ADMs cost more than bare retail drives of the same size, it's possible but not recommended to replace the drive in one, and Apple is in no way charging an unusual premium for ADMs.
Parts of this may be true (it's impossible to say, since they don't specify exactly what they're comparing) -- but even if parts are true, it's misleading at best. In fact, some of it doesn't even seem to make sense. Let's look at real price lists from Apple and dell.
First we note that Dell doesn't seem to offer a 73 GB drive at all, so it's not entirely clear what they're comparing. The most likely possibility appears to be Apple's smallest option, a 73 GB SAS ADM ($300) to Dell's smallest, a 146 GB SAS ($349). While it's certainly true that the prices are comparable, it's also true that the Dell drive is twice as big.
For 300 GB SAS drives, the Apple site shows $650 while the Dell site shows $699. While Apple's price is lower, it's certainly not even close to $200 lower. To get a $200 price difference, it looks like they compared the full price of a 300 GB drive for the Dell to upgrade price for the Apple (i.e. the price difference for changing from the stock drive to the 300 GB drive).
For 1 TB hard drives, they have something of a point, but not a very good one. Apple's price for a 1 TB SATA drive is $450, while Dell's is $639. They fail to note, however, that Dell also lists a 1 TB SAS drive (an option not available for the XServe) for $679. Taking this into account, it looks a great deal as if Dell is simply doing their best to encourage their higher-end customers to use enterprise-class SAS drives by offering them at a purely nominal incremental cost over SATA drives.
The original article attempts to portray the situation as Apple offering prices that are at least as good as, and often better than the competition. In reality, there appears to be only one reasonable configuration where the Apple is likely to be competitive: the one using 300 GB SAS. At the low end, the Dell offers twice as big of a drive as the Apple for a purely nominal price difference. For lots of storage, the Apple offers only SATA drives where Dell offers SAS. If you're storing 1 TB of data (or more) the incremental cost of SAS is usually fully justified. There are undoubtedly exceptions, but they're not particularly common.
How is storing the length wasteful of memory? 99% of the time I'd guess as much space would be used in storing a null character as would be consumed storing the length of the string itself.
You're basically right: the vast majority of strings are short enough that a single byte could hold the length. The problem is that if you decide to use only a single byte to hold the length, the design limits ALL strings to 255 characters -- and unfortunately, even though most strings are short, a few are long. A good design should be optimized for the common case, but allow anything that's at all reasonable.
There are, however, alternatives to NUL-termination to allow that. One example would be to have the initial byte hold the length for strings up to size X, but also have a value (or two) that signal the the next N bytes hold the real length. For most strings, this would waste no space at all. It would waste a little space only for the few that are quite long.
Of course nothing is free -- the penalty in such a case would be extra complexity in the string handling code.
That one really does admit to a simple answer from real, current (pun intended) knowledge: you need larger wires to carry more current, but NOT to carry more voltage. If the 1.21 gigawatts is 1 amp at 1.21 gigavolts (for example) the wire wouldn't have any reason to be any larger than one carrying 1 amp at 110 volts, or 1 amp at 0.1 volts.
Of course, even though the wire itself can be the same size, it'll normally look a lot thicker, because 1.21 gigavolts requires pretty serious insulation.
This is based on a proven model that consists of lightweight processes that share no memory (therefore no deadlocks) and send/receive asynchronous immutable messages.
You can certainly have deadlocks without sharing memory. Just for example, if two processes need to open two files apiece, you can deadlock without sharing a single byte of memory -- in fact, the two processes can easily be on entirely separate machines and still deadlock.
No. IPC is dirt cheap. Take X11 for example -- that's perfectly usable using plain old named pipes, even without Xshm.
Something like "Dirt cheap" is nearly meaningless without (a lot of) context. In a typical situation, X11 might be working with 1920x1280x4 bytes of information that updates a maximum of 60 times per second.
Contrast that to a parallel quick sort that executes each recursive call as a separate task. Even on a single processor, the entire sort will almost certainly execute in less time that it takes to create a new process OR a named pipe. Every current form of IPC is unreasonably expensive, and likely to remain that way for a long time.
In fact, you have to be careful to even make threads useful for a situation like this -- even without inter-process overhead, it's easy for the communication overhead to swamp out the gain in processing.
People have been working on automatic parallelization for decades. For a few specific areas it works pretty darned well -- for example, Cray had a Fortran compiler that could automatically vectorize some loops well over 20 years ago. It didn't always recognize code that could be executed in parallel (on its own) but it did so often enough to be quite useful -- it provided a noticeable speedup for a fair number of CPU-intensive processes. Around the same time, a number of other vendors had large parallel processors of various other sorts as well, most of them with at least somewhat similar capabilities in their compilers.
These were effective enough to prove the concept and fuel a lot of research. In nearly any given year since, you can almost certainly find at least one researcher who's at least claimed to be on the verge of a breakthrough to generalizing the ability. At the same time, the number of compilers successfully converting typical single-threaded code to take advantage of multiple cores/processors remains essentially constant (i.e. zero).
It's an interesting problem with a lot of approaches that work for certain kinds of situations and look like they might generalize well. It's easy to get something that works well enough that you're sure you must be on the right track -- but so far, none has gone much beyond interesting experiments.
Worse, just threading isn't really enough for a lot of interesting scenarios. Threading more or less assumes something like small-scale symmetric multiprocessing. In particular, it lacks any real provision for things like rings of processors, where communication with one processor might have to go through another, so you might have strong preferences about how threads are scheduled onto processors. Most APIs do include some sort of control over affinity between threads and processors, but this is working at essentially the assembly language level, with little (or no) ability to specify something like: "I don't care which specific processors these two threads run on, but they should run on adjacent processors with fast communication, whereas those two threads communicate only rarely, so greater separation is more permissible."
On the hardware side, the situation is somewhat similar: multicore processors are still really pretty primitive. Despite lots of talk about a much larger number of cores and such, research has already shown that most of what's currently in use won't scale beyond a few hundred processor or so, except for situations where there's essentially no communication between them. Scaling to run a lot of web servers in parallel (for one example) is fairly straightforward. Getting really large matrices multiplied in a hurry by using a lot of processors isn't nearly so straightforward. In particular, coherency is currently maintained primarily by snooping each others memory transactions, with a lot of caching to keep from saturating the memory buses. That's heavily dependent on the caching to even get beyond a half dozen cores or so. For thousands of cores, much more radical architectures are needed.
For anybody who cares, the correct number is not 180 000 Gs of acceleration. It's really 180 000 meters per second squared, which gives about 18 000 Gs.
I've never seen a similar sized NiMH battery with less capacity than a NiCad.
They have more energy storage, but the peak current they can supply is lower (aka they have a higher internal impedance). For example, SR Batteries has an article on the situation.
The "UTC without leap second" proposal is a workaround, an ugly hack...
Clearly the moderators are clueless today, or this was just posted too late to get noticed. Somebody apparently in favor of leap seconds calling anything else (and I do mean anything, up to and including MS-DOS) an ugly hack deserves a "funny" moderation more than if Robin Williams started posting.
But now everybody has it and is used to it, by bother changing it ? It cost much more than just keeping counting leap second has we do : if we remove leap seconds for UTC, some systems that rely on UTC to be on par with solar time will break.
The why is simple: because some systems use UTC as input, but attempt to use it to measure time intervals rather than just what the current time is. Any such attempt is almost guaranteed to be broken, and nearly impossible to fix. Admittedly, many are also broken by daylight savings time changes, but those at least could be fixed. Dealing with leap seconds is substantially more difficult.
As such, there's a real question: how many systems need the current time to sub-second precision, vs. how many need intervals to sub-second precision. A third possibility is systems that just need a coordinated time, and don't care all that much about whether it's consistent with anything else.
The answer, for the most part, is that nearly everything and everybody who cares about sub-second precision cares far more about time intervals than they do about that time being consistent with solar time. In fact, nearly everything and everybody who needs something related to solar time has to apply (often substantial) corrections to their time anyway -- time zones are an hour wide, so there's only a narrow strip (theoretically 1/3600th the width of the time zone, but time zone boundaries are often adjusted to fit political boundaries -- in which UTC corresponds to solar time without adjustment. In fact, the most obvious way to get your longitude to the necessary accuracy is from GPS, derived from a clock without leap seconds.
Systems that need solar time:
are mostly fairly sophisticated
already need adjustments
are relatively few
Leap seconds make life substantially more difficult for many while making it only marginally simpler for a few. That's not a good compromise.
I use XP for doing graphic stuff, such as PhotoShop and Rhino3D, and for a few games, such as ThiefII, yet it seems that Windows NTFS is woefully inferior as far as data security and fragmentation issues. NTFS has no journaling.
That's not entirely true. NTFS doesn't use journaling for the contents of files, but it does use journaling for metadata. You can even access the log file to a limited degree -- enough to see what files have changed, and an enumeration of the type of change (e.g. data overwritten vs. creation of a new file). A backup program (for one example) can directly access the journal records to find what files need to be backed up without scanning through them all to find changes. If this is more than a generic attack on Microsoft, and you honestly care about NTFS journaling, you might want to read an MSDN article about some of the details.
I'm disappointed that so few are sufficiently well read to know that Titan has statues of three Sirens, and is occupied by a robot carrying a message containing a single dot (meaning "Hi" in its language). Essentially the entire history of earth has been a consequence of its attempts to send a message back home to get its space ship repaired after crashing on Titan. Actual life, however, would be restricted primarily to Winston Niles, after he passed over into the chrono-synclastic infundibulum (sp?).
I have no ego wrapped up in any such thing -- and I notice that even though you claim you could easily name a half dozen, you've yet to name even one.
The fact is, given the complete lack of information you have available right now, suggestion you might make would do nothing more than open you to public ridicule.
And here I thought that the goal was to sell more computers...
Not necessarily. The goal is generally to make more money, not just to ship more units. Apple has a small market share, but a much higher profit margin than almost anybody else in the PC business.
The information was derived fairly directly from SEC financial statements. Apple's shows outlays to a few advertising agencies, one of which openly stated that essentially all they did was product placements. If you want to feel like I'm "full of shit", feel free though -- I'll openly admit I don't remember the names, nor do I have the ambition to spend a week or so tracking down all the relevant data about something over which I really don't much care.
In case you're wondering why I spent the time on something I didn't care about, I didn't -- at the time, I was tracking down some information on which PC makers bought parts from what suppliers. On financial statements, however, it doesn't really tell you what they bought from a company, only how much money they spent there, and you have to check with that company to figure out what they sell...
Just an FYI, mac users are pretty similar to PC users. Most of us just don't care.
They should care -- they pay for that. Macs don't show up by accident -- they show up because Apple pays for them to show up. When you buy a Mac, part of what you pay goes for Apple to buy product placements.
Just FWIW, the last time I checked Apple had the largest product placement budget of any computer maker I could find. At least at that time, HP had something like 10 times the computer sales, but less than one third the product placement budget.
Personally, I think this is true genius on the part of Apple. I'm convinced that product placements probably have a better payoff than almost any other sort of advertising. I think that's particularly true when/if a large part of what you're selling is a style or image.
1) It is impossible to make a string class that behaves "normally"
Plenty of people have tried. QT, Boost, STL, Gnome, WxWidgets, all have their own string classes. Years ago, when VB developers touted how easy it was to use strings compared to C++, I told them it was merely because nobody had made a good string class. After 10 years of trying to write one, and using dozens of other ones people created, I realized that C++ is simply too weak and too loosely typed to do this.
The problem isn't that it can't be done. If you really knew C++ as well as you claim, you'd realize that it's pretty easy (bordering in trivial) to write a string class that does precisely what you ask. The reason most don't work that way is because after people try it, they find that it's not what they really want -- in particular, allowing assignment of an int (to use your example) to a string tends to cause problems. If you're writing a 10-line throwaway script, allowing assignment of an int to a string probably won't cause a problem, but for big, industrial-strength projects it's a whole different story.
It's odd that you blame this on "loosely typed" -- loose typing is exactly what allows this to work, and C++ prevents it by having stronger typing than the languages to which you're apparently accustomed.
Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++// C#
Properties, at least as supported by these languages are simply a lousy idea. Supporting or using them is an equally bad idea.
A property is only "useful" when you've really used the wrong type. IOW, you have (for example) an int (by whatever name that language happens to use) private to your class, but you really want that int to be restricted to a specific range, or log every time it's read/written.
In other words, what you want is something that works like an int in some ways, but not others. C++ already provides a way to define such a type directly though (and so should any other OO language) -- that's what classes are for. When, for example, you want an int that's restricted to a specific range, you write a class (or template) for that purpose -- and it supports assignment to and from ints by overloading operator int and operator= respectively. Of course, these can also be inlined, just like any other function in C++.
C++ does have shortcomings -- but your understanding of it appears to be sufficiently limited that you don't know them yet.
Write the control flow in a high-level, easy-to-debug language, and later optimize the pieces running unacceptably slow by rewriting them in C.
If you need to rewrite something for speed, advocating C over C++ makes no sense -- for any given piece of C code, there is equivalent C++ that is just as fast, and with only a few minor exceptions (no pun intended) the exact same code will compile as either one and with an average compiler will run the same speed either way. On the rare occasion that you need to change the code at all (e.g. you've used 'class' as an identifier) the change is purely syntactic, and still has no effect on speed.
In the other direction, it's often fairly easy to produce code in C++ that's substantially faster than any reasonable equivalent in C. An obvious case in point is std::sort compared to C's qsort. For many cases, especially primitive types like int, std::sort will typically be three to five times as fast as qsort when operating on exactly the same data.
Most of these could theoretically be handled in C by a combination of writing specialized code everywhere needed and (perhaps) some unbelievably gross macros. I've been programming just about as long as anybody (going back as far as writing FORTRAN 66 on Control Data mainframes) and based on my experience, I'd say 1) this doesn't happen often enough to matter, and 2) thank God for that.
Slashdot Mirror
Likewise, your fifth citation regards dynamic classes. The other post was about dynamic methods. A dynamic class means you can create a new class at run time. A dynamic method means you can create a new method for an existing class at run time. While there's certainly similarity between the two, they're just as certainly not the same thing.
To give a really simplified (but hopefully not to the point that's it's actively misleading) explanation: for Java, think of a grid with classes along one axis, and interfaces along the other axis. A dynamic proxy class lets you put an 'X' at a more or less arbitrary box in that grid, setting up the connections so that class implements that interface. On the C# side, think of a class as having a row of boxes, one for each method in that class. A dynamic method allows you to add an entirely new box to the row, so it now has a method that didn't previously exist at all.
Unfortunately, if the method for that "box" is really completely new, you won't have other code that knows how to use it, and it won't necessarily accomplish a lot. One obvious use is about like in Java, to add methods that some existing code already knows how to use. OTOH, it certainly is possible to use it other ways. For one example, another program sends some previously unknown message, and you connect things up so that message ends up invoking your entirely new function. Taken to an extreme, you could define your "program" as little more than a tiny framework, for defining functions and connecting them to be invoked by messages (collecting appropriate data from dynamically generated forms).
Such bias is hard to avoid even under the best of circumstances. Even an author who really tries to be objective still tends to have rather set attitudes about the familiar versus the unfamiliar. I don't use either regularly, and don't care for either one, but I'm still enough more familiar with Java that I'd probably have difficulty comparing the two entirely fairly. For somebody who knows Java far better and uses it a great deal more, a truly unbiased comparison becomes simply impossible.
In this case, the problem is compounded considerably though: even if (somehow) they managed to write a comparison that was both meaningful and unbiased, the people to whom it could be useful would have no way of verifying its lack of bias. The only people who could/would know such a thing would be those with sufficient knowledge of both languages and platforms that they no longer needed any such comparison.
I stand by my original comment: the cited comparison is completely meaningless, and even if it did mean something, nobody who needs it would know enough to be certain whether they could trust it.
Personally, I don't care one way or the other (I don't care for either one), but I'm left wondering: could anybody honestly consider the "comparison" on the cited site useful in any way, shape, form, or fashion? Even if it provided a comparison that was deep enough to have a hope of meaning something, do you think there's just a hint of a possibility that a web site hosted on "javacamp.org" might have (and provide) a slightly biased view in a comparison between Java and any perceived competitor?
Project: 64 Channel logic analyzer.
Your Language: C
My Language: VHDL
Good luck!
Parts of this may be true (it's impossible to say, since they don't specify exactly what they're comparing) -- but even if parts are true, it's misleading at best. In fact, some of it doesn't even seem to make sense. Let's look at real price lists from Apple and dell.
First we note that Dell doesn't seem to offer a 73 GB drive at all, so it's not entirely clear what they're comparing. The most likely possibility appears to be Apple's smallest option, a 73 GB SAS ADM ($300) to Dell's smallest, a 146 GB SAS ($349). While it's certainly true that the prices are comparable, it's also true that the Dell drive is twice as big.
For 300 GB SAS drives, the Apple site shows $650 while the Dell site shows $699. While Apple's price is lower, it's certainly not even close to $200 lower. To get a $200 price difference, it looks like they compared the full price of a 300 GB drive for the Dell to upgrade price for the Apple (i.e. the price difference for changing from the stock drive to the 300 GB drive).
For 1 TB hard drives, they have something of a point, but not a very good one. Apple's price for a 1 TB SATA drive is $450, while Dell's is $639. They fail to note, however, that Dell also lists a 1 TB SAS drive (an option not available for the XServe) for $679. Taking this into account, it looks a great deal as if Dell is simply doing their best to encourage their higher-end customers to use enterprise-class SAS drives by offering them at a purely nominal incremental cost over SATA drives.
The original article attempts to portray the situation as Apple offering prices that are at least as good as, and often better than the competition. In reality, there appears to be only one reasonable configuration where the Apple is likely to be competitive: the one using 300 GB SAS. At the low end, the Dell offers twice as big of a drive as the Apple for a purely nominal price difference. For lots of storage, the Apple offers only SATA drives where Dell offers SAS. If you're storing 1 TB of data (or more) the incremental cost of SAS is usually fully justified. There are undoubtedly exceptions, but they're not particularly common.
You're basically right: the vast majority of strings are short enough that a single byte could hold the length. The problem is that if you decide to use only a single byte to hold the length, the design limits ALL strings to 255 characters -- and unfortunately, even though most strings are short, a few are long. A good design should be optimized for the common case, but allow anything that's at all reasonable.
There are, however, alternatives to NUL-termination to allow that. One example would be to have the initial byte hold the length for strings up to size X, but also have a value (or two) that signal the the next N bytes hold the real length. For most strings, this would waste no space at all. It would waste a little space only for the few that are quite long.
Of course nothing is free -- the penalty in such a case would be extra complexity in the string handling code.
This was to satisfy Bill G's desire to "factor large prime numbers."
Of course, even though the wire itself can be the same size, it'll normally look a lot thicker, because 1.21 gigavolts requires pretty serious insulation.
You can certainly have deadlocks without sharing memory. Just for example, if two processes need to open two files apiece, you can deadlock without sharing a single byte of memory -- in fact, the two processes can easily be on entirely separate machines and still deadlock.
Something like "Dirt cheap" is nearly meaningless without (a lot of) context. In a typical situation, X11 might be working with 1920x1280x4 bytes of information that updates a maximum of 60 times per second.
Contrast that to a parallel quick sort that executes each recursive call as a separate task. Even on a single processor, the entire sort will almost certainly execute in less time that it takes to create a new process OR a named pipe. Every current form of IPC is unreasonably expensive, and likely to remain that way for a long time.
In fact, you have to be careful to even make threads useful for a situation like this -- even without inter-process overhead, it's easy for the communication overhead to swamp out the gain in processing.
These were effective enough to prove the concept and fuel a lot of research. In nearly any given year since, you can almost certainly find at least one researcher who's at least claimed to be on the verge of a breakthrough to generalizing the ability. At the same time, the number of compilers successfully converting typical single-threaded code to take advantage of multiple cores/processors remains essentially constant (i.e. zero).
It's an interesting problem with a lot of approaches that work for certain kinds of situations and look like they might generalize well. It's easy to get something that works well enough that you're sure you must be on the right track -- but so far, none has gone much beyond interesting experiments.
Worse, just threading isn't really enough for a lot of interesting scenarios. Threading more or less assumes something like small-scale symmetric multiprocessing. In particular, it lacks any real provision for things like rings of processors, where communication with one processor might have to go through another, so you might have strong preferences about how threads are scheduled onto processors. Most APIs do include some sort of control over affinity between threads and processors, but this is working at essentially the assembly language level, with little (or no) ability to specify something like: "I don't care which specific processors these two threads run on, but they should run on adjacent processors with fast communication, whereas those two threads communicate only rarely, so greater separation is more permissible."
On the hardware side, the situation is somewhat similar: multicore processors are still really pretty primitive. Despite lots of talk about a much larger number of cores and such, research has already shown that most of what's currently in use won't scale beyond a few hundred processor or so, except for situations where there's essentially no communication between them. Scaling to run a lot of web servers in parallel (for one example) is fairly straightforward. Getting really large matrices multiplied in a hurry by using a lot of processors isn't nearly so straightforward. In particular, coherency is currently maintained primarily by snooping each others memory transactions, with a lot of caching to keep from saturating the memory buses. That's heavily dependent on the caching to even get beyond a half dozen cores or so. For thousands of cores, much more radical architectures are needed.
For anybody who cares, the correct number is not 180 000 Gs of acceleration. It's really 180 000 meters per second squared, which gives about 18 000 Gs.
They have more energy storage, but the peak current they can supply is lower (aka they have a higher internal impedance). For example, SR Batteries has an article on the situation.
Clearly the moderators are clueless today, or this was just posted too late to get noticed. Somebody apparently in favor of leap seconds calling anything else (and I do mean anything, up to and including MS-DOS) an ugly hack deserves a "funny" moderation more than if Robin Williams started posting.
The why is simple: because some systems use UTC as input, but attempt to use it to measure time intervals rather than just what the current time is. Any such attempt is almost guaranteed to be broken, and nearly impossible to fix. Admittedly, many are also broken by daylight savings time changes, but those at least could be fixed. Dealing with leap seconds is substantially more difficult.
As such, there's a real question: how many systems need the current time to sub-second precision, vs. how many need intervals to sub-second precision. A third possibility is systems that just need a coordinated time, and don't care all that much about whether it's consistent with anything else.
The answer, for the most part, is that nearly everything and everybody who cares about sub-second precision cares far more about time intervals than they do about that time being consistent with solar time. In fact, nearly everything and everybody who needs something related to solar time has to apply (often substantial) corrections to their time anyway -- time zones are an hour wide, so there's only a narrow strip (theoretically 1/3600th the width of the time zone, but time zone boundaries are often adjusted to fit political boundaries -- in which UTC corresponds to solar time without adjustment. In fact, the most obvious way to get your longitude to the necessary accuracy is from GPS, derived from a clock without leap seconds.
Systems that need solar time:
are relatively few
Leap seconds make life substantially more difficult for many while making it only marginally simpler for a few. That's not a good compromise.
That's not entirely true. NTFS doesn't use journaling for the contents of files, but it does use journaling for metadata. You can even access the log file to a limited degree -- enough to see what files have changed, and an enumeration of the type of change (e.g. data overwritten vs. creation of a new file). A backup program (for one example) can directly access the journal records to find what files need to be backed up without scanning through them all to find changes. If this is more than a generic attack on Microsoft, and you honestly care about NTFS journaling, you might want to read an MSDN article about some of the details.
I'm disappointed that so few are sufficiently well read to know that Titan has statues of three Sirens, and is occupied by a robot carrying a message containing a single dot (meaning "Hi" in its language). Essentially the entire history of earth has been a consequence of its attempts to send a message back home to get its space ship repaired after crashing on Titan. Actual life, however, would be restricted primarily to Winston Niles, after he passed over into the chrono-synclastic infundibulum (sp?).
The fact is, given the complete lack of information you have available right now, suggestion you might make would do nothing more than open you to public ridicule.
Not necessarily. The goal is generally to make more money, not just to ship more units. Apple has a small market share, but a much higher profit margin than almost anybody else in the PC business.
In case you're wondering why I spent the time on something I didn't care about, I didn't -- at the time, I was tracking down some information on which PC makers bought parts from what suppliers. On financial statements, however, it doesn't really tell you what they bought from a company, only how much money they spent there, and you have to check with that company to figure out what they sell...
They should care -- they pay for that. Macs don't show up by accident -- they show up because Apple pays for them to show up. When you buy a Mac, part of what you pay goes for Apple to buy product placements.
Just FWIW, the last time I checked Apple had the largest product placement budget of any computer maker I could find. At least at that time, HP had something like 10 times the computer sales, but less than one third the product placement budget.
Personally, I think this is true genius on the part of Apple. I'm convinced that product placements probably have a better payoff than almost any other sort of advertising. I think that's particularly true when/if a large part of what you're selling is a style or image.
You claim you can without even knowing the application? Maybe you should think more.
The problem isn't that it can't be done. If you really knew C++ as well as you claim, you'd realize that it's pretty easy (bordering in trivial) to write a string class that does precisely what you ask. The reason most don't work that way is because after people try it, they find that it's not what they really want -- in particular, allowing assignment of an int (to use your example) to a string tends to cause problems. If you're writing a 10-line throwaway script, allowing assignment of an int to a string probably won't cause a problem, but for big, industrial-strength projects it's a whole different story.
It's odd that you blame this on "loosely typed" -- loose typing is exactly what allows this to work, and C++ prevents it by having stronger typing than the languages to which you're apparently accustomed.
Properties, at least as supported by these languages are simply a lousy idea. Supporting or using them is an equally bad idea.
A property is only "useful" when you've really used the wrong type. IOW, you have (for example) an int (by whatever name that language happens to use) private to your class, but you really want that int to be restricted to a specific range, or log every time it's read/written.
In other words, what you want is something that works like an int in some ways, but not others. C++ already provides a way to define such a type directly though (and so should any other OO language) -- that's what classes are for. When, for example, you want an int that's restricted to a specific range, you write a class (or template) for that purpose -- and it supports assignment to and from ints by overloading operator int and operator= respectively. Of course, these can also be inlined, just like any other function in C++.
C++ does have shortcomings -- but your understanding of it appears to be sufficiently limited that you don't know them yet.
I don't know. Someday, when there IS a better language, maybe we'll find out.
Don't get me wrong: IMO, C++ sucks. But the alternatives suck even more!
If you need to rewrite something for speed, advocating C over C++ makes no sense -- for any given piece of C code, there is equivalent C++ that is just as fast, and with only a few minor exceptions (no pun intended) the exact same code will compile as either one and with an average compiler will run the same speed either way. On the rare occasion that you need to change the code at all (e.g. you've used 'class' as an identifier) the change is purely syntactic, and still has no effect on speed.
In the other direction, it's often fairly easy to produce code in C++ that's substantially faster than any reasonable equivalent in C. An obvious case in point is std::sort compared to C's qsort. For many cases, especially primitive types like int, std::sort will typically be three to five times as fast as qsort when operating on exactly the same data.
Most of these could theoretically be handled in C by a combination of writing specialized code everywhere needed and (perhaps) some unbelievably gross macros. I've been programming just about as long as anybody (going back as far as writing FORTRAN 66 on Control Data mainframes) and based on my experience, I'd say 1) this doesn't happen often enough to matter, and 2) thank God for that.