Why learn an OS's API when you can use a cross platform lib
What's the point of learning an operating system's API when you could easily just use a cross platform library?
For example, why would someone use Windows Forms and have their program run only of Windows when they can use Qt and deploy on multiple operating systems. Or why would someone write networking code using the Linux API when they could easily use the Boost.Asio library.
Is there really any benefit in learning an operating system's in's and out's?
For example, why would someone use Windows Forms and have their program run only of Windows when they can use Qt and deploy on multiple operating systems. Or why would someone write networking code using the Linux API when they could easily use the Boost.Asio library.
Is there really any benefit in learning an operating system's in's and out's?
Last edited on
What would you do if you will need to extend such crossplatform library? Or if you need to write your own because you cannot afford one (QT) or its license prevent you from using it (using some free libraries in proprietary commercial applications)
What if there is no library for your platform? (Again, QT exist on QNX only in commercial version, boost::asio supports limeted seclection of platforsm)
What if you have to eschew any frameworks, wrappers and such for the sake of perfomance?
What if you need to write a device driver? For device you (or your company) just created.
What if there is no library for your platform? (Again, QT exist on QNX only in commercial version, boost::asio supports limeted seclection of platforsm)
What if you have to eschew any frameworks, wrappers and such for the sake of perfomance?
What if you need to write a device driver? For device you (or your company) just created.
Last edited on
@MiiNiPaa
Thank you so much for the quick response. You make a great point.
Should I put off learning an operating system's API until I actually need it in a project?
I'm asking because my free time is limited.
Thank you so much for the quick response. You make a great point.
Should I put off learning an operating system's API until I actually need it in a project?
I'm asking because my free time is limited.
Last edited on
You should learn what OS API has to offer, to avoid reinventing the wheel and know when using other libraries is counterproductive.
If you are going to add 10+MB of QT to the 100KB application to show one informational message...
If you are going to add 10+MB of QT to the 100KB application to show one informational message...
If performance isnt an issue, the library gives all the feature you need, and it supports the platform you need, its often a no brainer.
Licensing is often not as bad as it is made out to be. You can implement closed modules that take advantage of the LGPL license, if available.
Licensing is often not as bad as it is made out to be. You can implement closed modules that take advantage of the LGPL license, if available.
> Should I put off learning an operating system's API until I actually need it in a project?
Yes. Yes.
We don't really learn a language feature, a new programming idiom, an API or the architecture of a library till we have used it to solve a real life-problem.
This is what I tend to do:
a. First, look at the standard C++ library.
Look for anything else if and only if the functionality provided by the standard library is inadequate.
b. Then look at the Boost libraries.
They are of a high quality, widely used, robust, non-viral and is part of mainstream C++. Many Boost libraries are eventually incorporated into the standard C++ library.
c. Look for de-facto standards which are available as part of the standard API on every platform.
For instance, try to limit the usage to the BSD sockets API rather than resort to cute WinSock extensions.
d. If none of the above suffice, then and only then look around for good (ideally non-viral) libraries.
Yes. Yes.
We don't really learn a language feature, a new programming idiom, an API or the architecture of a library till we have used it to solve a real life-problem.
This is what I tend to do:
a. First, look at the standard C++ library.
Look for anything else if and only if the functionality provided by the standard library is inadequate.
b. Then look at the Boost libraries.
They are of a high quality, widely used, robust, non-viral and is part of mainstream C++. Many Boost libraries are eventually incorporated into the standard C++ library.
c. Look for de-facto standards which are available as part of the standard API on every platform.
For instance, try to limit the usage to the BSD sockets API rather than resort to cute WinSock extensions.
d. If none of the above suffice, then and only then look around for good (ideally non-viral) libraries.
Topic archived. No new replies allowed.