Nodes with unlimited children.

[Jeff Relf]

Hi All,

I plan on using the following C++ code
to create nodes with unlimited children:

// I would like to declare NodeT like this,
// but it won't compile because Lnk_T is not defined yet.

struct NodeT { Lnk_T Lnk ; };

So I have to declare NodeT like this instead:

struct NodeT {
struct { NodeT * * B, * * E, * * Room ; } Lnk ; };


typedef NodeT * Link ;

typedef Link * Link_P ;

// B is the Beginning of an array of pointers.
// E is the End of an array of pointers that are in use.
// Room the end of an array of all pointers, used or not.

struct Lnk_T { Link_P B, E, Room ; };

Lnk_T Lnk ;

enum { Chunk = 4,
Sz_Ptr = sizeof Link, Sz_Node = sizeof NodeT };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link_P ) realloc( Lnk.B, Room * Sz_Ptr );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Ptr ); }


// Below is an example of is how the above might be used,
// I know that it works.

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

GrowList ( Lnk ); // Lnk is a global, so it's initialized.

Link & P = * Lnk.E ++ ;

P = ( Link ) realloc( P, Sz_Node );

memset ( P, 0, Sz_Node );

GrowList ( ( Lnk_T & ) P->Lnk );

{ Link Passed = P, & P = * Passed->Lnk.E ++ ;

P = ( Link ) realloc( P, Sz_Node );

memset ( P, 0, Sz_Node );

GrowList ( ( Lnk_T & ) P->Lnk );

// etc.
}

But is there any way to declare NodeT so that
I don't have to use that ( Lnk_T & ) cast ?

 

[Karl Heinz Buchegger]

Hi All,

I plan on using the following C++ code
to create nodes with unlimited children:

// I would like to declare NodeT like this,
// but it won't compile because Lnk_T is not defined yet.

struct NodeT { Lnk_T Lnk ; };

So I have to declare NodeT like this instead:

Start the whole thing with a forward declaration of NodeT. YOu
then can use NodeT pointers in the declaration of Lnk_T and can
use Lnk_T in the declaration of NodeT.

Like so:

struct NodeT;
struct Lnk_T { NodeT** B, **E, **Room; };
struct NodeT { Lnk_T Lnk; };

Your posted code then compiles without the cast.

BTW: I consider your formatting style horrible.

 

[Jumpin' Jehosephat]

Hi All,

I plan on using the following C++ code
to create nodes with unlimited children:

// I would like to declare NodeT like this,
// but it won't compile because Lnk_T is not defined yet.

struct NodeT { Lnk_T Lnk ; };

So I have to declare NodeT like this instead:

struct NodeT {
struct { NodeT * * B, * * E, * * Room ; } Lnk ; };


typedef NodeT * Link ;

typedef Link * Link_P ;

// B is the Beginning of an array of pointers.
// E is the End of an array of pointers that are in use.
// Room the end of an array of all pointers, used or not.

struct Lnk_T { Link_P B, E, Room ; };

Lnk_T Lnk ;

enum { Chunk = 4,
Sz_Ptr = sizeof Link, Sz_Node = sizeof NodeT };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link_P ) realloc( Lnk.B, Room * Sz_Ptr );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Ptr ); }


// Below is an example of is how the above might be used,
// I know that it works.

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

GrowList ( Lnk ); // Lnk is a global, so it's initialized.

Link & P = * Lnk.E ++ ;

P = ( Link ) realloc( P, Sz_Node );

memset ( P, 0, Sz_Node );

GrowList ( ( Lnk_T & ) P->Lnk );

{ Link Passed = P, & P = * Passed->Lnk.E ++ ;

P = ( Link ) realloc( P, Sz_Node );

memset ( P, 0, Sz_Node );

GrowList ( ( Lnk_T & ) P->Lnk );

// etc.
}

But is there any way to declare NodeT so that
I don't have to use that ( Lnk_T & ) cast ?

That doesn't sound type safe.

And modern computing demands type safety.

 

[General Protection Fault]

Hi All,

I plan on using the following C++ code
to create nodes with unlimited children:

// I would like to declare NodeT like this,
// but it won't compile because Lnk_T is not defined yet.

struct NodeT { Lnk_T Lnk ; };

So I have to declare NodeT like this instead:

struct NodeT {
struct { NodeT * * B, * * E, * * Room ; } Lnk ; };


typedef NodeT * Link ;

typedef Link * Link_P ;

// B is the Beginning of an array of pointers.
// E is the End of an array of pointers that are in use.
// Room the end of an array of all pointers, used or not.

struct Lnk_T { Link_P B, E, Room ; };

Lnk_T Lnk ;

enum { Chunk = 4,
Sz_Ptr = sizeof Link, Sz_Node = sizeof NodeT };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link_P ) realloc( Lnk.B, Room * Sz_Ptr );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Ptr ); }


// Below is an example of is how the above might be used,
// I know that it works.

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

GrowList ( Lnk ); // Lnk is a global, so it's initialized.

Link & P = * Lnk.E ++ ;

P = ( Link ) realloc( P, Sz_Node );

memset ( P, 0, Sz_Node );

GrowList ( ( Lnk_T & ) P->Lnk );

{ Link Passed = P, & P = * Passed->Lnk.E ++ ;

P = ( Link ) realloc( P, Sz_Node );

memset ( P, 0, Sz_Node );

GrowList ( ( Lnk_T & ) P->Lnk );

// etc.
}

But is there any way to declare NodeT so that
I don't have to use that ( Lnk_T & ) cast ?

Good lord, that's the worst code I've ever seen. I hope I don't ever
have to maintain something of yours.

It's considered polite, when incrementing a pointer value, to bracket to
explicity show what you're intending, i.e.
(*p)++ return the value at the pointer, then increment the value
*(p++) return the value at the pointer, then increment the pointer

Maybe I got those backwards. Which is why you really want to be explicit.

 

[Jeff Relf]

Karl Heinz Buchegger

Re: Nodes with unlimited children,

You wrote,
" Start the whole thing with a forward declaration of NodeT. "

Oh, how so very sweet, thank you much !

By the way,
I just realized that the code that I showed in my original
post was really designed for a NodeT of varying length,
which I don't think I really need.

So this is how it looks now ( and it works ),

struct NodeT ;

typedef NodeT * Link ;

// B is the Beginning of an array of NodeT's.
// E is the End of an array of NodeT's that are in use.
// Room the end of an array of all NodeT's, used or not.

struct Lnk_T { Link B, E, Room ; };

struct NodeT { Lnk_T Lnk ; };

Lnk_T Lnk ;

enum { Sz_Node = sizeof NodeT, Chunk_Lnk = 4 };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk_Lnk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link ) realloc( Lnk.B, Room * Sz_Node );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Node ); }

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

// Lnk is a global, so it's initialized.
// This creates a child for Lnk.
// There is no limit to the number of children.
GrowList ( Lnk );

// This creates a grandchild for Lnk.
GrowList ( ( * Lnk.E ++ ).Lnk );

// etc
}

You wrote,
" BTW: I consider your formatting style horrible. "

Everyone employs whitespace differently,
I even change my own style from time to time.

So I don't see how it's worth commenting on.

 

[Joe Gottman]

Hi All,

I plan on using the following C++ code
to create nodes with unlimited children:

<code snipped>

There's a clever way to get this effect with only two Node *'s per Node:

class Node
{
/* put data here */
Node *firstChild;
Node *nextSibling;
};

Then, to get all the children of a node, you just do
for (Node *child = myNode->firstChild; child != 0; child =
child->nextSibling) {
// whatever
}

This works great as long as you don't need constant-time access to the
nth child of a Node.

Joe Gottman

 

[Jeff Relf]

Hi General Protection Fault,

Re: Precedence vs. overused parentheses,
such as: ( * Lnk.E ++ ).Lnk in the following code,

struct NodeT ;

typedef NodeT * Link ;

// B is the Beginning of an array of NodeT's.
// E is the End of an array of NodeT's that are in use.
// Room the end of an array of all NodeT's, used or not.

struct Lnk_T { Link B, E, Room ; };

struct NodeT { Lnk_T Lnk ; };

Lnk_T Lnk ;

enum { Sz_Node = sizeof NodeT, Chunk_Lnk = 4 };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk_Lnk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link ) realloc( Lnk.B, Room * Sz_Node );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Node ); }

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

// Lnk is a global, so it's initialized.
// This creates a child for Lnk.
// There is no limit to the number of children.
GrowList ( Lnk );

// This creates a grandchild for Lnk.
GrowList ( ( * Lnk.E ++ ).Lnk );

// etc
}

If you're asking me,
it's much better to know the precedence of operators
than to overuse parentheses.

For example:
( * Lnk.E ++ ).Lnk is better than ( * ( Lnk.E ++ ) ).Lnk

But it's subjective, so why quibble ?

As for you maintaining my code,
I wouldn't worry about that if I were you.

Here is the order of precedence, highest first:
++ Post-increment, Left to right
-- Post-decrement
( ) Function call
[ ] Array element
-> Pointer to structure member
.. Structure or union member
++ Pre-increment, Right to left
-- Pre-decrement
! Logical NOT
~ Bitwise NOT
- Unary minus
+ Unary plus
& Address
* Indirection
sizeof Size in bytes
new Allocate program memory
delete Deallocate program memory
( type ) Type cast [ for example, ( float ) i ]
..* Pointer to member ( objects ), Left to right
->* Pointer to member ( pointers )
* Multiply, Left to right
/ Divide
% Remainder
+ Add, Left to right
- Subtract
<< Left shift, Left to right< Less than, Left to right
<= Less than or equal to

Greater than
= Greater than or equal to

== Equal, Left to right
!= Not equal
& Bitwise AND, Left to right
^ Bitwise exclusive OR, Left to right
| Bitwise OR, Left to right
&& Logical AND, Left to right
|| Logical OR, Left to right
? : Conditional, Right to left
= Assignment, Right to left
*=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |= Compound assignment
, Comma, Left to right

 

[International All-Star Cast]

Hi General Protection Fault,

Re: Precedence vs. overused parentheses,
such as: ( * Lnk.E ++ ).Lnk in the following code,

struct NodeT ;

What a bunch of boring bullshit.

Here's something more interesting. I was writing a c# service and that
created a file that would then be transferred somewhere else. Originally I
coded some meta-data in the file name, but then because that had specific
size requirements, I had to use something else. How about File Properties
( right click on a text file, and look at the Properties ( third ) tab. It
has stuff like Author, Title, Subject.

I figure those nice m$ people created a cool assembly that would let me
set/get those. Well there is a class with get methods but not set methods.
So, I had to use a COM object that M$ supplies called DFOfile.dll

Yeah, so, when you dig a little beneath the pretty surface of .NET -- it's
all COM.

typedef NodeT * Link ;

// B is the Beginning of an array of NodeT's.
// E is the End of an array of NodeT's that are in use.
// Room the end of an array of all NodeT's, used or not.

struct Lnk_T { Link B, E, Room ; };

struct NodeT { Lnk_T Lnk ; };

Lnk_T Lnk ;

enum { Sz_Node = sizeof NodeT, Chunk_Lnk = 4 };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk_Lnk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link ) realloc( Lnk.B, Room * Sz_Node );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Node ); }

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

// Lnk is a global, so it's initialized.
// This creates a child for Lnk.
// There is no limit to the number of children.
GrowList ( Lnk );

// This creates a grandchild for Lnk.
GrowList ( ( * Lnk.E ++ ).Lnk );

// etc
}

If you're asking me,
it's much better to know the precedence of operators
than to overuse parentheses.

For example:
( * Lnk.E ++ ).Lnk is better than ( * ( Lnk.E ++ ) ).Lnk

But it's subjective, so why quibble ?

As for you maintaining my code,
I wouldn't worry about that if I were you.

Here is the order of precedence, highest first:
++ Post-increment, Left to right
-- Post-decrement
( ) Function call
[ ] Array element
-> Pointer to structure member
. Structure or union member
++ Pre-increment, Right to left
-- Pre-decrement
! Logical NOT
~ Bitwise NOT
- Unary minus
+ Unary plus
& Address
* Indirection
sizeof Size in bytes
new Allocate program memory
delete Deallocate program memory
( type ) Type cast [ for example, ( float ) i ]
.* Pointer to member ( objects ), Left to right
->* Pointer to member ( pointers )
* Multiply, Left to right
/ Divide
% Remainder
+ Add, Left to right
- Subtract
<< Left shift, Left to right< Less than, Left to right
<= Less than or equal to

Greater than
= Greater than or equal to

== Equal, Left to right
!= Not equal
& Bitwise AND, Left to right
^ Bitwise exclusive OR, Left to right
| Bitwise OR, Left to right
&& Logical AND, Left to right
|| Logical OR, Left to right
? : Conditional, Right to left
= Assignment, Right to left
*=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |= Compound assignment
, Comma, Left to right

 

[Jeff Relf]

Oops, I should've said:

I prefer Lnk.E ++ -> Lnk over ( Lnk.E ++ ) -> Lnk

 

[Jeff Relf]

Hi Joe Gottman,

You showed something similar this:

class Node_Type {
Node * firstChild ;
Node * nextSibling ; };

for ( Node_Type * child = myNode->firstChild ;
child != 0 ;
child = child->nextSibling ) ...


For what I'm doing, I prefer my dynamic array of nodes.

such as: Lnk.E ++ -> Lnk ( defined below ),

That allows me to do things like: Lnk.B [ 4 ]
which directly references the fifth node.

My NodeT is very small and has a fixed size,
if NodeT was large or if it had a dynamic size
I'd use the code that I originally posted in this thread:

To loop though all the child nodes I define this:
( Lnk is a global, see below )

#define LoopChildren \
Link _Lnk = Lnk.B - 1 ; while ( ++ _Lnk < Lnk.E )

Which is then called like this:

LoopChildren _Lnk->Whatever ;

Here's how I declared those variables:

struct NodeT ;

typedef NodeT * Link ;

// B is the Beginning of an array of NodeT's.
// E is the End of an array of NodeT's that are in use.
// Room the end of an array of all NodeT's, used or not.

struct Lnk_T { Link B, E, Room ; };

struct NodeT { int Whatever ; Lnk_T Lnk ; };

Lnk_T Lnk ; // This is a global variable, so it's initialized.

enum { Sz_Node = sizeof NodeT, Chunk_Lnk = 4 };

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk_Lnk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link ) realloc( Lnk.B, Room * Sz_Node );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Node ); }

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

// This creates a child for Lnk.
// There is no limit to the number of children.
GrowList ( Lnk );

// This creates a grandchild for Lnk.
GrowList ( Lnk.E ++ -> Lnk );

// etc
}

 

[Jeff Relf]

Hi International All-Star Cast,

Win XP's File Properties is... well... specific to Win XP,
and therefore it can't be part of the main C# framework.

I'm sure that there is
plenty of C# code that only runs on Win XP.

To be sure that your C# code _ Shines _
on dual 64-bit PowerPCs as well as on some arcane cell phone,
you'd better damn well test it on all of those devices.

 

[Sargeant Vince Carter]

Hi International All-Star Cast,

Win XP's File Properties is... well... specific to Win XP,
and therefore it can't be part of the main C# framework.

I'm sure that there is
plenty of C# code that only runs on Win XP.

To be sure that your C# code _ Shines _
on dual 64-bit PowerPCs as well as on some arcane cell phone,
you'd better damn well test it on all of those devices.

Sure, sure, but it's a web service...so I could care less.

Yesterday, I wrote an synchronous Delegate ( what you overtrained c++ might
term a callback function ) so that my GUI web service consumer could do
work in the background.

It's very cool.

 

[Karl Heinz Buchegger]

You wrote,
" BTW: I consider your formatting style horrible. "

Everyone employs whitespace differently,
I even change my own style from time to time.

It's not only about whitespace.

Eg.

// B is the Beginning of an array of NodeT's.
// E is the End of an array of NodeT's that are in use.
// Room the end of an array of all NodeT's, used or not.

struct Lnk_T { Link B, E, Room ; };

Why do you need the comment? To describe what B, E and Room
are for. So then why not write it more verbose in the
first place:

struct Lnk_T { Link Beginn, End, Room ; };

Why everything on one line?

struct Lnk_T
{
Link Begin;
Link End;
Link Room;
};

Same for the code. Your code looks like one of the early
C programmers who thought that cramming as much as they can
into a single line is a good idea. It is not! Everybody
programming for years and having to maintain old code knows
this. One of the most important things in a code (besides
beeing correct) is maintainability.

Compare

GrowList ( Lnk_T & Lnk ) {
if ( Lnk.E + 1 < Lnk.Room ) return;
int Room = Lnk.Room - Lnk.B + Chunk_Lnk, E = Lnk.E - Lnk.B ;
Lnk.B = ( Link ) realloc( Lnk.B, Room * Sz_Node );
Lnk.Room = Lnk.B + Room ; Lnk.E = Lnk.B + E ;
memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Node ); }

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int ) {

// Lnk is a global, so it's initialized.
// This creates a child for Lnk.
// There is no limit to the number of children.
GrowList ( Lnk );

// This creates a grandchild for Lnk.
GrowList ( ( * Lnk.E ++ ).Lnk );

// etc
}

To

void GrowList ( Lnk_T & Lnk )
{
if ( Lnk.E + 1 < Lnk.Room )
return;

int Room = Lnk.Room - Lnk.B + Chunk_Lnk;
int E = Lnk.E - Lnk.B ;

Lnk.B = ( Link ) realloc( Lnk.B, Room * Sz_Node );
Lnk.Room = Lnk.B + Room ;
Lnk.E = Lnk.B + E ;

memset( Lnk.E, 0, ( Lnk.Room - Lnk.E ) * Sz_Node );
}

BTW what you do with pointers and int in the above is illegal.
I wonder why your compiler didn't barf on it.


__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int )
{

// Lnk is a global, so it's initialized.
// This creates a child for Lnk.
// There is no limit to the number of children.
GrowList ( Lnk );

// This creates a grandchild for Lnk.
GrowList ( ( * Lnk.E ++ ).Lnk );

// etc
}

In your code I didn't see where GrowList end and WinMain starts.
It took me reformatting to notice that I accidently copied not
only one function but two. And I didn't notice until I had the
whole thing in the newreader.

So I don't see how it's worth commenting on.

It is. Because at least in this group (clc++) we are used to
see problem request which can be traced back to simply bad
formatting. Reformatting and reindenting shows the error
quite clearly. So the regulars do this, reply with the
reformatted code and the OP sees his problem on his own.

Your code is the worst case I have seen for a long time.

Just because I notice it right now. You are also posting to
comp.os.linux.advocacy. Is this intended? Your code contains
__stdcall WinMain( ... )
which is clearly not a linux thing.

 

[Karl Heinz Buchegger]

BTW what you do with pointers and int in the above is illegal.
I wonder why your compiler didn't barf on it.

Forget that. It is legal.
My fault.

 

[Jeff Relf]

Hi Karl Heinz Buchegger,

You wrote, << ...in this group ( clc++ )
we are used to seeing problems/requests
which can be traced back to simply bad formatting.
Reformatting and reindenting shows the errors quite clearly.

So the regulars do this,
reply with the reformatted code
and the OP sees his problem on his own. >>

I'm of the opinion that one's choice of whitespace
and the names one chooses for the identifiers
is less important than just going over the code.

i.e. It helps to simply change the whitespace,
no matter how you change it.

For that very reason, I often change my style.

Besides, my original question was answered quickly by you
after you examined the first few lines of my post.
( And for that I thank you )

What style of code is more maintainable ?

I can't answer that question.

Re: struct Lnk_T { Link B, E, Room ; };

You suggested that
I would not need so many comment lines if I wrote it as:

struct Lnk_T
{
Link Begin;
Link End;
Link Room;
};

It's ironic that you would rename those 3 variables,
because after examining this code myself
I've decided to change them to: B, P, and E.

I much prefer the shorter names for often used pointers.

B is what I usually call the beginning of a buffer,
and E what I call the end of a buffer,
and P is what I call my working pointer.

So long as the scope is kept small, it works quite well.

Another change I made was to pre-increment P inside Inc(),
( the function that makes room for it )
so now P always points to the current Node.

Pre-incrementing is always my preference.

Using your preferred whitespace style ( kind of ),
my code now looks like this:

struct NodeT ;

typedef NodeT * Link ;

// B is the Beginning of an array of NodeT's.
// P is the Pointer to the NodeT in use.
// E is the End of an array NodeT's.
// Inc() increments P.

struct Lnk_T
{
Link B, P, E ;
};

struct NodeT
{
int Whatever ;
Lnk_T Lnk ;
};

Lnk_T Lnk ; // A global, so it's already initialized.

enum {
Sz_Node = sizeof NodeT
};

NodeT & Inc ( Lnk_T & Ln )
{
if ( Ln.E && ++ Ln.P < Ln.E )
return * Ln.P ;

int E = Ln.E - Ln.B + 4 ;
int P = Ln.P - Ln.B ;

Ln.B = ( Link ) realloc( Ln.B, E * Sz_Node );
Ln.E = Ln.B + E ;
Ln.P = Ln.B + P ;

memset( Ln.P, 0, ( Ln.E - Ln.P ) * Sz_Node );

return * Ln.P ;
}

// The - 1 below is so that I can pre-increment.

#define LoopChildren \
Link _Lnk = Lnk.B - 1 ; while ( ++ _Lnk < Lnk.P )

__stdcall WinMain( HINSTANCE, HINSTANCE, LPSTR, int )
{

// In the line below, the first call to Inc()
// creates one child for Lnk ( Lnk is a global )
// and returns it as a reference to Lnk.P
//
// That child is then is passed in a second call to InC(),
// thus creating a grandchild
// and returning a reference to Lnk.P->Lnk.P.
//
// There is no limit to the number of children per node.
//
// Afterwards Lnk.P->Lnk.P->Whatever
// is valid and is initialized to zero.

printf( "%d", Inc ( Inc ( Lnk ).Lnk )->Whatever );

// This prints all of Lnk's children.

LoopChildren printf( "%d", _Lnk->Whatever );

}


P.S.

I cross-posted to Comp.OS.Linux.Advocacy ( Cola )
because I'm only reading that group, not Comp.Lang.C++.

And yes, as my WinMain() hinted at,
I only program for Win XP.

I'm only in Cola because I have some friends there.

 

[Jeff Relf]

Oops, two errors,

It's printf( "%d", Inc ( Inc ( Lnk ).Lnk ).Whatever );
not printf( "%d", Inc ( Inc ( Lnk ).Lnk )->Whatever );

Because the each call to Inc()
returns it as a reference to * Lnk.P, not Lnk.P

 

[Karl Heinz Buchegger]

Hi Karl Heinz Buchegger,

You wrote, << ...in this group ( clc++ )
we are used to seeing problems/requests
which can be traced back to simply bad formatting.
Reformatting and reindenting shows the errors quite clearly.

So the regulars do this,
reply with the reformatted code
and the OP sees his problem on his own. >>

I'm of the opinion that one's choice of whitespace
and the names one chooses for the identifiers
is less important than just going over the code.

i.e. It helps to simply change the whitespace,
no matter how you change it.

For that very reason, I often change my style.

Besides, my original question was answered quickly by you
after you examined the first few lines of my post.

Quickly is good.
I had to cut&paste that mess into my editor and start
reindenting and reformatting to even have a chance to
figure out what is wrong and in which way it needs
to be changed

It's ironic that you would rename those 3 variables,
because after examining this code myself
I've decided to change them to: B, P, and E.

Which only proofs that it is possible to write Fortran
code in every language.
(Apologies to Fortran programmers. Although I didn't write
Fortran programs since 15 years any more, I know that
Fortran has evolved in this time.)

I cross-posted to Comp.OS.Linux.Advocacy ( Cola )
because I'm only reading that group, not Comp.Lang.C++.

Good reason

 

[Andrew Koenig]

Re: Precedence vs. overused parentheses,
such as: ( * Lnk.E ++ ).Lnk in the following code,

Um... the parentheses are necessary in this expression. If you were to
write

*Lnk.E++.Lnk

it would mean the same as

*((Lnk.E++).Lnk)

 

[Siemel Naran]

Why is this message crossposted to comp.os.linux.advocacy?

For example:
( * Lnk.E ++ ).Lnk is better than ( * ( Lnk.E ++ ) ).Lnk

Assuming I understand the intent of your code, my preference is

const LnkType& OldLnk = Lnk.E.Lnk;
++Lnk.E; // as opposed to the equivalent ++(Lnk.E)

Here is the order of precedence, highest first:
++ Post-increment, Left to right
-- Post-decrement
( ) Function call
[ ] Array element
-> Pointer to structure member
. Structure or union member
++ Pre-increment, Right to left
-- Pre-decrement
! Logical NOT
~ Bitwise NOT
- Unary minus
+ Unary plus
& Address
* Indirection
sizeof Size in bytes
new Allocate program memory
delete Deallocate program memory
( type ) Type cast [ for example, ( float ) i ]
.* Pointer to member ( objects ), Left to right
->* Pointer to member ( pointers )
* Multiply, Left to right
/ Divide
% Remainder
+ Add, Left to right
- Subtract
<< Left shift, Left to right< Less than, Left to right
<= Less than or equal to

Greater than
= Greater than or equal to

== Equal, Left to right
!= Not equal
& Bitwise AND, Left to right
^ Bitwise exclusive OR, Left to right
| Bitwise OR, Left to right
&& Logical AND, Left to right
|| Logical OR, Left to right
? : Conditional, Right to left
= Assignment, Right to left
*=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |= Compound assignment
, Comma, Left to right

The list is incorrect. The operators are grouped into boxes, and each
box has a higher priority than the one after it, but within each box
the operators have the same priority. For example, your list above
has + before -, which suggests that a-b+c is a-(b+c), but it is really
(a-b)+c. There's usually no difference when a, b, c are integers or
any type with the commutivity property, but if you have overloaded
operators you should see operator- called first, then
operator+. As an aside, consider overflow: a=UNIT_MAX, b=UNIT_MAX,
c=1, and a-b+c should be 1, but a-(b+c) is either an overflow
exception or UINT_MAX. I wonder if there are any examples to prove
that operators are grouped into boxes other than overloaded operators
and overflow/underflow considerations.

So instead of

+ Add, Left to right
- Subtract

I'd write either

+ Add, Left to right; - Subtract

or

Next Group/Box
+ Add, Left to right
- Subtract

 

[The Ghost In The Machine]

In comp.os.linux.advocacy, General Protection Fault
<[email protected]>
wrote

Good lord, that's the worst code I've ever seen. I hope I don't ever
have to maintain something of yours.

ObEgo: What about my code?

I posted a variant of an HTML colorizer some time ago
after JR posted code that was absolutely terrible (longer
than -- and worse than -- this stuff). With STL, it came
out rather clean, but Jeff apparently hasn't learned the
wonders of std::map yet.

I'm not sure the above actually *does* anything, either -- except
maintain a collection of Room objects, and a far simpler method
of doing that (if one does want a doubly-linked list) is to
simply declare

std::list<Room> roomList;

and use the STL manipulators, some of which can be quite sophisticated
(for_each() is one of the simpler algorithms; there's a fair number
of others):

struct RoomManipulator { operator()(Room & r) { ... } } manipo;
void manipf(Room & r);

std::for_each(roomList.begin(), roomList.end(), manipo);

or one can use the simpler

std::for_each(roomList.begin(), roomList.end(), manipf);

if one doesn't need to keep state.

Or one one can do it with an explicit iterator:

for(std::list<Room>::const_iterator i = roomList.begin();
i != roomList.end(); i++)
{
...
}

If one wants a list of Room *pointers* instead (there are some issues
that may require such), the declaration is simply changed to:

std::list<Room *> roomPointerList;

and the code suitably modified -- although ideally it wouldn't
make that much difference.

Or one can declare a templated "smart pointer" class:

std::list<std::auto_ptr<Room> > roomPointerList

Unfortunately std::auto_ptr<> isn't the brightest of resource
managers. I wrote my own long ago, but it's a bit klunky
as it requires friend access in order to properly manage
the usecount (one per object).

If one doesn't like lists, one can use various other
collection forms: std::set and std::hashset if one wants
a sorted collection, and std::vector if one wants to keep
things contiguous in memory (although the block of memory
may in fact move). std::vector might be a good replacement
for some of Jeff's code here. The aforementioned std::map
might be useful if one needs namevalue pairs; std::hashmap
might be slightly faster if one doesn't need the pairs
sorted in any recognizable order.

I'm not sure how efficient STL is (although a lot of the
implementation is inline), but it's one of the more elegant
constructs I've come across. Admittedly, though, some of
the implementation details can get a bit on the grody side.

It's considered polite, when incrementing a pointer value, to bracket to
explicity show what you're intending, i.e.
(*p)++ return the value at the pointer, then increment
the value
*(p++) return the value at the pointer, then increment the pointer

Maybe I got those backwards. Which is why you really want to be explicit.

The C/C++ spec does define the precedence of '*' versus '++' but I for
one can't remember which binds more tightly, and I'm probably not alone.