Printable View
1) can you explain what makes it undefined? I remember reading somewhere that the compiler can assume that different types do not overlap in memory but I'm not sure if that's what you're talking about.
2) good point.
3) that depends on the programmer. however odd it may seem to someone like you, there are those of us who find something like this quite logical and yes, useful. to each his own, I suppose.
Perhaps there is a use for what you have. Maybe you ought to change the name to something other than "reference" since re-inventing/obfuscating C++ references seems to be the point of contention.
May I suggest, "reference_ptr" ?
This is why I think everyone should learn C++ BEFORE they learn Java.
Java brainwashes people into equating the word reference with a psuedo-pointer mutation, and then when they really do run into real references they treat them like those psuedo-pointers in Java.
1) The result of a reinterpret_cast on pointers is unspecified. As such, it is also unspecified whether the result can be dereferenced, and thus dereferencing it yields undefined behaviour.
Since your null_ type is empty, it has effectively no alignment requirements, which is most likely less strict than the target of the cast, which means that dereferencing might hit a hardware trap. Oh, and the standard doesn't even guarantee round-tripping of the cast in this case, which means that it is undefined whether this asserts or not:
Strange, I was sure there was something more explicit.Code:int &ri = null;
assert(ri == null);
Okay, you've said it again, but not actually answer how... so, how exactly is this useful?!
I mean, this isn't even a particularly good implementation of what you've done. If you're going to go, go all out... return null, the real null/(0)/'\0'.
Soma
>> Okay, you've said it again, but not actually answer how... so, how exactly is this useful?!
that's a very subjective question. clearly you don't see much use in it at all - there's nothing I could say to change that.
>> I mean, this isn't even a particularly good implementation of what you've done.
you're more than welcome to produce a better implementation.
>> If you're going to go, go all out... return null, the real null/(0)/'\0'.
maybe you should climb down from your little glass tower and realize that we all have different viewpoints and opinions, which should be respected no matter how incompatible/irreconcilable they may be with eachother.
Given the example from before with a function that returns a reference, something like this:
could be changed into this:Code:Object& Func( int data );
Then instead of returning null if the Object isn't needed or valid, you could return false, then the caller would know that the output parameter doesn't have anything useful.Code:bool Func( int data, Object& output );
Another solution is to throw an exception if an error occurs which prevents a valid object from being returned.
Yes, but I think the point was to avoid those solutions for a cleaner interface.
I think I'd just prefer to use a pointer, though. Are there any benefits to this solution over a pointer beyond being able to use reference syntax?
I'd use a boost::optional<T&>, I think.
I've made a few changes:
- renamed the type to null_t
- with the global object being an instance of a derived class made it 'invisible' to template specializations. fixed.
- made the copy constructor private
- removed the c-style casts
my biggest concerns are CornedBee's points (1) and (2). the latter probably has no solution. can anyone confirm the former?
>> Then instead of returning null if the Object isn't needed or valid, you could return false, then the caller would know that the output parameter doesn't have anything useful.
that's the typical approach. refer to the function retrieve_table_2 in my previous post.
>> Are there any benefits to this solution over a pointer beyond being able to use reference syntax?
not really. :)
>> I'd use a boost::optional<T&>, I think.
I'll look into that. thanks.
as far as I can tell, point (2) doesn't apply here. whereas:
this is clearly unsafe since B::a may or may not be aligned at the base address of the outer object. on the other hand, casting back and forth between distinct pointers types should be completely safe as long as they aren't dereferenced (in the truest sense of the word). and if this isn't guaranteed by the standard then why not?Code:struct A
{
char c;
};
struct B
{
A a;
};
//
B b;
A & a = reinterpret_cast< A & >( b );
a.c = 'd';
Here's some more info about static_casting pointers: Chapter 93. Avoid using static_cast on pointersQuote:
Originally Posted by Sebastiani
Again, if you are going to go, go all out; return (0) and check against (0). This would completely solve '1' and '2' as offered by CornedBee. (Assuming you insert the appropriate compile-time firewalls and a few specializations, if you like, to support a few bizarre compilers--where the firewalls will block compilation otherwise.)
1) Because you would never actually dereference, or even actually use, the "'null'" object you would not need to generate the false reference in the way you do.
2) Any attempt at using the reference would result in the same behavior as attempting to use '*(0)'.
3) Of course, it is still useless in every conceivable way, subverts reference logic, and confuses everyone who knows C++--because references can't be 'null'.
Just think, with my suggestion you could make references behave even more like pointers because this would work!
SomaCode:int & test()
{
return(null);
}
int main()
{
int & val(test());
if(0 == &val)
{
std::cout << "I can't believe you think this is useful.\n";
}
}
Actually, since both A and B are PODs here, B::a is guaranteed to have the same starting address as the containing B instance, and the cast is safe, with predictable results.Quote:
Originally Posted by Sebastiani
The same cannot be said for non-PODs.
The round-trip A->B->A is guaranteed if the alignment requirements for B aren't greater than those for A. For example, if Bs always have to be aligned at 4 bytes and so do As, it's safe, but if As only need to be aligned at 2 bytes or need not be aligned at all, it isn't. Since your null_t has no members, it has no alignment requirement, and the cast to any type that does, and back, will not round-trip.Quote:
Originally Posted by Soma
No. Dereferencing the null pointer to get a reference is explicitly mentioned to be undefined. It doesn't matter that no hardware dereferencing actually takes place. A compiler is allowed to reject the code if it can prove you're dereferencing 0.Quote:
Again, if you are going to go, go all out; return (0) and check against (0). This would completely solve '1' and '2' as offered by CornedBee.
Here's something you can do with pointers that you can't do with null references:
Don't break the language rules!Code:foo *fn1(); // Might return null.
foo &fn2(); // Might return null.
if(foo *pfoo = fn1()) {
// pfoo isn't null. If fn1 returns null, the block isn't entered. pfoo isn't visible outside the block.
// It's not possible to access a null pfoo.
}
if(foo &rfoo = fn2()) {
// If foo has no boolean conversion, this fails to compile.
// If foo has a boolean conversion and fn2 returns an object, this conversion will be used to
// decide whether the block is entered. Unless the conversion determines a "bad" state,
// this is not useful. (And if it does, then returning null is not useful.)
// If foo has a boolean conversion and fn2 returns null, the program will crash! Or, worse,
// because it's not a true null it may do something very silly.
}
That's kind of dumb. How am I supposed to access memory location 0 on an embedded system with such a rule in place? If true, it renders C++ useless for embedded development.Quote:
Originally Posted by CornedBee