c++ pointers pass by value pass by address F2DW cast float to unsigned int
0uploaded as quick time MOV animation codec no audio .
c++ always seems so convoluted, at times. Just like the use of the word "void" .
How many definitions\context of one word can there be ?
Just to say, pointers are NOT trivial. So why do the books treat it as such ?
"C traps and pit falls" 1989 ISBN 0-201-17928-8 Addison-Wesley
reprinted with corrections November 1988
uses almost 3 pages to analyze this:
( * ( void( * ) ( ) ) 0 ) ( ) ;
....^................^...little hats to show 2 of the parenthesis pairs.
my quick analysis.
( void( * ) ( ) ) 0................this inner part cast 0 as a "void function pointer"
........................................a function points to address 0
then the outer left most * uses the function pointer to make the call\jump to address 0
quick summary:
below is a simple memory map of any Identifier , of an "actual parameter"
during a function call .
address..............content
1000...................data( could be anything,.. an integer, an address, a char )
pass...................pass
1000 and.............data and
we passed...........we passed
by address...........by value
It used to be, that everytime I thought I knew how to write or read a pointer statment
I would bump into another one that choked me up.
That's when I took a break, then I started using the:
1. simple memory maps
2. reading the pointer statements from Right to left
inside to outside
3. viewing the & and * operators and what makes a valid argument to these
.....two operators
4. step by step evaluation.
When I tuned into that , I could finally do it. Some, well most books have a really poor
showing of pointers. A simple pointer statment , and that's it and their off onto other
stuff. All the power of c++ is in pointers.
Sad to say, while Malik's huge book of 1500 pages has some good stuff, his link list,
stacks and queues are good, His step by step pointer description is just plain crap.
It provides no reasoning as how to analyze a pointer statment , which becomes
important when the compile fails and a pointer statment must be fixed .
Deitel and Deitel have much better pointer coverage , but still incomplete.
Comment of number 5 ( in the graphic). the pass by value, even though the value is an address . Well, in assembly language, the processor has
"indirect addressing modes" so, 5. is a "indirect pass by address" but a hard core
C guru would still want to classify it as "pass by value"
note on 3. and 4( in the graphic ).
Both of these are "passing a pointer by address" because the
address of a pointer namely pMyInt is being passed. It must be received as
as a double derefeernce on the left side, because we are inherently using 2 linked
addresses,...the address of pMyInt links to the content of pMyInt( where pMyInt content is an address too ) . Even if we have no need to double dereference
ppMyInt or prMyInt of the left side, we must still satisfy the compiler,
cause the compiler knows there are 2 linked addresses.
4 ( in the graphic ).
* & is the only order of these operators. & ( c++ Ref ) got the address of pMyInt
........and was assigned into prMyInt memory space.
........When we use prMyInt , prMyInt( as a c++ style reference ) will return
........the content of pMyInt , which is an address . If we
........choose, we could assign a new address to pMyInt via
........prMyInt = some address ;
........or we could double dereference as * prMyInt to read memory space myInt ,
........and we only need to show 1 operator.
overall, this "pointer to a pointer.....prMyInt" , involves 3 memory spaces:
prMyInt....pMyInt....myInt
Again, right to left reading\evaluation
passing a pointer by address is usefull when we want to initialize a pointer.
A function prototype shows func( int * * pp ) ; and we pass to it & pOurPointer .
The function then * pp = some address ; initializes pOurPointer content .
Another way is like this: : func( int * & pr ) = pOurPointer ;
then pr = someaddress ; will initialize pOurPointer .
We can eliminate one level of showing a dereference * operator.
Someone might think it reads cleaner that way, inside of func()'s body.
The "logical" ! NOT( logical complement\logical inverter ) operator:
ALL integers have been conceptually grouped into just 2 sets:
setA 0 is { 0 }
setB ALL integers +- that are not 0 { 1,5,-2, etc. }
so:
0 is logical 0
1 is logical 1
5 is logical 1
-2 is logical 1
now "logically" inverting:
! 0 is 1
! 1 is 0
! 5 is 0
! -2 is 0