0

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.

4
Contributors
8
Replies
9
Views
10 Years
Discussion Span
Last Post by Ancient Dragon
0

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

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

0

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

0

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.

0

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

0

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.

0

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.

0

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?

0

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 topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.