| |||||||||||||
GCC 4.6.0 releasedGCC 4.6.0 releasedPosted Mar 29, 2011 2:39 UTC (Tue) by HelloWorld (guest, #56129)In reply to: GCC 4.6.0 released by cmccabe Parent article: GCC 4.6.0 released
The fact that Java needs wrapper classes for this, and for other things, is a design limitation of Java, not of primitives themselves.The term "Primitive type" refers to different things in different languages. I was talking about primitive types in Java, and they're a bad idea. I don't know about Go and its notion of primitive types. Having a bool type is "obviously a bad thing," as you can obtain the same effect with ints.Um no, you can't. The point of having a boolean type is to enable the compiler to check that there is actually a logical value in your if statement or while loop, and not a numeric value. Oh wait, that argument is bogus.I said something is obviously a bad thing if it's not needed and causes bugs. You deliberately didn't quote the second bit, because you knew that if you had, you wouldn't have had much of a point. Please stop doing that. And please tell me: what is in your opinion a more convincing way to show that a language feature is a bad idea than showing that it's dangerous and that you don't actually need it? This is just more "argument by assertion" on your part. I find NULL, or nil, or None, or whatever you call it, to be useful more often than it is not. And when I don't have it, I usually have to create some kind of special class value to represent "zero" which is usually just an annoyance.It is trivial to do this once generically. Heck, I'll just do it for you.
abstract class Option<T> {
public abstract T get();
public abstract bool isPresent();
}
final class None<T> extends Option<T> {
public T get() { throw new Ouch(); }
public bool isPresent() { return false; }
}
final class Some<T> extends Option<T> {
private final T t;
public Some(T t) { this.t = t; }
public T get() { return t; }
public bool isPresent() { return true; }
}
Put this in java.util and you have everything you need to represent optional values. If a method takes an optional value of type T you declare a formal parameter of type Option<T>. If you don't want to pass a value, pass new None<T>(), otherwise, pass new Some<T>(myT). What does null do better than this simple class hierarchy?
(Log in to post comments)
GCC 4.6.0 released Posted Mar 29, 2011 5:34 UTC (Tue) by cmccabe (guest, #60281) [Link]
> What does null do better than this simple class hierarchy?
I'm well aware that you can build a nullable pointer out of a non-nullable one. C++ has boost::optional which is kind of a nullable object, templated in a similar way. However, that technique is less efficient and more cumbersome than just using a regular pointer.
So far, you haven't presented any actual evidence that non-nullable pointers are helpful to programmers. Your whole argument depends on the idea that nullable pointers are somehow this huge source of bugs. But in my 10 years of C++ (and some Java) I haven't found this to be the case. I am much more worried about race conditions, implicit narrowing of numerics, and code that handles error conditions poorly than I ever will be about NULL pointers.
It's like trying to sell me insurance against stampeding elephants. I know that elephants can kill, but honestly, I'm not that worried about them. I have other things to worry about.
C++ has non-nullable pointers in the form of references. However, despite this fact, programmers continue to use pointers. Apparently either the advantages of a non-nullable pointer aren't that great, or the weight of legacy code is too heavy. I guess you're free to interpret it however you like.
When you look at static code analysis tools that people run in the real world, they tend to look for things like race conditions, uninitialized memory uses, double frees, and so on. You could imagine annotating your pointers with something like "attribute __nonnull", and using your tool to look for violations of that, but in practice, nobody bothers to do it.
Here's an example of such an implementation:
Now is any big Java project using this stuff? If not, why not? These are the kind of questions we should be asking.
Please don't misinterpret what I'm saying. I'm not necessarily against non-nullable pointers, I'm just saying that the evidence presented here has not been persuasive.
GCC 4.6.0 released Posted Mar 29, 2011 10:52 UTC (Tue) by nix (subscriber, #2304) [Link]
I've been religiously doing nonnull attribute decorations in the code I write for more than ten years. Violations are hardly ever detected.
However, I get null pointer errors on a fairly regular basis, because GCC's nonnull attribute can only warn you if it can be sure a pointer is NULL, and if it's received from somewhere else it can't tell that. Whole-program compilation will help, but a lot of code is in shared libraries, and there, you have no recourse.
But if the *actual type* of the pointer was different (so the compiler could distinguish 'non-null pointer to object' and 'nullable pointer to object' even for external symbols) this error would largely disappear (as it does in C++ with references). However, this would require changing the C linkage model, and probably mangling names. Ain't gonna happen.
GCC 4.6.0 released Posted Mar 30, 2011 7:13 UTC (Wed) by jrn (subscriber, #64214) [Link]
Sounds like a job for sparse.
GCC 4.6.0 released Posted Apr 1, 2011 17:51 UTC (Fri) by nix (subscriber, #2304) [Link]
Yeah, agreed, and if the system I'd been working on then hadn't been a horrible preprocessor-mangled nightmare (Pro*C, and if you have experience with it, my condolences) so sparse would have drowned the real warnings in all the screaming about the hideous wrecked code the preprocessor inserted.
GCC 4.6.0 released Posted Mar 29, 2011 13:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> However, that technique is less efficient and more cumbersome than just using a regular pointer.
If these are an actual problem in your code, you're probably overusing "optional" elements anyway. I almost never need them.
> Your whole argument depends on the idea that nullable pointers are somehow this huge source of bugs. But in my 10 years of C++ (and some Java) I haven't found this to be the case.
> C++ has non-nullable pointers in the form of references. However, despite this fact, programmers continue to use pointers.
> Please don't misinterpret what I'm saying. I'm not necessarily against non-nullable pointers, I'm just saying that the evidence presented here has not been persuasive.
|
|||||||||||||