the way someone explained it to me that helps remember to put prototypes before using is; to treat it like declaring a variable. you can't use a variable before declaring it. i know there is differences, but i feel it is a good frame of reference to a new programmer or at least a new C / C++ programmer.
That was a clear explanation. Thanks, Dr. This is similar to hoisting in JavaScript . Hoisting is JavaScript's default behavior of moving all declarations to the top of the current scope (to the top of the current script or the current function)
Hi, congrats for your videos. For this one, in order to be more educational/demonstrative, you could have : a) Showed the _printf_ prototype in header file; b) wrote foo() and bar() into two separate source code files; c) created your own header file containing foo() and bar() prototype. This would have been more _in real life_ C project demo. Thanks anyway, Peace!
I am a person that wrote some or more C code :) . This TH-cam Channel, is making C very easy to learn, if you do not know . C actually is a easy or very easy programming language.
Header files are full of prototypes its really useful to put all the prototypes into a header and just include that header when working with multiple c/c++ files
Yes, and Pascal used the "Forward" reserved word to mark such forward declarations. It also had to my mind better terminology such as "Uses" to mark include files.
Is because the compiler needs to know how much stack space it needs to grow when calling a function (in addition to any automatic variables it may have).
Got an idea for your next vid, c++ templates vs preprocessor templates, preprocessor being where you make a bunch of defines your template expects (in place of of the c++ templates) and use #include to use your template (in other words the template is an entire file on it's own) which in turn undefines those defines once it's done with them (unless it's expected that you will use the defines still after said template's inclusion) **Edit:** As an aside it's also possible to replicate the inheritance of members like c++ classes do by putting the members in their own file then including that file at the top of the struct you're defining, damn sight clearer as to what goes where too. With that technique on top of the preprocessor templates and the callback typedefs, there's no actual value to c++ besides syntactic sugar and overloading
Your C programming language points are very useful and great. As you know, writing fast and accurate numerical calculation programs is always the concern of numerical calculation programmers. I think figuring out how to implement math functions in the C compiler is a safe and standard way to develop your own mathematical library. Because the compiler was written by very professional people. But my problem is that I don't understand its written literature. For example, I could not find how a function like SQRT is implemented. If possible, please advise. Thankful
These prototypes, you can move them to a .h file (header) and include that? Which then allows you to move the implementations to another .c file (C? source? code?) and compile that separately? (then link the compilations as last step?) If yes then I think I'm beginning to understand this flow a bit more...
Hi, Jacob, greetings from San Francisco. I have found that explaining function prototypes to newbies is an excellent gateway to a discussion explaining HOW C passes parameters to the called function on the stack, and how the return parameter is returned ON the stack, along with an attendant et discussion of the concept of FRAMES. Are you going there to?
I am new to C, so I have to ask: They seem to be completely unnecessary and not make any sense. Why not just declare the function as it is at the top of the source file? Then you have the functionality, the return type, the arguments and the compiler compiles.
I think you glossed a little too much on why it's needed. If you wanted, it's easy enough to straight #include all your code. But I think? for libraries like you said it is not a choice at all, you must use the linker after compilation, the code is not baked into your executable in a kind of outdated desire to save space repeating the same libs again and again on your filesystem.
Yeah, most 5 minute programming videos gloss over some important stuff. And, yes, libraries are a common use case. There are, of course, header-only libraries. So, it is a choice. But, you're right if I'm linking together a bunch of different code from different translation units, I'm going to need prototypes. I was just trying to provide a simple example for beginning programmers who may not really grok the whole linking/translation unit/library part of the picture. I guess maybe I need to make another video on the topic. 🤔 Thanks.
I think needing function prototypes is so primitive. Modern multi-pass compilers can resolve these symbols from the actual functions regardless of where they are declared in relation to where they are used. I don't know why C/C++ never got rid of this archaic limitation.
Btw, C does allow typedef function types, but it does not allow to define (and declare) functions with those typedef-ed types. What you can do is define a function macro for full function type with substituted name as argument. #define MyWidget_define(name) int (name)(char *restrict buf, void *ctx, size_t ctxsz) typedef MyWidget_define(MyWidget_func); struct Widget { MyWidget_func *call; void *ctx; size_t ctxsz; }; MyWidget_define(widget_foo) { buf[0] = 'b'; buf[1] = 'a'; buf[2] = 'r'; buf[3] = '\0'; memset(ctx, 1, ctxsz); return 0; }
@@_gatorland_ sposterebbe la responsabilità della gestione della "forward diclaration" dei simboli dal programmatore al compilatore, automatizzando il tutto. Ci sono dei precedenti, per esempio gli assbler moderni sono tipicamente a doppia passata in modo da poter fare dei "salti" ad etichette definite "sotto" la riga corrente
@@AlessioSangalli quindi ti riferisci solo ad eventuali funzioni dichiarate nei source file anziché negli header? Io penso che servano molto a strutturare il codice, in modo da fornire una raccolta compatta di funzioni dichiarate nei .c ed aumentare la comprensione e la leggibilità
What can you build with C in 2023? Have you built any great projects with C so far? Why don't you share your C projects with us? I'd like to see your C projects, please don't say no
The fact that you either have to write functions before you call them or write meaningless (because no compiler parses in one pass nowadays) function signatures just pisses me off terribly, as a person who came from c sharp. This makes zero sense, at least because functions can't be reassigned in c anyway
This not only ugly thing in c Fact that you should either write “struct”/“enum” word every time or use typedef is fucking annoying Why not doing this by default just like C does with other datatypes? And no, this is not about getting less syntax sugar, but getting more control Thats just bad design or proof me wrong
C is old. There is no module system; everything is file-based. It's up to you to let the compiler know the parameters and return types of any functions not defined in the source file you're compiling. If you don't like writing "enum" and "struct" all the time, then use C++. Enums in C aren't even type safe (they turn into ints) so you don't really need to declare an enum using its tag name. Both C and C++ have built up technical debt over decades of modernization while still maintaining backwards compatibility with older standards. If you want something like C but fully modern, consider Rust.
@@alexanderdell2623 To your surprise, my forte is C#, too; just that I code in seven different languages but never complain about any. You do not even have a valid reasoning in this "argumentation" :P
![F.HERO Ft. JSPKK x ลำไย ไหทองคำ x M-PEE - ไม่สนิทบิดหมด (Thai Riders Anthem) [Official MV]](http://i.ytimg.com/vi/kPJZ0UihBfk/mqdefault.jpg)
Without them, foo couldn’t call bar and that would be a sad sad day
the way someone explained it to me that helps remember to put prototypes before using is; to treat it like declaring a variable. you can't use a variable before declaring it. i know there is differences, but i feel it is a good frame of reference to a new programmer or at least a new C / C++ programmer.
That was a clear explanation. Thanks, Dr.
This is similar to hoisting in JavaScript .
Hoisting is JavaScript's default behavior of moving all declarations to the top of the current scope (to the top of the current script or the current function)
These quick little C basics videos are really useful. Thanks
Thank you, Dr. Sorber.
Hi, congrats for your videos. For this one, in order to be more educational/demonstrative, you could have : a) Showed the _printf_ prototype in header file; b) wrote foo() and bar() into two separate source code files; c) created your own header file containing foo() and bar() prototype. This would have been more _in real life_ C project demo. Thanks anyway, Peace!
You are a very good teacher - It's a great thing you decided to post your videos!
I am a person that wrote some or more C code :) .
This TH-cam Channel, is making C very easy to learn, if you do not know .
C actually is a easy or very easy programming language.
Simple but important to know. Thanks.
Header files are full of prototypes its really useful to put all the prototypes into a header and just include that header when working with multiple c/c++ files
This is also called "forward declaration".
Yes, and Pascal used the "Forward" reserved word to mark such forward declarations. It also had to my mind better terminology such as "Uses" to mark include files.
Is because the compiler needs to know how much stack space it needs to grow when calling a function (in addition to any automatic variables it may have).
Got an idea for your next vid, c++ templates vs preprocessor templates, preprocessor being where you make a bunch of defines your template expects (in place of of the c++ templates) and use #include to use your template (in other words the template is an entire file on it's own) which in turn undefines those defines once it's done with them (unless it's expected that you will use the defines still after said template's inclusion)
**Edit:** As an aside it's also possible to replicate the inheritance of members like c++ classes do by putting the members in their own file then including that file at the top of the struct you're defining, damn sight clearer as to what goes where too. With that technique on top of the preprocessor templates and the callback typedefs, there's no actual value to c++ besides syntactic sugar and overloading
Your C programming language points are very useful and great.
As you know, writing fast and accurate numerical calculation programs is always the concern of numerical calculation programmers.
I think figuring out how to implement math functions in the C compiler is a safe and standard way to develop your own mathematical library.
Because the compiler was written by very professional people. But my problem is that I don't understand its written literature.
For example, I could not find how a function like SQRT is implemented. If possible, please advise. Thankful
You should make a video on _Generic. Show how to use it and maybe even do a simple array example. Something similar to C++'s std::vector.
These prototypes, you can move them to a .h file (header) and include that?
Which then allows you to move the implementations to another .c file (C? source? code?) and compile that separately? (then link the compilations as last step?)
If yes then I think I'm beginning to understand this flow a bit more...
Please make a video about _Generic and it's usage
It’s also called a forward declaration.
Hi, Jacob, greetings from San Francisco. I have found that explaining function prototypes to newbies is an excellent gateway to a discussion explaining HOW C passes parameters to the called function on the stack, and how the return parameter is returned ON the stack, along with an attendant et discussion of the concept of FRAMES. Are you going there to?
I am new to C, so I have to ask:
They seem to be completely unnecessary and not make any sense. Why not just declare the function as it is at the top of the source file? Then you have the functionality, the return type, the arguments and the compiler compiles.
I think the point is that, when other people view your code they may not know how you decided to organize it.
GCC gave me this warning today: "warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x"
Guys how can i calculate 2^1001
In c or cpp
Any ideas for that issues
Well, one answer would be (1
I think you glossed a little too much on why it's needed.
If you wanted, it's easy enough to straight #include all your code. But I think? for libraries like you said it is not a choice at all, you must use the linker after compilation, the code is not baked into your executable in a kind of outdated desire to save space repeating the same libs again and again on your filesystem.
Yeah, most 5 minute programming videos gloss over some important stuff. And, yes, libraries are a common use case. There are, of course, header-only libraries. So, it is a choice. But, you're right if I'm linking together a bunch of different code from different translation units, I'm going to need prototypes. I was just trying to provide a simple example for beginning programmers who may not really grok the whole linking/translation unit/library part of the picture. I guess maybe I need to make another video on the topic. 🤔 Thanks.
I think needing function prototypes is so primitive. Modern multi-pass compilers can resolve these symbols from the actual functions regardless of where they are declared in relation to where they are used. I don't know why C/C++ never got rid of this archaic limitation.
Currently 1 week into a 4 week c boot camp 😓
Btw, C does allow typedef function types, but it does not allow to define (and declare) functions with those typedef-ed types. What you can do is define a function macro for full function type with substituted name as argument.
#define MyWidget_define(name) int (name)(char *restrict buf, void *ctx, size_t ctxsz)
typedef MyWidget_define(MyWidget_func);
struct Widget {
MyWidget_func *call;
void *ctx;
size_t ctxsz;
};
MyWidget_define(widget_foo)
{
buf[0] = 'b';
buf[1] = 'a';
buf[2] = 'r';
buf[3] = '\0';
memset(ctx, 1, ctxsz);
return 0;
}
Why would you do that macro trick? It just hides names and types of argument 'buf' and 'ctxsz'.
great guy teaching useful stuff, but I wish you spoke slower. it's sometimes really hard to keep up.
So i'm the only one that's still confused
I really wish C had a spec that required two pass parsing to avoid this unnecessary sophistication
E perché pensi non sia necessario? Chiedo per curiosità
@@_gatorland_ sposterebbe la responsabilità della gestione della "forward diclaration" dei simboli dal programmatore al compilatore, automatizzando il tutto. Ci sono dei precedenti, per esempio gli assbler moderni sono tipicamente a doppia passata in modo da poter fare dei "salti" ad etichette definite "sotto" la riga corrente
@@AlessioSangalli quindi ti riferisci solo ad eventuali funzioni dichiarate nei source file anziché negli header?
Io penso che servano molto a strutturare il codice, in modo da fornire una raccolta compatta di funzioni dichiarate nei .c ed aumentare la comprensione e la leggibilità
@@_gatorland_ non parlavo di header. Comunque altri linguaggi (che so Java) non usano header files, è una scelta
What can you build with C in 2023? Have you built any great projects with C so far? Why don't you share your C projects with us? I'd like to see your C projects, please don't say no
The video is unclear
The fact that you either have to write functions before you call them or write meaningless (because no compiler parses in one pass nowadays) function signatures just pisses me off terribly, as a person who came from c sharp.
This makes zero sense, at least because functions can't be reassigned in c anyway
This not only ugly thing in c
Fact that you should either write “struct”/“enum” word every time or use typedef is fucking annoying
Why not doing this by default just like C does with other datatypes?
And no, this is not about getting less syntax sugar, but getting more control
Thats just bad design or proof me wrong
@@alexanderdell2623 stay mad
C is old. There is no module system; everything is file-based. It's up to you to let the compiler know the parameters and return types of any functions not defined in the source file you're compiling.
If you don't like writing "enum" and "struct" all the time, then use C++. Enums in C aren't even type safe (they turn into ints) so you don't really need to declare an enum using its tag name.
Both C and C++ have built up technical debt over decades of modernization while still maintaining backwards compatibility with older standards. If you want something like C but fully modern, consider Rust.
@@anar.bastanov average c-lover argumentation
@@alexanderdell2623 To your surprise, my forte is C#, too; just that I code in seven different languages but never complain about any. You do not even have a valid reasoning in this "argumentation" :P
It's not helpful. Thanks anyway