Thread: C++ std routines

Are C++ stnadard routines like std::cout wrriten using C liberary functions like fgets()?

>Are C++ stnadard routines like std::cout wrriten using C liberary functions like fgets()?
Possibly, but not likely. It's easier (not really, but it's *better*) to work through a lower level API than to use a middle man.

[>>>>>>>>>>>>>>>>>>>>>>>>>>>EDITED<<<<<<<<<<<<<<<<< <<<<<<<<]
I read in msdn that fgets() and similar functions are standard in C Run-Time liberary. The CRT functions should be platform independent (Am I right?), so the lowest level of platform independent functions are fgetc(), _putw(), _getch(), _setmode(), etc. Am I right?
If C++ std liberaries like iostream has their own low level rutines and does not use C rutines, then why msdn Run-Time liberary reference is full of C rutines?

Another point: When we use Win32 API for creating a file for example. Some very low level rutines that are written by microsoft and are in kernel32.dll for example execute. These low level rutines does not use C or C++ std libraries to do their job. Am I correct?
Now if we imagine that Windows don't prophibit us from executing low level rutines and I want to write a program that formats a hard drive, am I beyond the OS hardware abstraction layer?
How Partition Magic formats a drive for example? What rutines does it use?

If you feel my questions are stupid or confuzing please tell me to explain more. It is very important for me to find the correct answers.

> Maybe I should ask how fgets() works? What rutines does it use?
Whatever the current platform has to offer probably.

Consider the std:: the nice level concrete on which you build your house.

Underneath, there is the whole jaggy mess of the current platform, but you don't need to know about that. In some places it can be quite thin, but in other places it could be much thicker.

I've edited my last post. So please read it again.

OK. So for example when I use std::cin.get() in my code, the real code that will be replaced by a linker or (if its body is in a DLL and will be executed in RunTime) can be different in each platform. The standard is only for the arguments, return value and the duty of the function, the body can be different.
Am I correct?

How Partition Magic formats a drive for example? How OS let him do its job?

That is correct... in a way. It's at compile-time, not linking-time.

In the context of this discussion, i'm defining a C++ implementation as the combination of the compiler, linker and standard library (including the STL). Your implementation is portable if it conforms to the ISO C++ specifications. These specifications rule the language syntax and how the entities of the standard library should be presented to the user (we, the coders).

If an implementation changes these rules, it is not portable. For instance, if the syntax for a function declaration was altered by some implementation to function_name return_type(arglist,...); instead of the ISO defined return_type function_name (arglist,...);, this implementation would not be portable across other implementations.

On another implementation that conformed to ISO C++, that change would be caught at compile time and flagged as an error.

If the implementation overloaded getline() to include yet a new declaration with different parameters than those already defined in the standard library, the same would happen if the user decided to code with the new getline function and compile his code on another implementation.

However, despite being not portable across implementations, it could still be portable across systems. That implementation (assuming it was a Win32 one) could have a corresponding one for Linux, and Solaris, and DEC,...

That level of portability (portability across systems) is achieved by the implementation provider in how he coded the standard library (STL included). It is obvious that a std::cout cannot work the same way in windows, linux, Macintosh,... However, to the user it must look like so. Regardless of the system the user is coding for, std::cout syntax must be the same. The code that implements std::cout, on the other hand, is necessarily different.

But the code of std::cout is "added" at compile time. Not linking time.

>>How Partition Magic formats a drive for example? How OS let him do its job?

Partition Magic does not use either C or C++ standard functions for that because there are no such standard functions. It will have to go directly to the os api system calls, such as win32 api functions. I don't know which specific functions because I've never attempted to format a drive in a win32 program. Those os-specific functions can be called just like any of the standard c or c++ functions, just include the correct header file(s) and libraries. For win32 api functions, see www.msdn.microsoft.com or your compiler's online help files for win32 api functions.

But the code of std::cout is "added" at compile time. Not linking time.

Why at compile time? std::cout has external linkage and should be linked after compilation.

If I foun out correctly there are some functions in WinIoCtl.h that can do such things. Is it possible to write own code for formatting and partitioning?

The linkage type regulates the visibility of a name. Not if that name is added during compile or link-time.

External linkage names are those names that are visible from every translation unit of a program (global objects, extern const objects, classes...)

An Internal linkage name is a name that is local to the translation unit where it was declared (non extern const objects, names declared inside namespaces, static objects,...).

No linkage objects are all those names local to the scope in which they were declared, but not visible across the entire translation unit (local variables, enumerators declared inside a function, classes defined inside a function,...)

OK maybe I should use the term external refference. But I thought std::cin is in a lib and should be linked by linker to .obj. Or is in a DLL.

Yoy know, cin.get() is not an intrinsic function. I am now really confuzed.
If I am wrong please correct me (above post).