The object Pobj is a pointer and is much larger than 8 bits. More likely 32 or 64 bits. The reference, for the purpose of this discussion, is more or less a pointer with different syntax; you can treat its size, overhead and benefits just like if it was a pointer.

You probably meant 8 bytes.

I meant 8bits, which is not accurate as one may see.
[/quote]
For the record, pointers aren't 8 bits either. They are (probably) 8 bytes (64 bits) on a 64 bit computer.
On my 32 bit Windows 7, they are 4 bytes (32 bits).

Get this: A char is 1 byte, but a pointer to char is 4 bytes... (on my machine).
#include <iostream>
#include <limits.h>
int main()
{
std::cout << "sizeof(char) = " << sizeof(char) << " bytes, and " << (sizeof(char) * CHAR_BIT) << " bits.\n";
std::cout << "sizeof(char*) = " << sizeof(char*) << " bytes, and " << (sizeof(char*) * CHAR_BIT) << " bits.\n";

std::cout << "Note: In this situation, a 'byte' is considered " << CHAR_BIT << " bits." << std::endl;

return 0;
}

Outputs:
[html]sizeof(char) = 1 bytes, and 8 bits.
sizeof(char*) = 4 bytes, and 32 bits.
Note: In this situation, a 'byte' is considered 8 bits.[/html]

Try it online, or execute the code yourself.

sizeof() returns the size of the variable or variable type, measured in whatever the number of bits in an unsigned char is, which is usually 8 bits, and garunteed to be at least 8 bits. You can get the actual size of an unsigned char with CHAR_BIT (from limits.h). But I just mostly assume they are 8 bits - you have to make those assumptions sometimes, or you go crazy. I bet you think a minute has 60 seconds in it, too.

[quote name='Servant of the Lord' timestamp='1347833400' post='4980723']
I bet you think a minute has 60 seconds in it, too.

I will confirm that statement, depends the start point of second counting.
Else i am not scientist and approx value of 60 seconds in minute suffices for my needs.

And much thanks for explaining that sizeof function works i will do homework
[/quote]
It's not about being scientific and that a minute has approximately 60 seconds, or that it depends on how you count. A scientific minute does have exactly 60 seconds by definition. But the problem here is the effect of having a time that is bound to the rotation of the earth, like GMT or UTC. Leap seconds are added or removed from the time to keep the clock in sync with the rotation of the earth to ensure that the length a day is 24 hours +/- 0.9 seconds. On some days, the very last minute of the very last hour of that day has either 61 or 59 seconds, not 60 as a normal minute. If you have a time-stamp critical application, you may be in trouble when some systems are suddenly off by a second and you have times stamps that are not in sync anymore.

There are other time systems that don't have leap seconds, in which a minute is always 60 seconds, for example atomic time. At the introduction of atomic time, it was set to GMT. The difference is that atomic time ticks according to the definition of a second, with 60 seconds a minute and so on, but without leap seconds. Today, the atomic time is 30 or so seconds ahead of GMT due to added leap seconds.

Is this necessary to know? In everyday life, probably not. You're most likely fine assuming a minute always has 60 seconds. Just like you can assume that in your everyday development you can assume that a byte has eight bits. Some platforms, just like some application are time-stamp critical, your assumptions may be wrong and a byte isn't eight bits anymore. There are often more to it to trivial and well known facts, and it is not always as easy and trivial as it may sound

PUFfff.
My brain just blew up...
i had no idea that 0.9sec is skipped each day

I like this education.

No, we don't skip 0.9 seconds every day. The length of a day is varying on the order of milliseconds, and a leap second is introduced once these milliseconds have accumulated to more than 0.9 seconds. A leap second is currently introduced roughly once every three years or so, but it varies. So it's just a second on a relatively large time scale.

This relatively small adjustment over a long period is what can make it difficult; it doesn't happen often so you can practically try and observe it as it happens. But it does happen, and if you depend on it you have to make sure that you can handle it.

you can assume that a byte has eight bits
byte isn't eight bits anymore

I understand the point you are making, using bytes and bits comparison was not the best idea,
at least in my knowledge since , byte = 8 bits. byte does not exist as far as i know, we only use it to reference 8 bits
as we use minute to reference 60 seconds etc...
[/quote]
The time and the byte comparison are on different scales practically, yes, but sort of demonstrates the same idea about assumptions. The definition of a byte depends on context, and within the context of C and C++ it is the smallest unit of storage which is the storage of the type char and its variants. If a char is 32 bits, then so is a byte in that particular context. If you are explicitly talking about groups of 8-bit of information, then the term octet is more accurate and less ambiguous.

But as I said, it is most likely not necessary for you to know this; especially about the time, but you should at least be aware of the byte issue even if you choose to ignore it for the moment.

Personally, I am at trying to not depend on these kind of assumptions as far as practically reasonable. I don't write my code to be aware of leap seconds (I just assume they don't exist; they simply don't affect anything I do), but I try my best to not assume that a byte is eight bits, and if I do assume that, I will also isolate that code as much as possible. But then again, I am more picky on these kind of details than most are ;)