Hi ladies and gents,

Wanted to ask a simple question probably for you guys and the answer will maybe be simple aswell, but, I thought, what the heck, I'll go for it :)

It just seems strange that when everyone tells to use <iostream> instead of <iostream.h>, <cstdlib> instead of <stdlib.h>, etc... that this is not the case for <windows.h> ?

Is there a particular reason for this?

I know it's not really important, but, I really am curious as to know what is the reason for not changing this.

Thanks.

Because windows.h isn't part of either standard.

The standards committees can only decide what the standard header files should be called.

Thanks Salem, but if it doesn't belong to either standard, too what does it belong then?

Well it's specific to win32 windows machines.

A near equivalent for say unix would be unistd.h

Other operating systems have their own header files.

also, windows.h doesn't define any c++ classes -- pure C, although you can use in in c++ programs. If the .h extension really bothers you then you could create your own file without the extension and have it call windows.h

Oh, I get it now, this means that when I or anyone else use <windows.h> it wouldn't be portable to any other type of OS.

Then, what would you use in replacement of <windows.h> so you could write code and use it on different OS?

It wasn't about being bothersome AD, I was just curious as to why it still had an .h extension while other headers in C++ don't use .h extensions anymore.

Thanks for the explanation guys.

Then, what would you use in replacement of <windows.h> so you could write code and use it on different OS?

depends on the operating system. There are libraries that are pretty much portable between *nix, MS-Windows, and (I think) MAC, for example QT.

depends on the operating system. There are libraries that are pretty much portable between *nix, MS-Windows, and (I think) MAC, for example QT.

are the programs created using the windows port ofQT portable?

Yes because they will contain no windows-specific function calls. You should be able to port it to *nix version of QT without any code changes, assuming you did not make any os-specific function calls outside what QT gives you.

This article has been dead for over six months. Start a new discussion instead.