the null reference

I generally avoid working with pointers whenever possible, but of course it can't be totally avoided. so last night I came up with this idea of a class that would make it possible to eliminate the need for them in many situations. I'm hoping you guys can flesh out any bugs but mostly how you'd feel about using something like this. here's an example usage:

Code:

---

#include <iostream>
#include "null.hpp"

using namespace std;
using namespace xtd;

class ancestor
{
      public:
     
      ancestor( string const & name, ancestor const & parent = null )
      : name( name ), parent( parent )
      {      }

      string
            name;
      ancestor const
            & parent;     
};

void
print_lineage( ancestor const & my )
{
      cout << my.name << endl;
      if( my.parent != null )
      {
            cout << my.name << "'s parent: ";
            print_lineage( my.parent );
      }
}

int
main( void )
{
      ancestor
            God( "God" ),
            Adam( "Adam", God ),
            Cain( "Cain", Adam );               
      print_lineage( Cain );
}

---

No offense, but this is even less than useless. It's completely deranged. It only allows... excuse me, forces a reference to behave similar to how pointers behave. Look at the example function you posted... you've violated the nature of a reference! (The point of a reference isn't just to allow different syntactical sugar.) The idea is, if you get a reference you get to assume that you really have a reference. If you have to check a reference for null, you've not eliminated the need for pointers... you made references into pointers, and at the same time confused everyone.

Soma

>> If you have to check a reference for null, you've not eliminated the need for pointers... you made references into pointers, and at the same time confused everyone.

yes - if every reference handled had to be checked for null, but that is not what I am advocating here. even with pointers, we generally know exactly when to check for NULL (eg: malloc) and when not to (eg: within an array processing routine). it's all about context.

>> The point of a reference isn't just to allow different syntactical sugar.

well, they allow us to write code that is clearer and more uniform. if you prefer to call that sugar then so be it.

>> No offense, but this is even less than useless. It's completely deranged.

classic. :D

perhaps it's not for everyone, but I encourage you to experiment with it some more before you rule out it's usefulness.

Quote:

---

I generally avoid working with pointers whenever possible, but of course it can't be totally avoided.

---

Maybe it "could" be totally avoided, but no sane person would tell you that in every class definition you have to use a reference (making it non-copyable) or an actual instance of a class all to avoid the use of pointers.

I agree, I don't use pointers when I don't have to. But sometimes "I have to." Any time you have to "iterate" a structure, any time you need to decide whether or not to dynamically allocate a new class object, etc., you're going to use pointers (iterators are an example of implicit pointer use).

I agree that references have certain advantages over pointers in certain situations. So that's why they're there... and I'm not exactly sure what you're trying to accomplish then...

If people want to litter their code with the over-use of pointers (over-using the this-> is a pet-peeve of mine), so be it. It might be kinda silly to you or me, but the functionality of references already exists, so what are you trying to do? Maybe you can write your own language where everyone will be forced to do things the way you want, and you can name it Java.

the code I posted was simply a contrived example. a more typical usage might be:

Code:

---

class database
{
        class table
        {        };

        table &
        retrieve_table_1( string const & name )
        {
        /*
                if found, return a reference to the table. 
                otherwise, return null.
        */       
        }

        bool
        retrieve_table_2( string const & name, table & result )
        {
        /*
                if found, result is valid and return true.
                otherwise, return false.
        */       
        }

        table *
        retrieve_table_3( string const & name )
        {
        /*
                if found, return a pointer to the table.
                otherwise, return NULL.
        */       
        }

};

---

given the choice, I would choose to use the function retrieve_table_1 because it has a more simple interface. moreover, since it's clear that the table may not exist there wouln't be any confusion about the need to check for a null reference.

You've lost me. What good does it do whether or not you can check if a reference is null or not if I'm forced to call the function like this:

Code:

---

Table m_table;

table = retrieve_table_1( string const & a_name );

---

In which case, it won't even compile without there being something to be referenced.

like this:

Code:

---

table
      & table = retrieve_table_1( name );
if( table != null )
{
      for( unsigned r = 0; r < table.rows( ); r++ )
      {
      /*
            process a row
      */     
      }     
}

---

Quote:

---

I encourage you to experiment with it some more before you rule out it's usefulness.

---

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.

Quote:

---

I would choose to use the function retrieve_table_1 because it has a more simple interface.

---

O_o

Nothing involving this would be simple. (If you can write the class so that methods return your "'null'" or a reference then you can write it to return 'null' or a pointer to an instance just as easily--meaning that the user wouldn't have to worry about delete/free/etc. issues.)

I mean, references can not be reassigned. Suppose, for example, your writing a tool to update CD catalog information for various versions, each version mirroring the old and adding additional information to the tables, of a GUI database utility. Surely, you don't want to query for tables you don't need! You get wonky code because you can't just rely on fall through, nor can you reassign the reference.

Quote:

---

Code:

---

table
      & table = retrieve_table_1( name );
if( table != null )
{
      for( unsigned r = 0; r < table.rows( ); r++ )
      {
      /*
            process a row
      */     
      }     
}

---

---

O_o

Code:

---

table
      * table = retrieve_table_3( name );
if( table != null )
{
      for( unsigned r = 0; r < table->rows( ); r++ )
      {
      /*
            process a row
      */     
      }     
}

---

What have you gained over my example--besides a few less characters? (Keeping in mind that if the method can return a reference the object must manage the 'table's existence.)

Soma

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. Any such attempt to create one is an invalid C++ program.
The whole idea is itself a bug. What you're thinking of is impossible - end of story - Kapish?!
In fact I think it would be quite a stretch for one to call themselves a C++ programmer without knowing this.

Section 8.3.2 paragraph 4:
"A reference shall be initialized to refer to a valid object or function.
[Note: in particular, a null reference cannot exist in a well-defined
program, because the only way to create such a reference would be to bind it
to the ``object'' obtained by dereferencing a null pointer, which causes
undefined behavior."

I think Sebastiani wants the kind of pointer-like object references that exist in Java and co.

is this a null reference?

Code:

---

MyClass& func()
{
    MyClass obj;
    // time pass :D
    return obj;
}
void flips()
{
    MyClass& ref = func(); // null reference?
}

---

No, it is just undefined behaviour. ref refers to an object that no longer exists.

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! >_<

Quote:

---

that's the purpose and intent of the OP (at least it was my purpose)

---

I do not think Sebastiani intended to write code that has undefined behaviour. If you intent is to write code that has undefined behaviour, good luck to you.

Quote:

---

how do i check that "ref" is a valid or invalid reference?

---

In your given code, ref is invalid. Full stop.

Quote:

---

we have this convention of NULL pointer being invalid (not a bulletproof way though, but that's C++, and programmers know)

---

A null pointer cannot be dereferenced, but whether that means it is invalid depends on context.

Quote:

---

Originally Posted by laserlight

In your given code, ref is invalid. Full stop.

---

well of course it's easy to see in this tiny snippet of code, which is intended to give you simplest example of a reference which is non existent!

what if i got an object by reference, which was not a local object, which was heap allocated one, but some how, in difficult to follow code, the object is deleted, and all i have is the reference, how to check is it valid?

Quote:

---

I think Sebastiani wants the kind of pointer-like object references that exist in Java and co.

---

Then he should program in Java.

Quote:

---

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! >_<

---

No. Just... no. God, no! No amount of jury rigging will protect you from idiocy. Sorry, but we are discussing C++ not some magic language that disallows all forms of programmer errors. The code, and offering, provided by Sebastiani will not work to check against a null reference because, strangely, as iMalc said, there is no such thing. The only thing that the Sebastiani offering will provide is a check against his offering which would have to be returned specifically--returning it by accident would be an even bigger issue.

Quote:

---

what if i got an object by reference, which was not a local object, which was heap allocated one, but some how, in difficult to follow code, the object is deleted, and all i have is the reference, how to check is it valid?

---

This offering, indeed any offering that subverts reference logic, will not help you debug a program. It can't help you find and correct programmer errors. There are however generations of tools that will help you debug a program... use them. (In your case a heavily modified form of new/new[]/delete/delete[]/malloc/realloc/calloc/free/etc. and something very similar to 'assert' would be a huge help.)

Soma

Quote:

---

what if i got an object by reference, which was not a local object, which was heap allocated one, but some how, in difficult to follow code, the object is deleted, and all i have is the reference, how to check is it valid?

---

Use the delete key.

Perfect Solution!
but if i only figure out where to use the "delete" key? :(
my biggest head-ache in managing the project is invalid pointers, invalid references, and the code follows the path of a Cob-Web !
does someone have any experience with such stuff? what would you suggest me to make it a little easy to follow?

Quote:

---

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?)

Quote:

---

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

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.

Quote:

---

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

Quote:

---

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!

thanks Elysia!
(i have hijacked this thread it seems, sorry)
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.
end of story! i will kill my self! urrrgh!

Quote:

---

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.

Quote:

---

Originally Posted by Sebastiani

>> 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.

---

Ah yes, I remember the good old days when I was working for a company that actually took the time to document their code... It doesn't work so well with undocumented spagetti code.

Quote:

---

Originally Posted by manav

what if i got an object by reference, which was not a local object, which was heap allocated one, but some how, in difficult to follow code, the object is deleted, and all i have is the reference, how to check is it valid?

---

You can't.

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.

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:

Code:

---

int &ri = null;
assert(ri == null);

---

Strange, I was sure there was something more explicit.

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:

Code:

---

Object& Func( int data );

---

could be changed into this:

Code:

---

bool Func( int data, Object& output );

---

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.
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:

Code:

---

struct A
{
    char c;
};

struct B
{
    A a;
};

//

B b;

A & a = reinterpret_cast< A & >( b );

a.c = 'd';

---

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?

Quote:

---

Originally Posted by Sebastiani

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.

---

Here's some more info about static_casting pointers: Chapter 93. Avoid using static_cast on pointers

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!

Code:

---

int & test()
{
  return(null);
}
int main()
{
  int & val(test());
  if(0 == &val)
  {
    std::cout << "I can't believe you think this is useful.\n";
  }
}

---

Soma

Quote:

---

Originally Posted by Sebastiani

this is clearly unsafe since B::a may or may not be aligned at the base address of the outer object.

---

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.
The same cannot be said for non-PODs.

Quote:

---

Originally Posted by Soma

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?

---

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:

---

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.

---

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.


Here's something you can do with pointers that you can't do with null references:

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.
}

---

Don't break the language rules!

Quote:

---

Originally Posted by CornedBee

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.

---

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.

Embedded systems usually have their own rules.

Quote:

---

Originally Posted by CornedBee

Embedded systems usually have their own rules.

---

Having their own rules would imply that the language isn't C++, no matter how much it might otherwise look like it. So the point stands, C++ is useless on embedded, although languages which look extremely like C++ might not be.

Quote:

---

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.

---

Who said anything about dereferencing 'null' to obtain anything? (Yes, that's rhetorical; I'm just saying... I didn't.) From my perspective you can't obtain anything by dereferencing 'null'--hence the beauty of 'null'.

I have no doubt that 'type & r(*(0));' is undefined, regardless of the decoration, but that isn't what I suggested. There are handfuls of "Horrible Hacks (R)", every compiler I've ever used has a few relevant to this case, that allow you to bypass assignment of a reference. The right code, or rather the very horribly wrong code, will work in virtually every compiler; the code I suggest never manipulates the reference directly so the compiler can't complain about the assignment to 'null'--note: assignment to 'null' not assignment to '*(0)'.

Quote:

---

Don't break the language rules!

---

Agreed. I'm just saying, if you are going to break them, break the @$%! out of them.

Soma

Quote:

---

Originally Posted by brewbuck

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.

---

You can access 0x0 on embedded systems??
I've never touched an embedded system; why are they different from regular PCs in that area?

>> 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.

interesting. I always assumed that the compiler was guaranteed to generate a hardware access when dereferencing a pointer to get a reference. I wonder why they felt it needed to be undefined (perhaps they were anticipating precisely this type of hack :D)?

>> the code I suggest never manipulates the reference directly so the compiler can't complain about the assignment to 'null'--note: assignment to 'null' not assignment to '*(0)'.

ah, I misunderstood what you were saying in your earlier post. sorry about that.

>> Don't break the language rules!
>> Agreed. I'm just saying, if you are going to break them, break the @$&#37;! out of them.

these two statements may be the moral of the story here. I shouldn't have presented this as any sort of viable programming paradigm for standard C++ program. hobby code, maybe, but nothing more.

Quote:

---

interesting. I always assumed that the compiler was guaranteed to generate a hardware access when dereferencing a pointer to get a reference.

---

Since references are practically always implemented as pointers in hardware, the expression

Code:

---

T &r = *psomething;

---

becomes a simple mov in machine code, if the compiler doesn't optimize the existence of the reference away completely.