Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15856 > unrolled thread

Tree implementation, ideas for keyboard input method needed

Back to article view | Back to comp.lang.c

Contents

  Tree implementation, ideas for keyboard input method needed Bubba <nickname@banelli.biz.invalid> - 2012-01-16 22:01 +0000
    Re: Tree implementation, ideas for keyboard input method needed Keith Thompson <kst-u@mib.org> - 2012-01-16 14:27 -0800
      Re: Tree implementation, ideas for keyboard input method needed Bubba <nickname@banelli.biz.invalid> - 2012-01-16 22:36 +0000
        Re: Tree implementation, ideas for keyboard input method needed Kaz Kylheku <kaz@kylheku.com> - 2012-01-16 22:53 +0000
        Re: Tree implementation, ideas for keyboard input method needed James Kuyper <jameskuyper@verizon.net> - 2012-01-16 18:06 -0500
        Re: Tree implementation, ideas for keyboard input method needed Keith Thompson <kst-u@mib.org> - 2012-01-16 16:41 -0800
      Re: Tree implementation, ideas for keyboard input method needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-16 23:01 +0000
        Re: Tree implementation, ideas for keyboard input method needed Shao Miller <sha0.miller@gmail.com> - 2012-01-16 19:49 -0500
          Re: Tree implementation, ideas for keyboard input method needed Keith Thompson <kst-u@mib.org> - 2012-01-16 17:46 -0800
    Re: Tree implementation, ideas for keyboard input method needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-16 22:29 +0000
      Re: Tree implementation, ideas for keyboard input method needed Bubba <nickname@banelli.biz.invalid> - 2012-01-16 22:38 +0000
      Re: Tree implementation, ideas for keyboard input method needed William Ahern <william@wilbur.25thandClement.com> - 2012-01-16 15:30 -0800
        Re: Tree implementation, ideas for keyboard input method needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-17 00:03 +0000
        Re: Tree implementation, ideas for keyboard input method needed Keith Thompson <kst-u@mib.org> - 2012-01-16 16:35 -0800
          Re: Tree implementation, ideas for keyboard input method needed cri@tiac.net (Richard Harter) - 2012-01-17 02:00 +0000
            Re: Tree implementation, ideas for keyboard input method needed Keith Thompson <kst-u@mib.org> - 2012-01-16 19:16 -0800
              Re: Tree implementation, ideas for keyboard input method needed cri@tiac.net (Richard Harter) - 2012-01-17 05:15 +0000
                Re: Tree implementation, ideas for keyboard input method needed Keith Thompson <kst-u@mib.org> - 2012-01-17 00:00 -0800
            Re: Tree implementation, ideas for keyboard input method needed Kaz Kylheku <kaz@kylheku.com> - 2012-01-17 04:04 +0000
    Re: Tree implementation, ideas for keyboard input method needed Kaz Kylheku <kaz@kylheku.com> - 2012-01-16 22:44 +0000
    Re: Tree implementation, ideas for keyboard input method needed Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-16 17:58 -0500
    Re: Tree implementation, ideas for keyboard input method needed ImpalerCore <jadill33@gmail.com> - 2012-01-16 19:36 -0800
      Re: Tree implementation, ideas for keyboard input method needed Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-16 23:33 -0500
        Re: Tree implementation, ideas for keyboard input method needed ImpalerCore <jadill33@gmail.com> - 2012-01-17 07:18 -0800
      Re: Tree implementation, ideas for keyboard input method needed "BartC" <bc@freeuk.com> - 2012-01-17 13:54 +0000
        Re: Tree implementation, ideas for keyboard input method needed ImpalerCore <jadill33@gmail.com> - 2012-01-17 07:39 -0800
      Re: Tree implementation, ideas for keyboard input method needed Kaz Kylheku <kaz@kylheku.com> - 2012-01-17 19:01 +0000
    Re: Tree implementation, ideas for keyboard input method needed jgk@panix.com (Joe keane) - 2012-01-18 21:21 +0000

Page 1 of 2  [1] 2  Next page →

#15856 — Tree implementation, ideas for keyboard input method needed

Greetings,

nodes of my ordered tree are implemented like this:

    typedef struct __celltype {
          labeltype label;
          struct __celltype *first_child;
          struct __celltype *next_sib;
          struct __celltype *last_child;
          int zadnji;
    } celltype;
    typedef celltype *node;
    typedef celltype *TREE;

where first_child points to first sibling of the node, next_sib points to 
next sibling and last_child points to last sibling in the node. Data 
zadnji is true if the node is last child of any other node.

Labeltype is char.

Here's the whole implementation:

#include <stdlib.h>
#include <stdio.h>
#define LAMBDA NULL
#define labeltype char

typedef struct __celltype {
          labeltype label;
          struct __celltype *first_child;
          struct __celltype *next_sib;
          struct __celltype *last_child;
          int zadnji; /*last*/
    } celltype;
    
typedef celltype *node;
typedef celltype *TREE;

node MAKE_ROOT(labeltype l, TREE *T) {
     if (!(*T = (celltype*) malloc(sizeof(celltype)))) {
    printf("Nema dovoljno memorije.");
    exit(1);
  }
     (*T)->label=l;
     (*T)->first_child=NULL;
     (*T)->next_sib=NULL;
     (*T)->last_child=NULL;
     (*T)->zadnji=0;
     return *T;
     }
     
node INSERT_CHILD(labeltype l, node i, TREE *T){
     node temp;
       if (!i) {
    printf("Nema tog cvora.");
    exit(1);
  }
  if (!(i->first_child= (celltype*) malloc(sizeof(celltype)))) {
    printf("Nema dovoljno memorije.");
    exit(1);
  }     
  if (i->first_child==NULL)  {
      i->first_child->label=l;
      i->first_child->first_child=NULL;
      i->first_child->next_sib=NULL;
      i->first_child->last_child=NULL;
      i->first_child->zadnji=1;
      }
    if (i->first_child!=NULL)  {    
      temp=i->first_child;
      i->first_child->label=l;   
      i->first_child->first_child=NULL;
      i->first_child->next_sib=temp;
      i->first_child->last_child=NULL;
      i->first_child->zadnji=0;
      }
      return i->first_child;
}

node ROOT(TREE T){
     return T;
     }

node INSERT_SIBLING(labeltype l, node i, TREE *T){
     node temp;
       if (!i) {
    printf("Nema tog cvora.");
    exit(1);
  }
  if (!(i->next_sib= (celltype*) malloc(sizeof(celltype)))) {
    printf("Nema dovoljno memorije.");
    exit(1);
  } 
  if (i==ROOT(*T)) {
             printf("Taj cvor je korijen.");
    exit(1);
  }     
  if(i->zadnji==1){
     i->zadnji=0;
     i->next_sib->label=l;
     i->next_sib->first_child=NULL;
     i->next_sib->next_sib=NULL;
     i->next_sib->last_child=NULL;
     i->next_sib->zadnji=1;
     }
    if(i->zadnji==0){
      temp=i->next_sib;
      i->next_sib->label=l;
     i->next_sib->first_child=NULL;
     i->next_sib->next_sib=temp;
     i->next_sib->last_child=NULL;
     i->next_sib->zadnji=0;
     }  
     return i->next_sib;
     }
     
node PARENT(node i,TREE T){
       node c, d;
       if (i==ROOT(T)) return LAMBDA;
       if (!i) {
	   printf("Nema tog cvora.");
		exit(1);
		}
       for (c=T->first_child; c!=NULL; c=c->next_sib)
       if (c==i) return T;
       for (c=T->first_child; c!=NULL; c=c->next_sib){
	   d=PARENT(i,c);
		if (d!=NULL) return d;
	}
return NULL;
}

void DELETE(node i, TREE *T) {
     node c,d,e,f,temp;
    if (i==ROOT(*T)) {
    printf("Taj cvor je korijen."); /*is root*/
    exit(1);
    }
	if (!i) {
    printf("Nema tog cvora."); /*no node*/
    exit(1);
  }
  if (i->first_child!=NULL) {
    printf("Taj cvor ima djece."); /*has sib*/
    exit(1);
 }
 c=PARENT(i,*T);
 if (c->first_child==c->last_child) {
     free(i);
     c->first_child=NULL;
     c->last_child=NULL;
     }
 if (i==c->first_child) {
     temp=i->next_sib;
     free(i);
     c->first_child=temp;
     }
  if(i==c->last_child) {
      d=c->first_child;                 
     while(d!=c->last_child) {
        if (d->next_sib==i) {
          d->next_sib=NULL;
          d->zadnji=1;
          break;
          }
    d=d->next_sib;
  }
  free(i);
  c->last_child=d;
  }
if ((i!=c->first_child)  && (i!=c->last_child)){
   
    for (d=c->first_child; d!=NULL; d=d->next_sib){
        if(d->next_sib==i) e=d;
        if(i->next_sib==d) f=d;
        }
   free(i);
   e->next_sib=f;
  }        
}

node FIRST_CHILD(node i, TREE T){
     if (i->first_child==NULL) return NULL;
     if (!i) {
    printf("Nema tog cvora.");
    exit(1);
  }         
  return i->first_child;
}

node NEXT_SIBLING(node i, TREE T){
     if (i->next_sib==NULL) return NULL;
     if (!i) {
    printf("Nema tog cvora.");
    exit(1);
  }         
  return i->next_sib;
}

labeltype LABEL(node i, TREE T) {
   if (!i) {
    printf("Nema tog cvora.");
    exit(1);
  }     
  return i->label;
}

void CHANGE_LABEL(labeltype l, node i, TREE *T){
       if (!i) {
    printf("Nema tog cvora.");
    exit(1);
  }       
  i->label=l;
}     
             
void POSTORDER(node i, TREE T) {
     node c;
     for(c=FIRST_CHILD(i,T); c!=LAMBDA; c=NEXT_SIBLING(c,T))
       POSTORDER(c,T);
    printf("%c ", LABEL(i,T));
}                   
                       

int main(void)
{
     return 0; 
} 



Now I need a sane way to input a tree from keyboard. What would be the 
easiest one?

Thanks in advance!

-- 
"If you lie to the compiler,
it will get its revenge."
Henry Spencer
2.718281828459045235360287471352662497757247093699959574966967627.com

[toc] | [next] | [standalone]

#15858

Bubba <nickname@banelli.biz.invalid> writes:

Just so you know, I'm not going to address your actual question, at
least for now.  I do have some comments on your coding style.

> nodes of my ordered tree are implemented like this:
>
>     typedef struct __celltype {
>           labeltype label;
>           struct __celltype *first_child;
>           struct __celltype *next_sib;
>           struct __celltype *last_child;
>           int zadnji;
>     } celltype;

Identifiers starting with underscores are reserved to the implementation
in most contexts.  Identifiers starting with two underscores are
reserved in all contexts.  You should never define such identifiers
yourself (unless you're writing code for a C compiler or library
implementation).

It's not necessary to use a typedef for a struct type.  You could just
declare it as:

    struct celltype {
        ...
    };

and simply refer to it as "struct celltype".  If you feel the need to
have a one-word name for the type, there's no need to use different
identifiers for the tag and typedef:

    typedef struct celltype {
        ...
    } celltype;

>     typedef celltype *node;
>     typedef celltype *TREE;

Typedefs for pointer types are generally a bad idea.  The problem is
that they hide the fact that the type is a pointer.  That's ok if it's a
truly opaque type, meaning that client code will not use any pointer
operations on it.

And logically, a pointer to a "celltype" isn't a node; it points to a node.

[...]
> node MAKE_ROOT(labeltype l, TREE *T) {

All-caps names are conventionally used for macros.  It's better style
to call the function "make_root".

And in fact I'd declare this as:

    struct celltype *make_root(labeltype label, struct celltype **t);

Note that "l" is a poor identifier; it's too easily confused with the
digit "1".

>      if (!(*T = (celltype*) malloc(sizeof(celltype)))) {

The cast is unnecessary, and could be harmful (in certain circumstances,
it can inhibit important warnings).  malloc() returns a void* result,
which can be implicitly converted to any pointer type (other than a
pointer-to-function type).

A good idiom is:

    if ((*T = malloc(sizeof **T) != NULL) {

>     printf("Nema dovoljno memorije.");

Error mesages should be printed to stderr and terminated with "\n".

>     exit(1);

exit(1) doesn't necessarily indicate failure.  Use exit(EXIT_FAILURE)
instead.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15860

Keith Thompson's log on stardate 16 sij 2012

I hoped for something like this in the first place, so thank you in 
advance!

> Identifiers starting with underscores are reserved to the
> implementation in most contexts.  Identifiers starting with two
> underscores are reserved in all contexts.  You should never define
> such identifiers yourself (unless you're writing code for a C
> compiler or library implementation).

What are the repercussions of choosing wrong number of underscores? :)

>> node MAKE_ROOT(labeltype l, TREE *T) {
> 
> All-caps names are conventionally used for macros.  It's better style
> to call the function "make_root".

I'm aware of that, thanks, it will be corrected.

> And in fact I'd declare this as:
>     struct celltype *make_root(labeltype label, struct celltype **t);

Could you please clarify the need for double pointer?

> Note that "l" is a poor identifier; it's too easily confused with the
> digit "1".

True again!

>>      if (!(*T = (celltype*) malloc(sizeof(celltype)))) {
> The cast is unnecessary, and could be harmful (in certain
> circumstances, it can inhibit important warnings).  malloc() returns
> a void* result, which can be implicitly converted to any pointer type
> (other than a pointer-to-function type).

I read some posts here about malloc's (non)casting. I'll do as you 
suggested.

> A good idiom is:
>     if ((*T = malloc(sizeof **T) != NULL) {

Ok.

>>     printf("Nema dovoljno memorije.");
> Error mesages should be printed to stderr and terminated with "\n".
>>     exit(1);
> exit(1) doesn't necessarily indicate failure.  Use exit(EXIT_FAILURE)
> instead.

Thanks, I'll apply those too!

-- 
"If you lie to the compiler,
it will get its revenge."
Henry Spencer
2.718281828459045235360287471352662497757247093699959574966967627.com

[toc] | [prev] | [next] | [standalone]

#15863

On 2012-01-16, Bubba <nickname@banelli.biz.invalid> wrote:
> Keith Thompson's log on stardate 16 sij 2012
>
> I hoped for something like this in the first place, so thank you in 
> advance!
>
>> Identifiers starting with underscores are reserved to the
>> implementation in most contexts.  Identifiers starting with two
>> underscores are reserved in all contexts.  You should never define
>> such identifiers yourself (unless you're writing code for a C
>> compiler or library implementation).
>
> What are the repercussions of choosing wrong number of underscores? :)

The repercussions are that any of your compiler or library headers are
completely free to have things like this in them:

  #define __celltype blorch[

This namespace does not belong to you, but to the implementors. 

(Since C doesn't have namespaces, we have to draw these borders within the
identifiers themselves.)

Even if you haven no clash now with __celltype, you could have one tomorrow,
when you include some header that you did not previously include, port your
program to a different system, or upgrade (or downgrade) to a different version
of the compiler or any of your libraries, etc.

[toc] | [prev] | [next] | [standalone]

#15866

On 01/16/2012 05:36 PM, Bubba wrote:
> Keith Thompson's log on stardate 16 sij 2012
> 
> I hoped for something like this in the first place, so thank you in 
> advance!
> 
>> Identifiers starting with underscores are reserved to the
>> implementation in most contexts.  Identifiers starting with two
>> underscores are reserved in all contexts.  You should never define
>> such identifiers yourself (unless you're writing code for a C
>> compiler or library implementation).
> 
> What are the repercussions of choosing wrong number of underscores? :)

Theoretically: the behavior of your program is undefined. This means
that the C standard places no restrictions on the behavior of the
resulting program. That's a bad thing, if there's any particular
behavior you want your program to have, since it might not have that
behavior. It's an even worse thing if there are any things your program
could do that you don't want it to do (such as erasing all of your
files), because there's a chance that it might do one of those things.

Practically: identifiers are reserved to the implementation, so they can
by used by the implementation for it's own purpose, without worrying
about the possibility that user code might interfere. Consider what
could go wrong with your program if __celltype is defined by the
implementation, inside stdlib.h, for some purpose. The best possible
outcome is that the compiler will notice two different conflicting
definitions for __celltype, and complain. The worst possibility is that
__celltype is defined in some way that produces no warning messages when
you misuse it.

>> And in fact I'd declare this as:
>>     struct celltype *make_root(labeltype label, struct celltype **t);
> 
> Could you please clarify the need for double pointer?

Please don't refer to that as a "double pointer". It's a pointer to a
pointer. a "double pointer" could be interpreted as referring to a
"double*".

I'll let Keith answer the rest of your question in more detail, since
it's his suggestion.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#15870

Bubba <nickname@banelli.biz.invalid> writes:
> Keith Thompson's log on stardate 16 sij 2012
> I hoped for something like this in the first place, so thank you in 
> advance!
>
>> Identifiers starting with underscores are reserved to the
>> implementation in most contexts.  Identifiers starting with two
>> underscores are reserved in all contexts.  You should never define
>> such identifiers yourself (unless you're writing code for a C
>> compiler or library implementation).
>
> What are the repercussions of choosing wrong number of underscores? :)

Undefined behavior.

If you're *lucky*, you'll happen to collide with an
implementation-defined identifier and your code will fail to compile.

If you're *unlucky*, your program works as you intended it to work, or
it will fail in subtle ways that are difficult to find.

The compiler and/or standard runtime library can do anything they like
with identifiers that start with "__", and nearly anything they like
with identifiers that start with a single underscore.  If you define
such an identifier yourself, it may or may not conflict with a
system-defined identifier.

So don't do that.

[...]

>> And in fact I'd declare this as:
>>     struct celltype *make_root(labeltype label, struct celltype **t);
>
> Could you please clarify the need for double pointer?

A "double pointer" could be either a pointer to a pointer, or a pointer
to type "double".  It's better to refer to it as a pointer-to-pointer.

Why a pointer to a pointer?  Don't ask me, it's your code; you declared
it with a pointer-to-pointer yourself.  All I did was replace the
typedef (which hides the fact that the type is a pointer) with its full
definition.

But in general, if you want a function to modify something of type foo,
you need to pass it a foo*.  In this case, "foo" happens to be a pointer
type itself.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15865

Keith Thompson <kst-u@mib.org> writes:
<snip>
> A good idiom is:
>
>     if ((*T = malloc(sizeof **T) != NULL) {

There's a missing ')' of course:

     if ((*T = malloc(sizeof **T)) != NULL) {

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15871

On 1/16/2012 18:01, Ben Bacarisse wrote:
> Keith Thompson<kst-u@mib.org>  writes:
> <snip>
>> A good idiom is:
>>
>>      if ((*T = malloc(sizeof **T) != NULL) {
>
> There's a missing ')' of course:
>
>       if ((*T = malloc(sizeof **T)) != NULL) {
>
> <snip>

And change the '!=' to '=='.  - Shao

[toc] | [prev] | [next] | [standalone]

#15872

Shao Miller <sha0.miller@gmail.com> writes:
> On 1/16/2012 18:01, Ben Bacarisse wrote:
>> Keith Thompson<kst-u@mib.org>  writes:
>> <snip>
>>> A good idiom is:
>>>
>>>      if ((*T = malloc(sizeof **T) != NULL) {
>>
>> There's a missing ')' of course:
>>
>>       if ((*T = malloc(sizeof **T)) != NULL) {
>>
>> <snip>
>
> And change the '!=' to '=='.  - Shao

Quite right, thanks.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15859

Bubba <nickname@banelli.biz.invalid> writes:

> Greetings,
>
> nodes of my ordered tree are implemented like this:
>
>     typedef struct __celltype {

__celltype is a reserved name.  celltype__ would be fine but then so
would celltype.

>           labeltype label;
>           struct __celltype *first_child;
>           struct __celltype *next_sib;
>           struct __celltype *last_child;
>           int zadnji;
>     } celltype;
>     typedef celltype *node;
>     typedef celltype *TREE;
>
> where first_child points to first sibling of the node, next_sib points to 
> next sibling and last_child points to last sibling in the node. Data 
> zadnji is true if the node is last child of any other node.
>
> Labeltype is char.
>
> Here's the whole implementation:
>
> #include <stdlib.h>
> #include <stdio.h>
> #define LAMBDA NULL
> #define labeltype char
>
> typedef struct __celltype {
>           labeltype label;
>           struct __celltype *first_child;
>           struct __celltype *next_sib;
>           struct __celltype *last_child;
>           int zadnji; /*last*/
>     } celltype;
>     
> typedef celltype *node;
> typedef celltype *TREE;
>
> node MAKE_ROOT(labeltype l, TREE *T) {
>      if (!(*T = (celltype*) malloc(sizeof(celltype)))) {

What's the cast for?  I'd write:

  if ((*T = malloc(sizeof **T)) == NULL)

That way you know, at first glance, that the size is correct.

>     printf("Nema dovoljno memorije.");
>     exit(1);
>   }

This code (allocate or fail with a message) is repeated lots of times.
Is a clear candidate for being a function.

>      (*T)->label=l;
>      (*T)->first_child=NULL;
>      (*T)->next_sib=NULL;
>      (*T)->last_child=NULL;
>      (*T)->zadnji=0;
>      return *T;
>      }
>      
> node INSERT_CHILD(labeltype l, node i, TREE *T){

You are using an uncommon naming convention (uppercase function names)
and unusual layout.  Is there are a reason for this?

>      node temp;
>        if (!i) {
>     printf("Nema tog cvora.");
>     exit(1);
>   }
>   if (!(i->first_child= (celltype*) malloc(sizeof(celltype)))) {
>     printf("Nema dovoljno memorije.");
>     exit(1);
>   }     
>   if (i->first_child==NULL)  {
>       i->first_child->label=l;

This is obviously wrong.  If i->first_child == NULL, you can't talk
about i->first_child->label.

>       i->first_child->first_child=NULL;
>       i->first_child->next_sib=NULL;
>       i->first_child->last_child=NULL;
>       i->first_child->zadnji=1;
>       }
>     if (i->first_child!=NULL)  {    

"else"?

>       temp=i->first_child;
>       i->first_child->label=l;   
>       i->first_child->first_child=NULL;
>       i->first_child->next_sib=temp;
>       i->first_child->last_child=NULL;
>       i->first_child->zadnji=0;
>       }
>       return i->first_child;
> }

The lack of spaces and the confusion caused by using tabs is making this
hard to read so I'll stop here.

<snip code>

> Now I need a sane way to input a tree from keyboard. What would be the 
> easiest one?

I'd use parentheses:

  (a b c)
  (a (x (u v) z))

If you need to indicate "next_sib", use some
marker character:

  (a b* c)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15861

Ben Bacarisse's log on stardate 16 sij 2012

> The lack of spaces and the confusion caused by using tabs is making this
> hard to read so I'll stop here.

Wow, this went wrong - I agree; I'll procede as you Keith suggested and 
report back with sorted out code!

Thanks!

-- 
"If you lie to the compiler,
it will get its revenge."
Henry Spencer
2.718281828459045235360287471352662497757247093699959574966967627.com

[toc] | [prev] | [next] | [standalone]

#15867

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Bubba <nickname@banelli.biz.invalid> writes:
<snip>
> >       temp=i->first_child;
> >       i->first_child->label=l;   
> >       i->first_child->first_child=NULL;
> >       i->first_child->next_sib=temp;
> >       i->first_child->last_child=NULL;
> >       i->first_child->zadnji=0;
> >       }
> >       return i->first_child;
> > }

> The lack of spaces and the confusion caused by using tabs is making this
> hard to read so I'll stop here.

You mean confusion caused by *not* using tabs, or by software trying to
convert perfectly fine tabs to spaces and--not surprisingly--fscking the
indentation?

Tabs for indentation, spaces for alignment. Almost every editor gets this
right by default. It's takes a concerted effort to screw it up. (I'm not
laying blame on anyone in particular here. I'm presuming it's the OP's
client software that is causing the problem.)

[toc] | [prev] | [next] | [standalone]

#15868

William Ahern <william@wilbur.25thandClement.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Bubba <nickname@banelli.biz.invalid> writes:
> <snip>
>> >       temp=i->first_child;
>> >       i->first_child->label=l;   
>> >       i->first_child->first_child=NULL;
>> >       i->first_child->next_sib=temp;
>> >       i->first_child->last_child=NULL;
>> >       i->first_child->zadnji=0;
>> >       }
>> >       return i->first_child;
>> > }
>
>> The lack of spaces and the confusion caused by using tabs is making this
>> hard to read so I'll stop here.
>
> You mean confusion caused by *not* using tabs, or by software trying to
> convert perfectly fine tabs to spaces and--not surprisingly--fscking the
> indentation?

By "using" I meant "posting with".  Tabs in a post are unlikely to look
the same as tabs in a code editor.  I made the remark when I was looking
at some code that had tabs, though I see there are some lines that looks
odd and have no tabs (in the post).

> Tabs for indentation, spaces for alignment. Almost every editor gets this
> right by default. It's takes a concerted effort to screw it up. (I'm not
> laying blame on anyone in particular here. I'm presuming it's the OP's
> client software that is causing the problem.)

We are probably in agreement.  I don't care what the editor uses for the
code, but once tabs get into a post, you've almost always lost.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15869

William Ahern <william@wilbur.25thandClement.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Bubba <nickname@banelli.biz.invalid> writes:
> <snip>
>> >       temp=i->first_child;
>> >       i->first_child->label=l;   
>> >       i->first_child->first_child=NULL;
>> >       i->first_child->next_sib=temp;
>> >       i->first_child->last_child=NULL;
>> >       i->first_child->zadnji=0;
>> >       }
>> >       return i->first_child;
>> > }
>
>> The lack of spaces and the confusion caused by using tabs is making this
>> hard to read so I'll stop here.
>
> You mean confusion caused by *not* using tabs, or by software trying to
> convert perfectly fine tabs to spaces and--not surprisingly--fscking the
> indentation?

No, I'm fairly sure he means confusion caused by using tabs.

> Tabs for indentation, spaces for alignment. Almost every editor gets this
> right by default. It's takes a concerted effort to screw it up. (I'm not
> laying blame on anyone in particular here. I'm presuming it's the OP's
> client software that is causing the problem.)

I've worked on far too much code that has a random mixture of tabs
and spaces, with a tab representing a variable number of columns,
depending on who modified a particular line of code most recently.
My personal solution to the problem is to use spaces exclusively
for indentation -- and that was part of the coding standard at my
most recent job.  (If I worked in environment that required the
exclusive use of tabs for indentation, of course I'd use tabs.)

I'm not going to argue that you should follow my convention, but
you should be aware that there are perfectly legitimate reasons
for using spaces, even if you don't agree with them; people who use
spaces rather than tabs aren't necessarily doing so out of ignorance.

And tabs can cause serious formatting problems when posting to
Usenet, because there's news software that doesn't handle them
correctly.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15873

On Mon, 16 Jan 2012 16:35:48 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>William Ahern <william@wilbur.25thandClement.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Bubba <nickname@banelli.biz.invalid> writes:
>> <snip>
>>> >       temp=i->first_child;
>>> >       i->first_child->label=l;   
>>> >       i->first_child->first_child=NULL;
>>> >       i->first_child->next_sib=temp;
>>> >       i->first_child->last_child=NULL;
>>> >       i->first_child->zadnji=0;
>>> >       }
>>> >       return i->first_child;
>>> > }
>>
>>> The lack of spaces and the confusion caused by using tabs is making this
>>> hard to read so I'll stop here.
>>
>> You mean confusion caused by *not* using tabs, or by software trying to
>> convert perfectly fine tabs to spaces and--not surprisingly--fscking the
>> indentation?
>
>No, I'm fairly sure he means confusion caused by using tabs.
>
>> Tabs for indentation, spaces for alignment. Almost every editor gets this
>> right by default. It's takes a concerted effort to screw it up. (I'm not
>> laying blame on anyone in particular here. I'm presuming it's the OP's
>> client software that is causing the problem.)
>
>I've worked on far too much code that has a random mixture of tabs
>and spaces, with a tab representing a variable number of columns,
>depending on who modified a particular line of code most recently.
>My personal solution to the problem is to use spaces exclusively
>for indentation -- and that was part of the coding standard at my
>most recent job.  (If I worked in environment that required the
>exclusive use of tabs for indentation, of course I'd use tabs.)
>
>I'm not going to argue that you should follow my convention, but
>you should be aware that there are perfectly legitimate reasons
>for using spaces, even if you don't agree with them; people who use
>spaces rather than tabs aren't necessarily doing so out of ignorance.
>
>And tabs can cause serious formatting problems when posting to
>Usenet, because there's news software that doesn't handle them
>correctly.

And if you have a friendly editor it will convert tabs to spaces and
vice versa just as you desire.

[toc] | [prev] | [next] | [standalone]

#15875

cri@tiac.net (Richard Harter) writes:
> On Mon, 16 Jan 2012 16:35:48 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
[...]
> And if you have a friendly editor it will convert tabs to spaces and
> vice versa just as you desire.

But not very well if different past maintainers had different ideas of
where the tabstops should be.  For example, one section of code might
assume 2-column tabstops, and another might assume 4-column or 8-column
tabstops.

Which is ok if tabs (and only tabs) are used exclusively for
indentation, but not if both sections have a mix of tabs and spaces.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15879

On Mon, 16 Jan 2012 19:16:10 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>cri@tiac.net (Richard Harter) writes:
>> On Mon, 16 Jan 2012 16:35:48 -0800, Keith Thompson <kst-u@mib.org>
>> wrote:
>[...]
>> And if you have a friendly editor it will convert tabs to spaces and
>> vice versa just as you desire.
>
>But not very well if different past maintainers had different ideas of
>where the tabstops should be.  For example, one section of code might
>assume 2-column tabstops, and another might assume 4-column or 8-column
>tabstops.

Within a single file?  And your editor displays them all correctly?
How remarkable.
>
>Which is ok if tabs (and only tabs) are used exclusively for
>indentation, but not if both sections have a mix of tabs and spaces.

I don't you caught what I had in mind.  If your editor has the option
of automatically converting tabs into spaces you can use tabs with the
settings you prefer, get the indentation that floats your boat, and
still have a tab free file.  I keep all of my code in tab free format
(except for makefiles - boo, hiss).  If your editor can go the other
way, i.e., convert those pesky spaces into tabs, you can deal with
files that historically have tabs that you want to keep that way.
Just convert tabs to spaces, edit, and convert back from spaces to
tabs.

   

[toc] | [prev] | [next] | [standalone]

#15880

cri@tiac.net (Richard Harter) writes:
> On Mon, 16 Jan 2012 19:16:10 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>>cri@tiac.net (Richard Harter) writes:
>>> On Mon, 16 Jan 2012 16:35:48 -0800, Keith Thompson <kst-u@mib.org>
>>> wrote:
>>[...]
>>> And if you have a friendly editor it will convert tabs to spaces and
>>> vice versa just as you desire.
>>
>>But not very well if different past maintainers had different ideas of
>>where the tabstops should be.  For example, one section of code might
>>assume 2-column tabstops, and another might assume 4-column or 8-column
>>tabstops.
>
> Within a single file?

Yes.

>                        And your editor displays them all correctly?

No.

That was the problem.

> How remarkable.

>>Which is ok if tabs (and only tabs) are used exclusively for
>>indentation, but not if both sections have a mix of tabs and spaces.
>
> I don't you caught what I had in mind.  If your editor has the option
> of automatically converting tabs into spaces you can use tabs with the
> settings you prefer, get the indentation that floats your boat, and
> still have a tab free file.  I keep all of my code in tab free format
> (except for makefiles - boo, hiss).  If your editor can go the other
> way, i.e., convert those pesky spaces into tabs, you can deal with
> files that historically have tabs that you want to keep that way.
> Just convert tabs to spaces, edit, and convert back from spaces to
> tabs.
  
That could work if everyone who modifies the file *either* uses only
tabs for indentation *or* uses only spaces (with a consistent number
of columns per level) for indentation.  My recent experience does
not indicate that maintaining that kind of consistency is practical.
Perhaps in some organizations it would be.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15877

On 2012-01-17, Richard Harter <cri@tiac.net> wrote:
> And if you have a friendly editor it will convert tabs to spaces and
> vice versa just as you desire.

I use program that I call autotab. This is integrated into
Vim. When I open a file, autotab is called to analyze up to 5000
lines of text from the file and emit a configuration for Vim,
such as whether tabs are expanded with spaces (expandtab), the soft indentation
size (shiftwidth) and the hard tab size (tabstop).

The code is here:

http://www.kylheku.com/cgit/c-snippets/tree/autotab.c

This program is so rarely wrong that I've stopped fixing the situations when it
is wrong.

[toc] | [prev] | [next] | [standalone]

#15862

On 2012-01-16, Bubba <nickname@banelli.biz.invalid> wrote:
> #define LAMBDA NULL

While this is a valiant effort, I recommend nothing less than:

#define PASTE(X, Y) X ## Y
#define XPASTE(X, Y) PASTE(X, Y)
#define MKTOKEN(A, B, C, D) XPASTE(XPASTE(A, B), XPASTE(C, D))
#define LAMBDA MKTOKEN(N, U, L, L)

Now you've REALLY defined a useless synonym for a useless synonym for zero,
in style!

Also, don't foget:

/* right-associatively-pasted lambda */
#define R_MKTOKEN(A, B, C, D) XPASTE(A, XPASTE(B, XPASTE(C, D)))
#define R_LAMBDA R_MKTOKEN(N, U, L, L)

/* left-associatively-pasted lambda */
#define L_MKTOKEN(A, B, C, D) XPASTE(XPASTE(XPASTE(A, B), C), D)
#define L_LAMBDA L_MKTOKEN(N, U, L, L)

Benchmark all three to see which LAMBDA null pointer constant runs faster!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web