What are some good ways to structure a C program? I'm coming from an OO background and I can't wade through these thousands of pajeet videos that have flooded YouTube, just to find a few nuggets of good advice. Seriously, the search results for anything related to C are absolutely horrendous.
Please help.
Other urls found in this thread:
github.com
c-faq.com
twitter.com
Define your data in data.h
Define your methods acting on data in methods.h
Include data.h before including methods.h in main.c
so C is an Indian-tier language?
OO works in C too
If the struct is named x, then the functions will be like
void x_init(struct x*)
int x_do_stuff(struct x*)
void x_free(struct x*)
For ages, people turned to OO where it suited the problem well.
C is pretty great because it doesn't force you, when the program fits another paradigm better.
Actually I prefer C++ though, mainly because templates, but builtin OO support isnt bad either. They could work a bit on functional proframming tho.
Anyways, this is the best in multi-paradigm languages, you can freely choose whichever fits the problem at hand the best.
state machines
If I pass a pointer of the struct to a function, can I just dereference it and modify the values inside of the function, or is this extremely bad practice? Didn't seem like another logical way to do it. I'd hate to do that in another language.
Thanks for the other tips. I guess I'll just put the structs and their related functions in a file each. I also believe OO is overkill.
>If I pass a pointer of the struct to a function, can I just dereference it and modify the values inside of the function, or is this extremely bad practice? Didn't seem like another logical way to do it. I'd hate to do that in another language.
Of course you can. If you don't want to let it modify, make it accept a const struct x*, that's what const is all about after all.
Passing pointer is the most optimal way to modify a struct, since it only passes 4-8 bytes. As opposed to making a whole copy if the struct.
What about indexing into global array? is that as fast as using a pointer?
Perfect, thanks lads
stole my post from advent of code general, lil faggot
obj files
oh, is it missing from there? sorry faggot
This is a joke right?
yet to see an indian C coder
they are mostly doing java android c# and sometimes c++
piracy is stealing, you'll hear from my attorney
Anyone can answer this?
Isnt a[i] = *(a+i)?
yes &a[i] is (a+i)
.
Not commercially, just the tutorials. It was probably the first programming language many people heard of, so of course there is an unending avalanche of shitty videos.
HolyC is actually an improvement over C.
Yes thats literally what that operator does.
Thats why you can go autistic and write i[a] and it will work the same
Does this mean one should define their own constructors for structs? Is there a standard for approaching this?
but would it be faster to use indexes instead of pointers if you can store your structs in arrays?
What i mean is accessing the struct using
struct A* a;
and doing
a.member = 2;
vs. accessing it with mystructs[i] each time,
mystructs[i].member = 2;
Depends on the size of the structure. If the structure is small (2 pointers or less) and you don't need mutation, just pass by value. It'll probably be faster because you don't have to worry about aliasing.
(mystructs+i)->member = 2;
might be slightly faster but not worth it
Its more of a convention, for where the initialization is non-trivial or opaque to the caller. It avoids a lot of problems. Say, you have a matrix structure, with members width, height, elemsize and p (for pointer). Its a lot cleaner to have a function, where you just give the width, height, elemsize, and it does the allocation on its own. Imagine the case when you add a new member, say comparor function ptr, because you want to have your matrixes sorted. Change the prototype of the constructor, and all outdated uses will be compiletime errors, instead of random crashes where you try to sort a matrix and comparor func is random memory junk.
>don't ever define a variable in header files.
>don't ever define a function in header files.
(you can declare them, but the actual definitions must be in .c files).
>don't use global variables, if you have to, read the following;
>if a function or global variable is specific to a single .c file, define it as static. it means no other .c file can access it, and compiler optimize it better (inline etc.).
>only public (non-static) functions must be declared in header files. if you have a public global variable, define it in .c file, declare it as extern in header file.
(so basically a .c file must be constructed as a single module).
>never include header files in header files. include them in .c files. the include order in .c file solves all the problems you envision.
i will not talk about practices of C as your question is only about structuring a C program, but you should read "practice of programming" by kernighan and pike anyway if you haven't already.
or you can define all your variables in one file,
and all your and implementations in another file. Prove to me that this doesnt work.
works is not the question
Thanks for this post, it was very helpful. Should structs go in header files? I will check out the book.
What implementation? Defining means actually making it, like, without "extern". Did you mean declaring?
yes
>define all your variables in one file,
>and all your implementations in another file
ew
Instead of having to waddle through garbage you can just look in a single file, keep the principle of one function per task and you are good.
tell me right now why this doesn't work
right
now
this is pure porn
Longer compilation times because you need to create a massive .o instead of just recompiling the changes to smaller files and linking them.
this is a good argument assuming you never have to make changes that might ripple through your program
>not structuring your program in such a way that you never need to make changes which might cause a ripple through your program
First of all, stop using youtube for programming guides, you fucking imbecile.
impossible if you are trying to solve any real problems
Recommend some good books that were written in the last 40 years then. Also, Google searches have the same problem, thousands of pajeet blogs top all of the results.
This is great, thanks
Same way you structure anything else.
However C has headers, so use them.
Header declares all functions and data structures; the source file implements them.
Typically, you make a separate directory for your header files and your source files which makes it easier to make libraries or modules or whatever you call it.
As for how to write the functions, you can still write it as objects if you need to, but more often, you see it as functions that take objects as inputs instead.
So you assume he meant a single file for every implementation and a single file for every declaration?
Because having these two split compiles faster in general. But this assumes you have a million files in a project.
>Should structs go in header files?
it depends, if it's a private resource, let's say some handle, you can define in .c file and the public functions (interface) use void* for it.
void *create_xxx(void);
int do_something(void *xxx);
void destroy_xxx(void *xxx);
you can also use #define HXXX void *
this is especially useful for libraries. for instance, you may need to use variable types from 3rd party libraries in your struct.
if you put structs in header file, users of your library should also find and include that 3rd party library headers to use your library, which is not nice.
Thank you. Makes sense.
Just read some good C code, sooner or later you'll grasp how to make your programs efficient and well designed.
This advice is bad.
If you want an opaque handle, forward declare a struct then typedef it. This gives you strong typing.
Using #define for a type is one of the most retarded things you can do in C.
thats a terrible practice because it bypasses type checking
it can happen you will mistakingly use argument of different struct type and this solution will hapilly compile it
if you only use pointers to the struct in the header, you can simply declare "struct something;" in header file and define it "struct something{int lol};" in source file
you're right, typedef is the way to go, i was just being lazy. i also use enums and typedefs instead of macros where ever possible.
dude, this solves nothng, use forward declaration of the struct
do you even C?
Any language that legacy software was written in is now considered Indian-tier; it doesn't necessarily reflect on the language itself.
Imagine the smell.
You should avoid void* where you don't need it, too. Forward declared structs are more maintainable, less error prone and just plain more convenient.
So variables and functions that are used by multiple source files are declared in header files? I don't see what's so confusing about this unless I'm wrong.
In most programming languages, the interface to a translation unit is generated automatically and you don't have to make a header file on your own.
>So variables and functions that are used by multiple source files are declared in header files?
100% exactly
What the fuck ever? This is general knowledge everyone Cnile would know.
That uncheck switch statement is fast as fuck