After b = new String(a) and c = new String(a), b.equals(c) but b != c. No matter how much state they share, the objects themselves must be distinct--there's no way for a constructor to give you a reference to an existing object instead of creating another.
Strings constructed at runtime aren't interned, only literals and constants. Otherwise they wouldn't have had to provide an intern method or override equals.
I thought that's one of the differences between C and C++. A C compiler can get away with
#define NULL ((void *) 0)
but a C++ compiler cannot, because the implicit conversion from (void *) to any other pointer type has been removed.
And it's important to note that only a zero value that's a compile-time constant has this meaning. Casting a zero-valued int to a pointer at runtime summons nasal demons (though many recent platforms have a clean enough architecture that a word-sized zero really is a null pointer).
But the syntax was copied from C. If the argument is that you write "i++" in Java because that's what you write in C, the counterargument is that you should have been writing "++i" in C whenever you didn't actually need the previous value. C++ just increases the cost of the incorrect style.
Unlike Java's (needlessly crippled) "primitive types", SmallInteger is a genuine class. Instances happen to be implemented more efficiently with no boxing, but they still support an extensible set of messages and can be intermingled transparently with other (boxed) objects. Lisp fixnums act like this too--the trick is to reserve a few tag bits to tell you whether a value is a pointer to the most general representation of class instances, or an unboxed integer (or character, boolean, cons...).
It is best to let the compiler choose the fastest integer type except in special cases, but needing more than the language offers--16 bits--has to be one of those cases. Competent coders use the preprocessor to either include typedefs or refuse to compile if they want INT_MAX > 32767.
Assuming int is 32 bits is absurd. We already have an integer type that's at least 32 bits, namely long. And if you want the value of INT_MAX you know where to find it.
What's wrong with bad coding blowing up at runtime?
If you can easily prove that it can't, is there any reason to run the risk?
From my C++ experience, genericity equals
crappy performance in time and space.
Time? How can a compiler produce worse code given more information about the arguments? Space is the usual tradeoff. If you want inline wrappers that just cast and use one real implementation, you can do that too.
Any overload of operator && is strict (though the builtin is not), because they didn't provide any way for a user-defined function to request evaluation of a non-strict argument. You can emulate this yourself with expression-tree classes but it's a lot of work.
"In C" doesn't mean alloca() will exist, even if it happens to be in your implementation. And a compiler could produce better code for a known set of objects (at fixed offsets in a traditional stack frame) than for accessing one of an unknown number of randomly-sized allocations.
Out of the box Emacs offers a class browser, reindents source, jumps to compiler errors, and integrates version control systems and debuggers. In what sense is that not an IDE?
Liveness is a global property. Pointers are dangerous unless you know what everyone is doing--or might ever do.
Now that generational copying collectors are often faster than malloc/free, dangling pointers are an entire class of errors that it's stupid to still tolerate.
Do you install new binaries for everything whenever a new security advisory comes out, or just do the ones you think of and then hope you didn't miss any?
Even after you've add enough memory to waste, using it still isn't free. The relative penalty for cache or even TLB misses is large and growing all the time, so paging in N copies of the same object code is just as gross as downloading N copies in the first place.
Besides, Debian GNU solved your "dependency hell" problem a long time ago, right down to side-by-side deployment being possible for those few libraries whose maintainers aren't competent to make backward-compatible changes.
... and upgrading the shared library repairs them all simultaneously. If they were statically linked, you wouldn't even know which executables need to be replaced.
It's fairly common to comment out markup when hand-editing, since <![IGNORE[...]]> can't be used within a document. Skipping non-markup in the document should be just a matter of matching the Perl regex
If someone else defines a foo element in a different namespace, I don't see how you can do anything other than ignore it--it's almost certainly not what you were looking for, and you have no idea what it might mean.
Certain details of the format have to be fixed (because if you don't know anything about your input you can't really consume it, only ignorantly transform it) but the format can still be extensible. For example, that could be implemented in XPath by
//user[@id="abc01"]/@real-name
which will search the entire document for the matching user element, no matter which other attributes are in use and which elements (LDAP info? groups?) may be nested around or inside it.
<foo isn't allowed in an attribute value, but it could appear in marked sections, comments, or processing instructions (which aren't too hard to ignore), or in a processing entity declaration in the prolog (which has to be fully parsed to deal with), or in a few other places if you read the external DTD subset. It also won't do what you want if the element you want is in a namespace (the correct prefix, if any, is unpredictable) or if the document uses default namespaces (you might have found someone else's foo element from a different namespace).
He's not being "tried", only interrogated. He hasn't been permitted to mount a legal defense. The Fifth Amendment requires due process for all criminal cases (the bit about war only applies to the clause about indictments), so why is military jurisdiction allowed to withhold it?
GML originated at IBM, where they wouldn't have screwed their own customers by saying "let's require ASCII!" If you want to use C0 control characters as delimiters, all you need is a SGML Declaration, but keep in mind that those characters (except U+0009 HORIZONTAL TAB) have no semantics in Unicode.
The problems with MDI are that you can't directly reach those documents via the window manager, and that you're stuck with an opaque bounding box around all the documents that only wastes real estate. Tabs are actually even worse--at least with MDI it's never impossible to see two documents side by side.
Re:Dave hit the nail on the head
on
Hyatt Discusses Tabs
·
· Score: 2, Informative
All the abilities you're describing (open in background, open multiple URLs) are just as feasible with real browser windows. The debate is only whether every major app ought to have its own half-assed window manager.
Might be using four RAID arrays plus a boot drive. Or have eighteen IDE controller channels (four per card and two on the motherboard?) with one used for a CD drive. Or built a 16-drive filesystem due to some obscure size limit and then added a hot spare. Hard to tell while the images are unavailable.
Protector ended in an elaborate arms race and running battle, working off nothing more than the history of the Pak and two points of light. One of the Pak in the library (looking for a mission) might simply look up and deduce that a core explosion would inevitably come.
Cautionary tales?
on
Ask Larry Niven
·
· Score: 5, Interesting
You've built worlds with uncommonly dystopian elements, such as Plateau's long tyranny over a disarmed populace, organlegging, all-out war with ruthless aliens, and suppression of dangerous technology. Have you intended any of these to be cautions about likely (or even inevitable) events, or just interesting to think about?
Slashdot Mirror
After b = new String(a) and c = new String(a), b.equals(c) but b != c. No matter how much state they share, the objects themselves must be distinct--there's no way for a constructor to give you a reference to an existing object instead of creating another.
Strings constructed at runtime aren't interned, only literals and constants. Otherwise they wouldn't have had to provide an intern method or override equals.
And it's important to note that only a zero value that's a compile-time constant has this meaning. Casting a zero-valued int to a pointer at runtime summons nasal demons (though many recent platforms have a clean enough architecture that a word-sized zero really is a null pointer).
But the syntax was copied from C. If the argument is that you write "i++" in Java because that's what you write in C, the counterargument is that you should have been writing "++i" in C whenever you didn't actually need the previous value. C++ just increases the cost of the incorrect style.
Unlike Java's (needlessly crippled) "primitive types", SmallInteger is a genuine class. Instances happen to be implemented more efficiently with no boxing, but they still support an extensible set of messages and can be intermingled transparently with other (boxed) objects. Lisp fixnums act like this too--the trick is to reserve a few tag bits to tell you whether a value is a pointer to the most general representation of class instances, or an unboxed integer (or character, boolean, cons...).
It is best to let the compiler choose the fastest integer type except in special cases, but needing more than the language offers--16 bits--has to be one of those cases. Competent coders use the preprocessor to either include typedefs or refuse to compile if they want INT_MAX > 32767.
Assuming int is 32 bits is absurd. We already have an integer type that's at least 32 bits, namely long. And if you want the value of INT_MAX you know where to find it.
If you can easily prove that it can't, is there any reason to run the risk?
Time? How can a compiler produce worse code given more information about the arguments? Space is the usual tradeoff. If you want inline wrappers that just cast and use one real implementation, you can do that too.
Any overload of operator && is strict (though the builtin is not), because they didn't provide any way for a user-defined function to request evaluation of a non-strict argument. You can emulate this yourself with expression-tree classes but it's a lot of work.
"In C" doesn't mean alloca() will exist, even if it happens to be in your implementation. And a compiler could produce better code for a known set of objects (at fixed offsets in a traditional stack frame) than for accessing one of an unknown number of randomly-sized allocations.
Out of the box Emacs offers a class browser, reindents source, jumps to compiler errors, and integrates version control systems and debuggers. In what sense is that not an IDE?
Liveness is a global property. Pointers are dangerous unless you know what everyone is doing--or might ever do.
Now that generational copying collectors are often faster than malloc/free, dangling pointers are an entire class of errors that it's stupid to still tolerate.
Even after you've add enough memory to waste, using it still isn't free. The relative penalty for cache or even TLB misses is large and growing all the time, so paging in N copies of the same object code is just as gross as downloading N copies in the first place.
Besides, Debian GNU solved your "dependency hell" problem a long time ago, right down to side-by-side deployment being possible for those few libraries whose maintainers aren't competent to make backward-compatible changes.
... and upgrading the shared library repairs them all simultaneously. If they were statically linked, you wouldn't even know which executables need to be replaced.
It's fairly common to comment out markup when hand-editing, since <![IGNORE[...]]> can't be used within a document. Skipping non-markup in the document should be just a matter of matching the Perl regex
If someone else defines a foo element in a different namespace, I don't see how you can do anything other than ignore it--it's almost certainly not what you were looking for, and you have no idea what it might mean.
<foo isn't allowed in an attribute value, but it could appear in marked sections, comments, or processing instructions (which aren't too hard to ignore), or in a processing entity declaration in the prolog (which has to be fully parsed to deal with), or in a few other places if you read the external DTD subset. It also won't do what you want if the element you want is in a namespace (the correct prefix, if any, is unpredictable) or if the document uses default namespaces (you might have found someone else's foo element from a different namespace).
He's not being "tried", only interrogated. He hasn't been permitted to mount a legal defense. The Fifth Amendment requires due process for all criminal cases (the bit about war only applies to the clause about indictments), so why is military jurisdiction allowed to withhold it?
GML originated at IBM, where they wouldn't have screwed their own customers by saying "let's require ASCII!" If you want to use C0 control characters as delimiters, all you need is a SGML Declaration, but keep in mind that those characters (except U+0009 HORIZONTAL TAB) have no semantics in Unicode.
The Mozilla binding is ctrl-click: it's either "open new window" or "open new tab", your choice.
The problems with MDI are that you can't directly reach those documents via the window manager, and that you're stuck with an opaque bounding box around all the documents that only wastes real estate. Tabs are actually even worse--at least with MDI it's never impossible to see two documents side by side.
All the abilities you're describing (open in background, open multiple URLs) are just as feasible with real browser windows. The debate is only whether every major app ought to have its own half-assed window manager.
Might be using four RAID arrays plus a boot drive. Or have eighteen IDE controller channels (four per card and two on the motherboard?) with one used for a CD drive. Or built a 16-drive filesystem due to some obscure size limit and then added a hot spare. Hard to tell while the images are unavailable.
Protector ended in an elaborate arms race and running battle, working off nothing more than the history of the Pak and two points of light. One of the Pak in the library (looking for a mission) might simply look up and deduce that a core explosion would inevitably come.
You've built worlds with uncommonly dystopian elements, such as Plateau's long tyranny over a disarmed populace, organlegging, all-out war with ruthless aliens, and suppression of dangerous technology. Have you intended any of these to be cautions about likely (or even inevitable) events, or just interesting to think about?