Why STL library?
As a beginner we are forcefully feeded the STL library. Yeah, I know that we don't need to work hard for the work already done by others. But I feel like I am just scripting for the compiler not programming for the hardware. Why don't they(or you)teach us whats inside everything?(Is it that we will learn it later?). What does it take to make own code that reads from keyboard(same as cin) and displays in monitor(as of cout) without using<iostream>.
There are just some regular fuctions in the library.You can use it by include this library instead of writing the fuction on you own.
But, if you want someting done differently when calling fuctions in the library, you can overload it.
But, if you want someting done differently when calling fuctions in the library, you can overload it.
@xiaowei.Thanks for your reply but I am not satisfied with your answer.Please read my question once again. I wonder, is my question clear. Sorry if not.
You can try and make an input and output by scratch but let me tell you it might be a bit hard for you right now.
here's what the input stream looks like:
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00912_source.html
here's what vector (1 of the stl) look like:
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00739.html#ad8b1553486aa775c08b2980ed677b1af
I started trying to make my own templated container the other day but didn't get around to finishing it.
http://www.cplusplus.com/forum/beginner/113499/
here's what the input stream looks like:
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00912_source.html
here's what vector (1 of the stl) look like:
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00739.html#ad8b1553486aa775c08b2980ed677b1af
I started trying to make my own templated container the other day but didn't get around to finishing it.
http://www.cplusplus.com/forum/beginner/113499/
Last edited on
For 99% of practical cases, you do not (and should not) need to know the underlying mechanics. You can always learn about them for fun, though, but just don't feel like you're doing anything wrong by using abstraction layers like C++ and the STL.
So you want to do everything yourself , then you have to write your own drivers , program your BIOS and the interrupt controller to listen to ports and create the interrupt queue , program your graphic driver to write to the VRAM for different functions actually write your kernel...
This seems impractical and a waste of time to me.
Streams are basically abstractions of functions provided by your OS to control the console , so instead of STL you can call those functions but you stil have to use already programmed routines.
This is the basic concept of "high level programming" to not reinvent the wheel and use abstractions contrasting assembly and machine language, there are languages like java , c# with huge libraries to let programmers only concentrate on their problems by providing them the bells and whistles, they would waste their time making.
This seems impractical and a waste of time to me.
Streams are basically abstractions of functions provided by your OS to control the console , so instead of STL you can call those functions but you stil have to use already programmed routines.
This is the basic concept of "high level programming" to not reinvent the wheel and use abstractions contrasting assembly and machine language, there are languages like java , c# with huge libraries to let programmers only concentrate on their problems by providing them the bells and whistles, they would waste their time making.
@a k n. I agree and with appreciate you. But what for those who actually write new device drivers. I don't think already programmed routines would help them.
| what for those who actually write new device drivers |
If you ask Torvalds, kernel (and hence drivers) should be in C, not C++. Granted, you still have a standard library at your disposal.
Drivers are between metal and OS. You need to know both metal and OS. Programming drivers is clearly not for everyone.
The STL and C++ standard library is taught for a few reasons:
1. These algorithms and containers are optimized. They may not be very easy to read but that's because they consider effeciency above readability. The interfaces with these functions/classes are well documented though.
2. Everyone who has a C++ standard-compliant compiler has these functions available. No downloading 3rd party libraries
In the world of OOP, only interfaces should be important. You might be curious regarding the implementation, but that shouldn't affect how you use the class. I think this is the toughest part of converting to OOP... If you must know about what happens inside of a class, you need to go through several layers of abstraction before you get to the details.
Example:
in cmath there is a sin() function. We know what goes in and we know what comes out. How it is implemented is not something that we need to worry about when using the function and so we should be able to use the function without knowing the internal details (whether it's using taylor series, lookup tables, or something else). The same is true for std::vector, std::string, std::cout.
1. These algorithms and containers are optimized. They may not be very easy to read but that's because they consider effeciency above readability. The interfaces with these functions/classes are well documented though.
2. Everyone who has a C++ standard-compliant compiler has these functions available. No downloading 3rd party libraries
In the world of OOP, only interfaces should be important. You might be curious regarding the implementation, but that shouldn't affect how you use the class. I think this is the toughest part of converting to OOP... If you must know about what happens inside of a class, you need to go through several layers of abstraction before you get to the details.
Example:
in cmath there is a sin() function. We know what goes in and we know what comes out. How it is implemented is not something that we need to worry about when using the function and so we should be able to use the function without knowing the internal details (whether it's using taylor series, lookup tables, or something else). The same is true for std::vector, std::string, std::cout.
Last edited on
Topic archived. No new replies allowed.