41–50 of 66 posts
Any use cases for Nil, that is, the class pointer to nothing? I've not seen it in the wild (which isn't saying a great deal.)
You could use it to test whether or not you really got a class from NSClassFromString(). For instance: Class _myClass; // aClassName was previously defined if((_myClass = NSClassFromString(aClassName)) == Nil) [NSException raise:@"InvalidClass" reason:@"Unknown class named %@.", aClassName); id myObj = [[_myClass alloc] init]; [myObj whatever];
Good article overall. However, I must object to this bit: "C represents nothing as 0 for primitive value" That's not true. There is no "nothing" for integer types, and floats either also lack "nothing", or have NaN as their "nothing", depending on your perspective. One of the (many) annoying features of C-style NULL is that it means that some types are effectively option types while other types aren't, and there's no…
Definitely spot on regarding 0 not representing 'nothing'. However, 'int *' is inherently "pointer to int or nothing" (in the same style as your NSString example), so I'm not sure I agree with your assertion that some types are option types while some aren't in C. Any type can be an option type (in your sense of the term, again a la your NSString example) by making it into a pointer. Similarly, using an NSString with…
(Using the prevailing terminology. I'm not sure I'm comfortable with this use of the term "option type", but I'm rolling with it for now.)
Earlier quoted context omitted.
Definitely spot on regarding 0 not representing 'nothing'. However, 'int *' is inherently "pointer to int or nothing" (in the same style as your NSString example), so I'm not sure I agree with your assertion that some types are option types while some aren't in C. Any type can be an option type (in your sense of the term, again a la your NSString example) by making it into a pointer. Similarly, using an NSString with…
int and pointer to int are two different types. Pointer-to-int being an option type does not make int an option type. So there are still option types and non-option types. (Using the prevailing terminology. I'm not sure I'm comfortable with this use of the term "option type", but I'm rolling with it for now.)
It's worth noting that Go has interesting handling for empty values as well. A nil basically means "the zero value for a given data type". Thus, an empty array compares equal to nil: http://tour.golang.org/#36
package main
import "fmt"
func main() {
var z []int = make([]int, 0, 0) // jerf changed this line
fmt.Println(z, len(z), cap(z))
if z == nil {
fmt.Println("nil!")
} else {
fmt.Println("initialized slice is not nil")
}
// This won't even compile; "cannot convert nil
// to type int" at the if clause:
// var a int = 0
// if a == nil {
// fmt.Println("jerf is wrong; nil does == 0")
// }
}
Earlier quoted context omitted.
This isn't a good idea since even it happens to work it invokes undefined behaviour. If you change the method to virtual it will crash. I think you mean non-virtual method, not 'class method' or static method which wouldn't have a this pointer.
That's a good point, calling a virtual method on a null pointer is the source of some backtraces that seem to start a few bytes past 0. Naming things is always difficult, but I meant class method, although what I should have said was non-virtual class method, which is possible in C++. Both virtual and non-virtual have "this" pointers, the difference is whether the class method to call is looked up at runtime or compi…
"Class method" is usually used to refer to methods that class objects have themselves, as opposed to an "instance method", which is a method that instances of a class possess. C++ doesn't have class objects or class methods.
Earlier quoted context omitted.
You do raise an interesting point that a nil swallowing language forces you to write your methods in such a way as to logically return false for a nil receiver. I'd argue this is the way most methods are naturally written, so it doesn't have too much of an impact. I'm struggling to think of an example where logically returning true for a nil receiver is a much more natural than the other way around. Most of them, inc…
`[a compare:b]` returns 0 both if they are equal and if a is nil.
Also, nils aren't allowed in the collection classes, so sorting with compare: will simply never encounter this case.
Earlier quoted context omitted.
To clarify: I mean to say that 0 represents "nothing" in C in the same way that it does in math. This is one of the things I love about C--the ability to exploit the properties of numbers directly, rather than needing to build abstractions around them. Bitmasks, for example, are one of my favorite things ever. But yeah, point well-taken. Perhaps I'll take the opportunity to wax on the other special values used in Fou…
0 isn't really "nothing", though. It's special, in that it's the additive identity of a lot of useful sets of numbers, but it's definitely something. An integer containing 0 is completely different from a pointer containing nil, conceptually speaking. To really have "nothing", you could use an int*, where a NULL pointer means "nothing", and a valid pointer means it contains a value. Or something more efficient with e…
Nice article, but I just wanted to throw out that if being able to call a class method on a null object in C++ is desirable, you can actually check for that condition instead of just crashing. if(!this) return false; // Or whatever Of course it's open for debate as to whether this is something to encourage, but it can help from having to use a Null Object pattern in some situations.
class X
{
int a;
public:
X() : a(123) { }
int get_a() { return this ? a : 1; }
};
class Y
{
int b;
public:
Y() : b(456) { }
int get_b() { return this ? b : 2; }
};
class Z : public X, public Y
{
int c;
public:
Z() : c(789) { }
int get_c() { return this ? c : 3; }
};
#include
int main()
{
Z *z = NULL;
std::cout get_a() get_b() get_c() Earlier quoted context omitted.
To clarify: I mean to say that 0 represents "nothing" in C in the same way that it does in math. This is one of the things I love about C--the ability to exploit the properties of numbers directly, rather than needing to build abstractions around them. Bitmasks, for example, are one of my favorite things ever. But yeah, point well-taken. Perhaps I'll take the opportunity to wax on the other special values used in Fou…
0 isn't really "nothing", though. It's special, in that it's the additive identity of a lot of useful sets of numbers, but it's definitely something. An integer containing 0 is completely different from a pointer containing nil, conceptually speaking. To really have "nothing", you could use an int*, where a NULL pointer means "nothing", and a valid pointer means it contains a value. Or something more efficient with e…
Or go to Wikipedia: 'The wThe word zero came via French zéro from Venetian zero, which (together with cypher) came via Italian zefiro from Arabic صفر, ṣafira = "it was empty", ṣifr = "zero", "nothing". ord zero came via French zéro from Venetian zero, which (together with cypher) came via Italian zefiro from Arabic صفر, ṣafira = "it was empty", ṣifr = "zero", "nothing".'
Earlier quoted context omitted.
`[a compare:b]` returns 0 both if they are equal and if a is nil.
Cheers for the counter-example. I can't think of a compare method in the Objective-C core lib (the biggest nil-swallowing lib I know of). Does anyone know of one? Would be interesting to see how it's handled and if it causes issues. You could return an enum, which would allow you to use non-obvious values (Lower = 1, Equal = 2, Higher = 3), though this would make it a bit of a pain to interface with C-style libs. Obv…