Thread: not enjoying it

Well, Boost doesn't replace the WinAPI in any way I can think of.
Abachler is not comparing both libraries side-by-side, I think. He's merely referencing the fact that indeed once you get into WinAPI, you will probably not want to use Boost because the latter makes heavy use of the STL types while WinAPI presents its own types which aren't based on the STL (WinAPI has been around since before that).

The trouble of going through explicit conversions (some of them probably involving the need to create your own STL wrappers), doesn't compensate against just doing it the WinAPI way.

WxWidgets has all the characteristics you mentioned above for Boost. Free, Peer-reviewed and portable. Yet, in most cases, you'll not want to use boost with it exactly because of the fact it presents its own types (some of them direct counterparts to the STL). More, you will definitely get into problems if you want to use certain libraries like boost::threads.

WinAPI is the portable one, I can hack, quickly solve problems and do dirty things to people using FBSLv3 and WinAPI only.

Since 96% people use Windows in my country.

WinAPI is the portable one, I can hack, quickly solve problems and do dirty things to people using FBSLv3 and WinAPI only.

Since 96% people use Windows in my country.

I don't think that's the commonly accepted definition of portability.

The way I learned it, portability is the ability for some software to run, and produce the same result, without or with little modifications on many hardware and software platforms (which may be weighted by userbase).

By this definition, WinAPI is not portable at all. It only runs on one hardware platform (x86) and one software platform (Windows), whereas portable libraries often support many other platforms IN ADDITION TO Windows on x86.

Originally Posted by cyberfish

The way I learned it, portability is the ability for some software to run, and produce the same result, without or with little modifications on many hardware and software platforms (which may be weighted by userbase).

Sure, but if all you want to do is program for windows (at which no doubt you could make a respectable living for the rest of your life) "portability" is a purely theoretical, basically irrelevant concept.

Not at all. There's still issues of portability across different windows kernels, portability across different locales, portability across different drivers, portability across different compilers, even the probabilistic probability of the code being later re-engineered for other vastly different systems like Linux or Macintosh.

Portability is a vast concept if devoid of any context.
Meanwhile, the WinAPI is in fact fairly portable to Linux due to the efforts of the WINE project.

I'm saying that once you learn the Windows API you can do anything the boost library can do, only with less overhead and fewer problems.

And a lot more code that I certainly do not want to have to (re)write and get correct. The point of abstracting things into libraries is in order to facilitate reuse. The point of abstraction in the first place is to let your mind think about less but do more - "We all know the only mental tool by means of which a very finite piece of reasoning can cover a myriad of cases is called ‘abstraction’; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worthwhile to point out that the purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." - Edsger Dijkstra, The Humble Programmer.

Anyway, I am not exactly sure why you A) seem to think that boost is directly competing with the WinAPI in some way, and I am also not exactly sure why you think B) that by 'doing it yourself' and not using boost, all your problems will magically vanish all of a sudden or something. Neither are true.

If you simply write windows applications, I do not care - I don't use windows anyway, so your code is probably largely irrelevant to me anyway and (I suppose) your viewpoint is valid (in a way.) But please do not use your limited view on the matter to try and put a library like boost on the stand only to knock it down. Trying to frame boost in such a manner is just a straw-man argument.

Considering you haven't exactly presented a valid technical argument against boost, I'm just going to assume you write windows apps and you don't need boost - which is fine.

Just don't project your needs onto mine.

anyway on topic: I just acquired my first full-time job as a programmer writing lots of Java/C++ (with boost, mind you!) I am also about to be attending school full-time.

Because of this, I have little time to work in the areas of research that I find particularly fascinating and interesting (functional programming, programming language design, reverse engineering, etc etc.) So it gets a little hard sometimes to be motivated, even when I manage to find the time. I have a lot of open source projects I try to contribute to, and I haven't been motivated to recently. And that's OK. It happens. People experience stress and a little bit of burnout.

Software will always be there for me to hack on late into the night - and I'm doing it for a job now. I feel like I should be more detached from it now, because while I have a passion for computing, there are tons of things in life that I would be a fool to give up for a computer screen - and I've done it before.

It's natural to feel somewhat burnt out or tired of something. Find something else for the time being. I stumbled into computers when I was about 11 and found a big passion - who's to say that can't happen again?

Originally Posted by Mario F.

Meanwhile, the WinAPI is in fact fairly portable to Linux due to the efforts of the WINE project.

I would call the current state of WINE pre-beta at best (as in it doesn't build and the binary distros of it I have seen have crippling bugs that are acknowledged by the developers), so this is a bit of a stretch at least for the time being.

I have nothing against it (in fact I wish it worked well), just that is my experience as a reasonably competent user -- don't promise anyone WINE will do anything for them.

I agree. However it must be said they have been doing an hell of a job. If one doesn't get too ambitious with the applications they try to run under Wine, the experience is very satisfying (if you are into running windows apps in linux. I'm not, with one notable exception: foobar2000).

That statement is just plain wrong. There are versions of windows for other processor families e.g. AM33 , x64 , ARM , EBC , IA-64 , M32R , MIPS , MIPS16 , MIPSFPU , MIPSFPU16 , MIPS41XX , SH3 , SH3DSP , SH4 , SH5 , THUMB , X86 , and Alpha as well as others. There are also other operatign systems that support WinAPI, such as Linux (through WINE) and REACT-OS.

Modern Windows only runs on x86 and x86-64 (EDIT: and Itanium for the server versions). ReactOS is more of an experimental thing than a usable OS. Too many things just don't work. Wine is incomplete due to the closed nature of WinAPI and the difficulty of implementing all the undocumented features/quirks/bugs of it. So only Windows on x86/x86-64 supports WinAPI reliably.

Originally Posted by cyberfish

Modern Windows only runs on x86 and x86-64 (EDIT: and Itanium for the server versions). ReactOS is more of an experimental thing than a usable OS. Too many things just don't work. Wine is incomplete due to the closed nature of WinAPI and the difficulty of implementing all the undocumented features/quirks/bugs of it. So only Windows on x86/x86-64 supports WinAPI reliably.

Again, that statement is just wrong. Visual Studio 2008 supports all the above processors except the alpha. The incomplete implementation of the API on other OS's is more the fault of the dev community for those OS's than the API's fault. The API is fully portable, its just not Open Source, so what isn't fully implemented is the Open Source version of the API.

Originally Posted by abachler

Again, that statement is just wrong. Visual Studio 2008 supports all the above processors except the alpha.

Visual Studio supporting those platforms has no bearing as to whether the Windows API is implemented for those platforms as well. Now it could be that the entire Windows API has been implemented for those platforms (I don't know), but the fact that VS can generate code for them has no bearing towards this discussion.