Printable View
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;
};
this should be your declaration
As for the Linked list implementationCode:/*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
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);
LST_REMOVE(head, elm, field)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);
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;
}
>#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
>>...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;
}
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"
>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
>>future updates
future updates of WHAT..
be more specific
That would be the compiler for everyone in the cheap seats. Or for the truly bored, directly from the ISO C standard:Quote:
reserved by the implementation
Here's where the C standard defines this limitation in case you don't believe me for some odd reason (it happens):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
-PreludeCode: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.
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
>>..if you doesn't like...
UPS!
pardon my english
if you *don't* like...
>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
>>...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 :
than :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*/
Code:#ifndef NUCLEAR_CONTROL
#define NUCLEAR_CONTROL
....
#endif /NUCLEAR_CONTROL*/
#ifndef _NUCLEAR_CONTROL
#define _NUCLEAR_CONTROL
....
#endif /*_NUCLEAR_CONTROL*/
>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