Is there a point to learning Linux-specific APIs? [closed] - c++

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm starting to move from Windows to Linux development. In the process, I need to "forget" all of the familiar Windows APIs (WaitForSingleObject, CreateTimer etc.) and learn a bunch of Linux specific APIs instead.
So, my question is... should I?
I mean, if cross platform libraries like Boost are commonly used in the Linux community, do I really need to learn ahead the Linux-specific APIs?
I'm well aware that it would be a good idea to be at least familiar with the APIs, but... what is most common in the professional industry? Do most Linux-focused software companies use cross platform libraries, or OS specific APIs?

It depends on how complicated things you are going to use/need. For example Linux has SEM_UNDO option for System V semaphore, which is not available, when boost is used. In general, boost portability does not come for free, you will be able to use only common subset of different O/S possibilities. If this is enough for you, go for boost and do not handle (sometimes) obscure low level API. This should not only make your programs more portable (to some extent), but also less error-prone.

As a pure C programmer, I rely on the long-time-successful POSIX standard. This is, for me, the best portable API I have ever used across UNIX-based systems. As #Shi points out in a comment, whether you're developing for embedded or desktop/server computers is important because Boost is quite heavy. I'm also an embedded systems developer and the POSIX standard is also quite portable even for uCLinux (a tiny tiny Linux port for embedded systems).
I think the strength of the POSIX standard resides on its low-level of implementation. It deals with fundamental computer concepts (device I/O, memory management, IPC,...) that unlikely change along the years. We are used to see changes in the way we interact with computers, not in the way computers actually work, and the POSIX standard is powerful due to its maturity on dealing with how computers work. Indeed, I'm in love with those magic functions as fork(), pipe(), read() and write() :-)

Related

FLTK, wxWidgets, GTK - light, easy and portable [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know that it isn't first topic when somebody considering different GUI libraries. But I have a few specific questions and needs that "the others" didn't have.
(As usual) I'm novice programmer, learning C++ now (finishing thinking in c++) and my university wants me to learn some GUI for programming projects (I'm electronics student) - I'm writing this because personally I would like to know C++ a little bit better before learning some additional libraries. But reality is brutal in this case :).
I'm looking for simple (easy to write in) library that will work under windows, linux and embedded systems (embedded linux or any other lightweight ARM system, not necessary android) without much (best case - ANY) modifications. I would like this library to be lightweight (thats why I eliminated QT), easy to use with other libraries (for audio/video players or some network applications) and languages (I'd like to write also in C, which will be my primary language I believe, maybe some python, D or java). The documentation/tutorials should be also easy and simply written - my English skills are very basic, as you can see reading my post.
After googling for hours my vote is for GTK/GTKmm which allow me to use LXDE, XFCE and GNOME (light/medium/heavy) without installing additional libraries, write code in C, C++, D, Python, Java and almost every programming language that exists. On the other hand many peoples wrote that FLTK is very simple, most portable and probably the fastest one. WxWidgets has many positive opinions so... I just don't know, please help me.
Thanks for your replies,
Pawel
I heard that FLTK is lightweight but have never used so no much comments. I have used however GTK+ and wxWidgets. I would say go for wxWidgets as it is a wrapper around GTK+ in Linux. Apart from that here are added advantages
wxWidgets uses native widgets wherever possible
You can use wxBase library which makes it lightweight (at expense of some feature see this)
Great support than GTK+ IMHO (forum, IRC, mailing list, SO, et al)
Also you can read these entries
http://docs.wxwidgets.org/trunk/page_libs.html
http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
https://stackoverflow.com/questions/5141116/choosing-between-qt-gtk-and-wxwidgets
https://stackoverflow.com/questions/1257894/wxwindows-vs-gtk-for-cross-platform-gui-programming
http://www.gidforums.com/showpost.php?p=37761&postcount=8
I would personally suggest you go with wxWidgets!

c++11 threading vs .Net threading? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which one should I use in my C++11/CLI program?
Which is the pros and which is the cons of c++11 threading and .net threading?
My program is windows only and is built with .net.
Considering that managed languages usually prefer developer productivity over performance (when in conflict), I'd say that managed threading is likely to be more developer friendly. Also, Garbage Collection is a well-known productivity feature.
Do you have an extreme need for performance and/or control? If not, I recommend managed code and managed threading.
C++11 would be a standard based, platform independent way of going about threading. This is important if you need to work across platforms.
Threading with .Net will typically tie your application with the OS (Windows). This has some advantages such as garbage collection (which is amiss in standard C++). However, note that you will probably need to ship the .Net framework with your application. Issues across versions of the framework are not too uncommon.
If you are asking about managed vs. native, then use managed code C# as much as possible, it's a much nicer developer experience all around. Also, the .NET 4 supports excellent APIs to help with multithreading, see Task Parallel Library (TPL) and the concurrent collections support, for starters.
The general purpose advice is to use managed code as much as possible, then use interop to native only as needed, for problems that don't quite fit the managed solution.
If you are asking about using C# vs. C++/CLI, then use C#. Both are CLI (managed) languages, but C++/CLI is more difficult to work with and is best used for some managed/native boundary scenarios. Also, C++/CLI doesn't support Intellisense (at least for VS2010, maybe now supported in 2012?)
Consider tenure: .NET threading has been around for a long time and is known to work with C++/CLI. C++11 threading is new, and I could totally see problems arising between that and C++/CLI since the /CLI stuff isn't as mainstream and it's likely that few other people are using /CLI and C++11 threading together.

Programming Language for Mac OS X application [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have an upcoming project coming up in which I want to dedicate several months to making a professional application which is basically a text editor with a special purpose (can't disclose too many details). The program shouldn't be too complicated, but I wanted it to have a nice GUI and be fast enough to sell from either the Mac App store or my website.
I was going to initially make it for Mac OS X and then later Windows and I wanted to know, for someone who is intermediate at programming, what language should I use for this program? Should I use a library? I already have a foundation in c++.
The standard programming language for Mac OS X is Objective-C, however, as a rock solid Unix descendant, it also has great C and C++ support. If you want to write an efficient, nice and native (OS X) look-and-feel GUI, I'd suggest you use Cocoa (it has Objective-C interfaces) which is Apple's default and official GUI implementation for OS X. Considering portabilitiy, however, you may also use some cross platform GUI/widget toolkit, such as QT, GTK+, etc. (which are also, in general, written in C/C++).
The Language
Well, if you have a solid foundation in C++, by all means use C++! However, I must warn you that C++ has a bad reputation for allowing only those people to use it who know every damn feature of the language. Therefore, you may soon run into problems if you don't have a thorough knowledge of templates for instance.
With reference to the platform, in my opinion, all mainstream languages are more-or-less good enough for Mac OS X development ( or Windows development ), it really depends on what you feel convenient using.
The Library
Now we come to my favourite part. Comparing Application frameworks. There are many choices when using Mac OS X. If you want to target multiple platforms ( as you say, you want to also support Windows later on), I suggest GTK+ or Qt. For a comparison between the two libraries, see here.
If you're programming for OS X, check out Cocoa. If you're aiming to create multi-platform applications, check out Qt.
Cocoa uses Objective-C, which is a superset of C - transitioning to it from C++ isn't too difficult, and the Apple Developers site has quite a bit of information for beginners.
Qt works with C++ or Javascript.
You can use marmelade
http://www.madewithmarmalade.com/
To make your application portable and you can write it in C language.
I would use Free Pascal with Lazarus for this, with native interface (still Carbon on OS X though, the Cocoa interface is still in development AFAIK) due to its natural cross platform behavior, both language and libraries so there's no external dependencies required. This would require you to learn another language and framework (it's the same with C++ if you're planning to use QT, GTK, or whatever you've never used before) however.

Portability libraries/frameworks [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have the book "Write Portable Code" which details POSH, an open-source "framework" (mostly just a header) to help with portability of C/C++ code between different platforms and hardware.
Since Poshlib hasn't had an update in 5 years now, I was wondering what other similar libraries/frameworks exist out there?
For C code, GLib is a modern cross-platform (non-GUI) library which makes it easy to write applications that run on many different platforms without source code changes. GLib is actively developed in an open manner as part of the GNOME project with lots of open source projects using it.
For C++ I would suggest looking at the Boost libraries.
Dear Shaggy Frog,
While I remain largely incurious about your handle, I must say that this is something of a hairy issue. Here's why. I work with the boost libraries day in and day out. They're fantastic, and make innumerable tasks way easier. But I must emphasis that if you use them, you need to use a profiler. Some of the really nice portions of it tend to be a bit slow, and you should definitely read up on best-practices before using certain parts like, say, transform iterators. Boost, though, is worth mentioning because it does make an effort to supply some pretty powerful pieces of abstraction that are almost foreign in the ++cverse.
However, Boost, and other frameworks like it, are not snakeoil. They rock. People who rock use them. People who rock work on them. For more specialized tasks, I'd need to know more about your problem domain. However, one other tool that's really excellent is SWIG, which will let you bundle up any hunk of portable C code into a library that's... well.... accessible.
As for bloat, a lot of that is going to go away when C++0x moves to the standard, thanks to variadic templates, and a number of similar pieces of cleverness. Honestly, I'm tired of people yelling about The Terrors Of Templates. Perhaps six years ago they were a danger due to poor compiler support, but these days, they're part of the language. They live under almost every piece of generic code you touch. Projects like CLang are hammering the very last nails into this coffin as we speak. They aren't a fad anymore. They aren't a magical solution. No one still thinks that. No one you should hire, anyway.
The future approaches. Do you need a Boost?
Most libraries with the buzzwords "portability framework" or "portable runtime" in their names are useless bloat and snake oil. If you want to write portable code, start with the relevant standards and follow them. Instead of reading your vendor's man pages or help files for standard library functions, read the ISO C or C++ standard or POSIX standard. And so on.
Aside from highly crippled embedded systems (note: many/most embedded systems do not fall into the "highly crippled" category) and DSPs, pretty much any environment can be made to be POSIX conformant. A much better approach than trying to design or find a new "portability framework" on top of diverse and incompatible underlying systems is to evaluate what parts of POSIX you need to get the job done, what parts might be missing or non-conformant on systems you're interested in, and whether there are drop-in replacements or workarounds for the missing or broken functionality.
For most people, the only relevant non-POSIX system is Windows. Cygwin is one heavy-weight option for making Windows conform to POSIX, but if you code to a more-inclusive subset of POSIX, you can get by with much lighter solutions and still support Windows.
There is similar Predef project on sourceforge, but it are not updated for several years also.
FWIW, the predef pages are actively maintained and have been continuously updated over the last several years.
Aside from Boost, which all C++ programmers should be familiar with, there are several libraries worth looking at. STLSoft is the first one that comes to my mind.
I have prepared a list of some prominent portability libraries for C and C++ on my personal web site. One can freely reuse it under the terms of the Creative Commons Attribution Licence. I had some experience with Qt, GLib, and the Apache Portable Runtime, and they all seemed to have been mostly OK.
There is also another list on the wikipedia.

Is coding in native c++ still popular? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I want to go into native c++ programming after University, but it seems like languages that compile with JIT (like .Net) are overtaking c++. What does the future hold for Native code?
C++ is the seventh programming language I have been professionally paid to program in, and I'm sure won't be the last. My advice is not to think of yourself as a specific language programmer. Even if JIT takes over the world, it has to get down to native machine code eventually, and someone has to write that software.
There are a lot of opportunities to work on natively compiled C++ code. It's especially popular (along with C) in non-PC environments such as embedded and real time environments, and in a lot of situations where there is some level of safety certification required.
Game programming, where performance is usually critical, is another area where C++ is very popular.
It is less popular than it was in traditional 'desktop' applications and web service applications although you can find native code projects in both these areas - especially the former - if you hunt around.
I'm not sure what you mean when you say that you will be "going into native C++ after college". Your career will not be defined by what languages you know, it will be defined by what you can do with those languages.
However, C++ is used widely in many applications. I work in systems and we use C++ for everything. .NET isn't an option in my world, but the guys doing the GIU's next door use it for everything. It comes down to what you want to do with your career. The language you use will come naturally, you are thinking about it backwards.
There will always be a place for C/C++
Any application that needs to be as
fast as possible will be written in
a native language like C/C++
Any application that runs on a device that has limited memory
will
run better in C/C++ since memory
management is more deterministic.
Operating systems will continue to be written in C. That
include
device drivers.
Up until recently one always had the luxury of speeding an application up by using better hardware. Will Moore's law being stretched to the limit, chances are the performance improvements will have to come from software. Chances are that languages that give better performance will come into their own in this regard.
If you go desktop C++ is still the way to go especially if you want to be cross platform.
Java GUI Libraries are way to slow and .NET is not portable (the GUI part).
But C++ is a language beast, the only language where i can understand managers to ask for 5 years experience.
In the server world the VM/JIT has so many advantages that only basic infrastructure is coded native. If this is the industry you want to join learn (infrastructure) or don't learn (applications) C++.
Its also pretty popular in embedded programming where you can't fire up a hundert MB virtual machine.
Since C/C++ is the only fast imperative native programming language left in mainstream you should learn at least the basics.
Yes, of course it is:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
And some of the great features like rvalue-references, variadic templates, uniform initializations, lambdas, unrestricted unions, thread-local storage, extern templates and ... yet keeps C++ to be a good choice for 20 years of the future, until the C++ committee decides to publish another new standard for the other remaining years (like a do...while!) (:
Note that the computers needs native programs to run! Java, .NET, python and ... needs native environment to run on it! so, native programs are the base of softwares.