Thread: the null reference

but if i only figure out where to use the "delete" key?

That's why Prelude claims her best code is written with the delete key. (Or was it backspace?)

Originally Posted by manav

undefined!!!
that's the purpose and intent of the OP (at least it was my purpose)
how do i check that "ref" is a valid or invalid reference?
we have this convention of NULL pointer being invalid (not a bulletproof way though, but that's C++, and programmers know)
how we check for above "ref" being valid or invalid?
i has the same situation in my project, and it is giving me nightmares! >_<

One way to easily detect that some object has been free/deleted is to create your own versions of new & delete, and let the delete version fill in the memory with some known pattern (e.g. 0xCFCFCFCFCF - that's almost guaranteed to crash you if you use it as a pointer).

--
Mats

Originally Posted by manav

oh thanks Mats!
i run my program under windbg, so the moment i reference an invalid object, the program breaks to the point where it happened.
in my case it happens when a function on deleted object is called, and when that function tries to read a member variable.

Yes, and then you have to trace back where that object was created.

If you have your own new and delete operator functions, then you can also record the return address [may need a bit of trickery to do that, but it can be done], and find where the object was created/deleted - this would of course involve allocating a bit of extra memory and using that extra memory to store this sort of info.

--
Mats

Originally Posted by manav

oh thanks Mats!
i run my program under windbg, so the moment i reference an invalid object, the program breaks to the point where it happened.
in my case it happens when a function on deleted object is called, and when that function tries to read a member variable.

Argh. Use Visual Studio you... you... MONKEY!
Windbg is not as useful as Visual Studio when it comes to debugging if you ask me.
Visual Studio already fills memory with a known pattern when uninitialized and when deleted in debug mode, so it provides this features for you for free. Why are you trying to make things hard on yourself?
Use Visual Studio.

And do yourself another favour - use smart pointers to ensure objects don't delete prematurely and don't use references to heap objects, use smart pointers!

Originally Posted by manav

but i think to fully utilize the features of MSVC i have to make a fully working MSVC project. currently i have a dummy MSVC project (after you helped me a little). this dummy project allows me to use other features of MSVC like completion, opening the headers by right click, finding definitions etc., but i can't build (you remember, we discussed that before) it under MSVC. that's why it's a dummy project. my work involves Qt etc. and to really use it MSVC way, i need a commercial version, while i am using open source version, with a patch, that allows it to compile using MSVC cl compiler.

Bzzt. Wrong.
You only need Professional if you want the resource editor or MFC or team edition stuff. Otherwise Express works just fine.
And I also told you before that your manual compiling with the stupid makefile is destroying the code is all sorts of horrible ways (like no C++ exceptions!). You should ask on the forum or google or ask on Qt's forum or some support alternative on how to compile Qt in a Visual Studio project.

Alternatively, another bad way, is to create a makefile project first.

>> There never has been, nor will there ever be such a thing as a null reference in C++. There is no way of creating such a thing and no way for such a thing to ever exist.

that is correct. but that doesn't mean it can't be simulated.

>> Uh... no. At the very best, the very best, with your "addition" you save one character per reference event over a pointer, and you still subvert reference logic.

noone uses a library of code without first reading the documentation. having done so, the only thing subverted would be small-mindedness.

>> my biggest head-ache in managing the project is invalid pointers, invalid references, and the code follows the path of a Cob-Web !

the easiest way to address that is to use 'smart' pointers.

at any rate, I admit something like this is a bit unorthodox, maybe even a little taboo. like opera, either you love it or you hate it.

The first example can also throw if it can't find a valid return!
But I guess that you've thought of that and wanted a returning function.

I can, off-the-cuff, think of three problems with this idea.

1) It's undefined behaviour. You dereference a type-punned pointer in the Type& conversion operator. It doesn't matter that the result is a reference, so the compiler doesn't actually dereference. The code is simply undefined.

2) It is a detriment to debugging. If you dereference the null pointer, the program will crash and burn. This is good. If you dereference your null reference, you read or write to the global variable area. This is bad.

3) It is a detriment to understanding. This is the worst problem of all. C++ references are never null. Every programmer knows this. Only, you break this rule and expect programmers to accommodate your oddness. They won't.
You claim that no one uses a library without reading the documentation. But library documentation is there to document what the library provides. It's not there to tell the programmer in what ways the library breaks the language rules. Nobody expects that references can't be null, so they won't even notice if you put this in the documentation. That's because C++ references aren't null, so clearly they can't be null in your library, no matter what the documentation says.
The only way to get programmers to notice this oddity is to put it in fat, 72-point font on the first page of the documentation: "References can be null."
But even then, people will not know what you mean. They'll either think you're confusing references and pointers, or they'll go looking into the library reference to search for a class called "reference". They won't suspect that you mean C++ references, because C++ references can't be null.
And when the programmers finally do understand what you mean, they'll drop your library like a poisonous snake and run away to where programmers play by the rules.

Do not break the language rules.