Link lists as datastructure

This is a discussion on Link lists as datastructure within the C Programming forums, part of the General Programming Boards category; Hi,everybody! The program reads in three types of input data using link lists. I wrote several structures but i really ...

  1. #1
    Registered User
    Join Date
    Jun 2002
    Posts
    3

    Question Link lists as datastructure

    Hi,everybody!
    The program reads in three types of input data using link lists.

    I wrote several structures but i really don't know how to use link lists to implement it!
    I'll appreciate if anybody give me any hint how to begin it!

    struct store{
    char * recordtype;
    int itemqty;
    float itemprice;
    int markup;
    };

  2. #2
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    this should be your declaration

    Code:
    /*FILE store.h*/
    
    #ifndef _STORE_H_INC_
    #define _STORE_H_INC_
    typedef struct _store{ 
       char * recordtype; 
       int itemqty; 
       float itemprice; 
       int markup; 
    
       struct st_n {  /*linked list node*/
           _store *pnext,*pprev;
       }link;
    }store;
    
    struct st_list{
        struct st_h { /*linked list header...*/
             _store *pfirst, *plast;
        }head;
        int count;
    };
    
    #endif
    As for the Linked list implementation
    just look of the macroses in the attachment
    i made...

    Usage of some of the macroses:

    Code:
    /*LST_INIT:  init list*/
    st_list some_list;
    LST_INIT(&some_list.head);
    Code:
    /*LST_INS_TAIL:  inserts a node at the tail*/
    st_list some_list;
    store some_store;
    LST_INS_TAIL(&some_list.head, &some_node,st_n);
    Code:
    /*LST_INS_HEAD:  inserts a node at the head*/
    st_list some_list;
    store some_store;
    LST_INS_HEAD(&some_list.head, &some_node,st_n);
    Code:
    /*LST_REMOVE(head, elm, field):  removes a node from a list
    WARNING!! this does not free the memory!
    You should save the pointer 
    and delete it after that*/
    
    st_list some_list;
    store *lp_some_store;/*some valid allocated pointer (malloc-ed)*/
    store *save = lp_some_store; /*save the pointer*/
    /*remove from list*/
    LST_REMOVE(&some_list.head, lp_some_store, st_n)
    /*free the mem*/
    free(save);
    LST_REMOVE(head, elm, field)
    Attached Files Attached Files

  3. #3
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    also if you allocate the nodes/stores
    with malloc you should destroy lists like this:

    Code:
    void destroy(st_list *plist){
        store *pnode = plist->head.pfirst;
        if(pnode){
             do{
                LST_REMOVE(&plist->head, pnode, st_n)
                free(pnode);
                pnode = plist->head.pfirst;
             }while(pnode);
        }
        plist->head.pfisrt = plist->head.plast = NULL;
    }

  4. #4
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >#ifndef _LIST_INC
    >#define _LIST_INC
    Bzzzt! You're out. This violates the implementation namespace because you used a leading underscore. I'm also curious as to why you chose to implement this as a series of macros.

    -Prelude
    My best code is written with the delete key.

  5. #5
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    >>...This violates the implementation namespace ...
    I do not violate nothing since this is pure C code...
    there are no namespaces in C...
    and this is C Programming forum...
    (uhmms forgot to remove #if defined(__cplusplus) lines in "_list.h" again take a NOTE at the C .h extension
    not <list>)


    >>I'm also curious as to why you chose to implement this as a
    >>series of macros.

    because i think this is the best solution for
    this type of linked list in pure C.
    This is just an intermediate code

    one should wrap those macroses (which are very general)
    in functions like this:
    Code:
    typedef struct _strnode
    {
        .....
    }strnode;
    
    int strlist_insert_node(strlist *plist, strnode *pnode){
      int ret=0;
      LST_INSERT(....)
      /* do other init stuff*/
      return ret;
    }

  6. #6
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    Also this is very close to the idea
    found in the standart Linux "list.h" implementation

    mine (the "_list.h" ) is a variation of Linux "list.h"

  7. #7
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >I do not violate nothing since this is pure C code...
    >there are no namespaces in C...
    >and this is C Programming forum...
    You seem to be confused by my choice of wording, allow me to be more specific.

    Identifiers beginning with an underscore are reserved by the implementation for future updates. If you violate that then it could very easily break your code later on. This is true for both C and C++, but I refer only to C since this is a C programming forum.

    -Prelude
    My best code is written with the delete key.

  8. #8
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    >>future updates

    future updates of WHAT..
    be more specific

  9. #9
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    reserved by the implementation
    That would be the compiler for everyone in the cheap seats. Or for the truly bored, directly from the ISO C standard:
    Code:
     3.12
    1 implementation
      particular set of software, running in a particular translation environment under particular
      control options, that performs translation of programs for, and supports execution of
      functions in, a particular execution environment
    Here's where the C standard defines this limitation in case you don't believe me for some odd reason (it happens):
    Code:
    7.1.3 Reserved identifiers
    1 Each header declares or defines all identifiers listed in its associated subclause, and
      optionally declares or defines identifiers listed in its associated future library directions
      subclause and identifiers which are always reserved either for any use or for use as file
      scope identifiers.
    
       All identifiers that begin with an underscore and either an uppercase letter or another
      underscore are always reserved for any use.
    
       All identifiers that begin with an underscore are always reserved for use as identifiers
      with file scope in both the ordinary and tag name spaces.
    -Prelude
    My best code is written with the delete key.

  10. #10
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    Aaw...!

    Now i get it !

    there something in my code that is not ISO style standart compliant!!!!

    Well guess what ...
    I have my own style...
    and i like it that way with leading '_'
    so i know the diff between:

    #define MAGIC_1 0x1234
    and :
    #define _SOME_CONTROL_DEF

    and since C/C++ syntaxis doesn't dissallow me to write :
    #define _VALID_C_SYNTAX
    i will use it like that.

    i am sorry if you doesn't like the layout of the header file
    everyone is permited change it without asking the author
    Use it for comercial purposes if any of you want to do this
    I don't care... This is (C)ommonly (U)sed (S)nippet in my
    programs...
    End of story

  11. #11
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    >>..if you doesn't like...
    UPS!
    pardon my english

    if you *don't* like...

  12. #12
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >I have my own style...
    That's fine, but I prefer to think of a style as something correct but unique to the programmer. Leading underscores are provably wrong, so your argument of style is silly.

    >and since C/C++ syntaxis doesn't dissallow me to write
    It doesn't dissallow void main either, but you're not stupid enough to do that, right? Because void main is wrong, just like leading underscores are wrong.

    >i am sorry if you doesn't like the layout of the header file
    I couldn't care less unless I'm the one maintaining it. I'm just trying to help you improve your code.

    >This is (C)ommonly (U)sed (S)nippet in my programs...
    Then I hope you don't (W)ork (F)or a (N)uclear (P)ower (P)lant.

    -Prelude
    My best code is written with the delete key.

  13. #13
    Banned borko_b's Avatar
    Join Date
    Jun 2002
    Location
    Well... I live in Bulgaria :)
    Posts
    100
    >>...Because void main is wrong...

    Now this is totaly different thing :

    void main it is not wrong
    void main is just undefined behavior because
    when the program returns the flow to the OS
    it leaves the EAX unchanged ... and if the OS is expecting value from EAX something BAD could(or could not) happen

    leading underscore WILL never cause such thing
    (except for some fancy new compiler wich automaticly updates some software using '_' but can't think of any so this is "don't really care" scenario)
    And it isn't wrong

    >>...Then I hope you don't (W)ork (F)or a (N)uclear (P)ower (P)lant
    The Nuclear Plant will never meltdown because of this...

    AND in case of maintaining:


    I prefer this :
    Code:
    #ifndef _NUCLEAR_CONTROL_V_1_1_1
    #define  _NUCLEAR_CONTROL_V_1_1_1
    ....
    #endif /*_NUCLEAR_CONTROL_V_1_1_1*/
    
    #ifndef _NUCLEAR_CONTROL_V_1_1_2
    #define  _NUCLEAR_CONTROL_V_1_1_2
    ....
    #endif /*_NUCLEAR_CONTROL_V_1_1_2*/
    than :

    Code:
    #ifndef NUCLEAR_CONTROL
    #define  NUCLEAR_CONTROL
    ....
    #endif /NUCLEAR_CONTROL*/
    
    #ifndef _NUCLEAR_CONTROL
    #define  _NUCLEAR_CONTROL
    ....
    #endif /*_NUCLEAR_CONTROL*/

  14. #14
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >void main it is not wrong
    >void main is just undefined behavior because
    Two contradictory statements. void main is undefined and undefined behavior is wrong.

    >leading underscore WILL never cause such thing
    No, it only risks mixing names with the implementation. This has the potential to change the entire functionality of your program without your knowing about it. If something is reserved then perhaps you should consider why. The standards committee are not idiots, they do everything for a reason and if you don't understand the reason then don't risk it.

    But, I'm through wasting my time with you. I've shown you your error, proven that I'm correct, and you still choose the path of willful ignorance. So there's no more need to argue with you on the point.

    -Prelude
    My best code is written with the delete key.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. I'm confused about link lists (again)
    By JFonseka in forum C Programming
    Replies: 4
    Last Post: 06-13-2008, 09:13 PM
  2. Function to check memory left from malloc and free?
    By Lechx in forum C Programming
    Replies: 4
    Last Post: 04-24-2006, 06:45 AM
  3. functions using link lists
    By chood72 in forum C++ Programming
    Replies: 3
    Last Post: 10-31-2005, 03:51 PM
  4. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM
  5. double link lists
    By rumi_red in forum C++ Programming
    Replies: 3
    Last Post: 10-30-2001, 10:13 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21