I have attended many online coding competition, they usually mention the note that #include<conio.h> means conio.h header can not be used.
I am not aware about all functions included by this header but curios to know that why it's not a good programming habit?
If anybody can explains some of it's functions should not be used.
example clrscr().
Well, conio.h is platform-specific. If you try to compile on Linux, your code will probably not compile. Also - using functions to manipulate the console window make your program less reusable than if you were using just standard input and output (you cannot redirect the stdin/stdout so easily).
If you are making rich console applications, you can instead use cross-platform libraries, such as ncurses.
It's not standard
[...] it is not part of the C standard library, ISO C nor is it defined by POSIX. 1
Some compilers support it but they are platform depended and it's hard to write a portable code between them.
Related
I wrote a c program on windows. It can compile properly on this OS. It uses windows.h library.
Can I compile it by GCC compilers on Mac? Or I must to change the code?
I heard c is portable; therefore it should can run on Mac. Yes?
You must either change the code or install something on your system to provide a substitute for <windows.h>, because it is not a standard header on macOS with Apple’s developer tools.
Assuming you do not install some substitute, if any exist, then you must remove #include <windows.h>. Whether you must change any other code, and how much, depends on what facilities you have used from <windows.h> and cannot be answered without knowing more about your code.
C is portable. The C standard defines a core subset of the language called strictly conforming. Strictly conforming code is portable to all C implementations. Most C programs include code outside that subset. It is portable to some extent, but there are many qualifications to that, many implementation dependencies, and many subtleties. Commonly, any complicated program requires changes in order to run on a new platform unless it was carefully designed for portability.
I've heard while looking at different C implementations that any system that hopes to implement C must minimally include certain libraries, stdarg.h etc. My question is why this is, it can't be that the C library is not Turing complete without some headers, and since the headers have been written it must be true that I could write them myself. Why, then, is it not permissible to have a C implementation consisting of just a compiler+linker toolchain? (of course, in this case interacting with the OS would require inline assembly or linked assembly code as well as knowledge of the system's syscalls etc., but that doesn't mean that C can't be written, does it?)
You confuse a property of the programming language, i.e. the language itself with additional features mandated by the standard.
"Turing complete" is just about the language itself; basically if you can use it to solve a certain class of problems (for a more exact definition, please see Wikipedia for a starter(!) ). That is quite an abstract concept and does not include any libraries. Basically, if you use such libraries, you just have to be able to write those libraries in the language itself. This is true for the C language.
About the libraries required: Your premise is wrong. C very well allows to omit the libraries themselves. That is the difference between a hosted (full libraries) and a freestanding (few target-specific headers, but no generated code). See 4p6.
The few headers are normally part of the compiler itself. They basically provide some typedefs and #defined constants, e.g. the range of the integer types (limits.h) and types of guaranteed minimum width (stdint.h, often also fixed-width types). stddef.h e.g. provides size_t and NULL.
While you do not need to use those headers, they already allow writing portable code for the program logic. Just see them as part of the language itself, tailored to the target.
The gcc C compiler, for instance actually is a freestanding implementation: It only provides the required headers, but not the standard library. Instead, it relies on the system library, which is e.g. glibc on Linux.
Note: Generally it is a bad idea to re-invent the wheel. So if you are on a hosted environment (i.e. full-grown OS), you should use the features available. Otherwise you might run into trouble, as these e.g. mightr provide additional functions not directly seen by your code. E.g. debugging or system/user-wide configuration like localisation support. Also debugging support might depend on you using the standard library, e.g. valgrind. Replacing memory allocation with your own code at least makes this much more difficult.
Not to mention maintainability. Not just others will understand your code easier if you use the standard names&semantics, but also yourself - just wait some years and try understanding your old code.
OTOH, if you are on a bare-metal embedded system, there is actually little use of most features the standard library. Including e.g. printf or scnaf just bloats your firmware, often without any actual use. For such systems, there are stripped-down libraries (e.g. newlib) which may be not completely compliant or allow to omit certain costly features, e.g. floating point conversion or the math lib. Still you only should use them iff you really need many of their features. And sometimes there is a middle way, but that requires some knowledge about the dependencies of the library.
Two reasons: compatibility and system interaction.
If you don't implement the whole C standard library, then code other people write won't work. Even the most basic C program uses library calls.
#include <stdio.h>
int main() {
printf("Hello world!\n");
return 0;
}
Without an agreed upon and fully implemented stdio.h that program will not run because the compiler doesn't know what printf() means.
Then there's system interaction. C has been called "portable assembly". This is because different computing environments do things differently, but C takes are of that for you (well, some of it). You can't write a portable stdio.h in assembly without losing your mind. But its more than that. Each C header file protects you from something that each environment does (or used to) do very differently.
stdlib.h shields you from differing memory models and process control.
stdio.h shields you from differing IO systems.
math.h shields you from differing floating point implementations.
limits.h shields you from differing data sizes.
locale.h shields you from differing locales.
And so on...
The C libraries provide a standard API that each environment can write to. When C is ported to a new environment, that environment is responsible for implementing those libraries according to the particulars of that system. You don't have to do that.
Nowadays we live in a much more homogeneous environment than when C was developed, but most of the C standard library still protects you from basic differences in how operating systems and hardware do things.
It didn't always used to be this way. An example that comes to mind is the hell of running a game on DOS. There was no standard interface to the sound and video card (if you had them). Each program had to ship drivers for each sound and video card they supported. If yours wasn't in there, sorry. If their driver was buggy, sorry.
Programming without the C standard library is kind of like that, but far far worse.
Is it possible to run a written code or written library that only uses initial c libraries, on every platform?
For example:
Windows,
ARM Microprocessors,
PIC microprocessors,
They have their compilers seperately and this difference is not important for me, I can compile in different compilers for need. But do I have to change code totally or partially to run on this platforms?
Note: For libraries, I will just use default c libraries.
It depends. If your library use only standard C and the multiplatform you are about to port has a compiler compatiable to standard C, you can always write the library code. But if your library have to call native API of each platform, you have to encapsulate these code seperately.
In embedded systems you will need to implement certain functions that the operating system gives you (like _sbrk, _read, etc.) for standard library functions like malloc and printf.
If you take care of that I don't see a reason for your code not to work so long as you take GREAT CARE in how you write it. By GREAT CARE, I mean be very careful with floating points, processor word size and any other things that are not common between your desired targets.
Short answer: possible, but not easy.
Am using a Dev c++ compiler, to compile a c code. (I am a beginner)
When I compile, it says 'some' header files are missing.
How can i include those header files in my system, so as to be utilized by the program??
Thanks
A header such as <sys/sem.h> which is used for the function semget() among other things, is not generally available in Windows. It's a POSIX header, and Windows does not implement the POSIX standard out of the box.
You should maybe look at the Win32 API instead, for instance a function like CreateSemaphore().
The problem is that you are trying to use the Linux API on Windows. Here is what is going on: Every operating system has its own set of libraries for programmers to use to make programs on that platform. In this instance, you are attempting to use Linux libraries on Windows. Windows doesn't have a code location called sys/ipc or sys/sem.
Furthermore, since you said you are a beginner, try finding another tutorial. sys/ipc.h and sys/sem.h are not for beginners, are are libraries typically used for communication between processes. These concepts are way beyond you right now haha :P
Here is a better place to start: http://www.cprogramming.com/tutorial/c-tutorial.html
I've got a question regarding writing applications for Windows. Can I use WinAPI and DWMApi (aero glass, ribbon, etc.) when programming in ANSI C? I'm looking at MSDN right now and they use c++.
The Windows API is a C API and can be used with any compiler that supports the 'standard' calling convention.
Microsoft has made the strategic decision to put their own C compiler on life support, though, and you're stuck with C90 (with some specific extension) when using Visual Studio. You can use 3rd party compilers (GCC and Clang via MinGW, Pelles C) which support more modern language dialects.
Try it.
Most APIs actually ARE C-APIs; they just call it C++ because "nobody" really uses C anymore. I've also noticed the occasional struct with additional functions attached to them, but definitely not in Win32, and they might just #ifdef that away for C.
The thing I don't know right away is whether the headers are "safe" when used with just C, and whether the libraries have unmangled symbols. I would assume they are, but one never knows. However, making a simple C program that just calls a single Win32 API function should clarify that.
The Win32 API is accessible from many different toolsets. All C compilers for Windows that I have ever come across can call all Win32 APIs. What's more all these C compilers can call COM APIs and even GDI+ which is a very C++ centric library. But MS provided a bridge for C clients to use.
So, in summary, choosing to use C will not deprive you of access to any part of Win32.