Re: typedefs and structs

[linas <linas@austin.ibm.com>]

On Wed, Nov 09, 2005 at 03:26:10PM -0500, linux-os (Dick Johnson) was heard to remark:
> 
> On Wed, 9 Nov 2005, linas wrote:
> 
> > On Wed, Nov 09, 2005 at 08:22:15AM -0800, Vadim Lobanov was heard to remark:
> >> On Wed, 9 Nov 2005, J.A. Magallon wrote:
> >>
> >>> void do_some_stuff(T& arg1,T&  arg2)
> >>
> >> A diligent C programmer would write this as follows:
> >> 	void do_some_stuff (struct T * a, struct T * b);
> >> So I don't see C++ winning at all here.
> >
> > I guess the real point that I'd wanted to make, and seems
> > to have gotten lost, was that by avoiding using pointers,
> > you end up designing code in a very different way, and you
> > can find out that often/usually, you don't need structs
> > filled with a zoo of pointers.
> 
> But you can't avoid pointers unless you make your entire
> program have global scope. 

I didn't say you can avoid all pointers. I did say that 
for many projects, one can often avoid many pointers.  
And I certainly did not say that one needs global scope 
to do so. In fact, I said the opposite. 

> Also, without pointers, you are severely limited on the kinds
> of libraries you can share. 

I think you don't understand what a reference is. 
A reference is just like a pointer, except that the 
signature is different.  It has nothing to do with the
ability to create or use libraries, or to create/use 
modular code.  

I was trying to say that by focusing on the concept
of a "reference" as opposed to the concept of a 
"pointer", you can write code that is *more* modular, 
not less.

> > Minimizing pointers is good: less ref counting is needed,
> > fewer mallocs are needed, fewer locks are needed
> > (because of local/private scope!!), and null pointer
> > deref errors are less likely.
> 
> No. Minimizing pointers should not be an objective. 

Why not?

I've fixed hundreds of kernel bugs (which you don't 
see on this list because my fixes mostly go to the 
distros or other users) and nine out of ten of these 
are null-pointer derefs. 

Maybe I'm naive for thinking that "fewer pointers == 
fewer pointer bugs" but, hey its worth a shot.

> Properly
> using the components of your tool-set should be. 

What tool set are you refering to?  I am assuming 
that the code is 100% malleable: that one has
complete authority to redesign the way the system 
works, from the ground up.  If you do not have this 
freedom, but are forced to use someone-else's tool set,
then yes, you are SOL.  Furthermore, I would agree 
that mixing two different styles of coding in one 
project can lead to some nasty, ugly code.

> > By using refs instead of pointers, it helps you focus
> > on the issue of "do I really need to store this pointer
> > somewhere? Will I really need it later, or can I be done
> > with it now?".
> 
> Huh? References (at the opcode level) are pointers. There
> is no difference whatsoever. 

Yes, that is right.  I'm not talking about opcodes.
That's not what the conversation is about.

What I am trying to say is that many people design 
code in such a way that they need to store lots of 
pointers in an assortment of structs.

I wanted to emphasize that there are other ways of
designing code, which has smaller needs for pointers
(and that this can be done without loosing modularity,
testability, debugability, and it can be done without 
resorting to global variables.)

--linas