<math.h> is a header specified in the C standard. Its usage is supported in C++, but formally deprecated (which means, approximately, slated for potential removal from a future standard) by all C++ standards. I would suggest it is unlikely to be removed from a future C++ standard, for as long as backward compatibility to C is considered important or desirable.
<cmath> is a header specified in the C++ standard. It provides essentially the same functionality as in C's <math.h>, except that names (other than a couple of macros) reside in namespace std.
A similar story goes for <stdio.h> (C) and <cstdio> (C++), except that usage of stream I/O (e.g. <iostream>) is encouraged in C++.
Standard C++ headers never have a .hpp extension. That naming convention for headers is a convention encouraged by some, but is not formally required.
<math.h> is a header specified in the C standard. Its usage is supported in C++, but formally deprecated (which means, approximately, slated for potential removal from a future standard) by all C++ standards. I would suggest it is unlikely to be removed from a future C++ standard, for as long as backward compatibility to C is considered important or desirable.
<cmath> is a header specified in the C++ standard. It provides essentially the same functionality as in C's <math.h>, except that names (other than a couple of macros) reside in namespace std.
A similar story goes for <stdio.h> (C) and <cstdio> (C++), except that usage of stream I/O (e.g. <iostream>) is encouraged in C++.
Standard C++ headers never have a .hpp extension. That naming convention for headers is a convention encouraged by some, but is not formally required.
The C++11 Standard says:
D.5 C standard library headers
1 For compatibility with the C standard library and the C Unicode TR, the C++ standard library provides the 25 C headers, ...
The inclusion of these headers is stated as deprecated, meaning:
Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.
So they are still (just) part of C++.
They are provided for compatibility which is to allow the programmer to compile programs originally written for C with a standard conforming C++ compiler with little or no modification. That means things like not having to change the #include statements from <stdio.h> to <ctsdio>.
So the example given in cplusplus.com is actually standards conforming C++ that just happens to be compatible with a C90 and a C99 conforming C compiler. Presumably they do this because the page describing the math library gives information for both C and C++ languages following the standards for C90, C99, C++98 and C++11.
So to answer the specific questions:
1) Why are they using
<stdio.h>I thought this was for C and not really for C++ ?
It's for C++ compatibility with C. Presumably they use it so the code will also compile on a C90/C99 conforming C compiler for which the page gives specifications.
1) Why are they using
<math.h>I though the .h represented C header files rather than the .hpp C++ header files?
No. The standard does not specify what extensions files should use. In practice many C++ projects use .h as an extension for their header files.
I feel like I wont be able to explain myself if the teacher asks "why did you use a C header file?
Given that the C compatibility headers are deprecated (though probably not going anywhere) I would suggest it better to use the <cstdio> and <cmath> versions. However the idea that you are somehow writing C code simply because of your choice of library function is wrong. If it is legal C++ code being fed through a C++ compiler then it is C++. It may be more procedural in character and less object oriented in philosophy but it is nevertheless fully C++. Many, many, many C++ programs use libraries written in other languages, especially C. That doesn't make those programs somehow C.
Videos
Append -lm to the end of your gcc command.
With all recent versions of GCC on GNU/Linux systems like Ubuntu, when you use the math library, you have to explicitly link to it. It is not automatically linked to along with the rest of the standard C library.
If you are compiling on the command-line with the gcc or g++ command, you would accomplish this by putting -lm at the end of the command.
For example: gcc -o foo foo.c -lm
If you are going to compile a C program with math.h library in LINUX using GCC or G++ you will have to use –lm option after the compile command.
gcc xyz.c -o xyz -lm
Here,
gcc is compiler command (compiler name)
xyz.c is a source file name.
-o is an option to specify the output file.
xyz is the name of the output file.
-lm is an option to link againt the math library (libm).
for more details here is the link containing complete article on it.
Compiling C program with math.h in Linux.
we have just started learning about programming in c and our teacher told us that we must include the math library in order to perform functions like sqrt and pow. however im using code blocks for programming and it turns out that i didnt need to use that. is it because the stdlib.h has already been included?
The functions in stdlib.h and stdio.h have implementations in libc.so (or libc.a for static linking), which is linked into your executable by default (as if -lc were specified). GCC can be instructed to avoid this automatic link with the -nostdlib or -nodefaultlibs options.
The math functions in math.h have implementations in libm.so (or libm.a for static linking), and libm is not linked in by default. There are historical reasons for this libm/libc split, none of them very convincing.
Interestingly, the C++ runtime libstdc++ requires libm, so if you compile a C++ program with GCC (g++), you will automatically get libm linked in.
Remember that C is an old language and that FPUs are a relatively recent phenomenon. I first saw C on 8-bit processors where it was a lot of work to do even 32-bit integer arithmetic. Many of these implementations didn't even have a floating point math library available!
Even on the first 68000 machines (Mac, Atari ST, Amiga), floating point coprocessors were often expensive add-ons.
To do all that floating point math, you needed a pretty sizable library. And the math was going to be slow. So you rarely used floats. You tried to do everything with integers or scaled integers. When you had to include math.h, you gritted your teeth. Often, you'd write your own approximations and lookup tables to avoid it.
Trade-offs existed for a long time. Sometimes there were competing math packages called "fastmath" or such. What's the best solution for math? Really accurate but slow stuff? Inaccurate but fast? Big tables for trig functions? It wasn't until coprocessors were guaranteed to be in the computer that most implementations became obvious. I imagine that there's some programmer out there somewhere right now, working on an embedded chip, trying to decide whether to bring in the math library to handle some math problem.
That's why math wasn't standard. Many or maybe most programs didn't use a single float. If FPUs had always been around and floats and doubles were always cheap to operate on, no doubt there would have been a "stdmath".