because I don't know what it does and it needlessly makes my executable bigger.
i just want to use 1 or 2 functions anyway such as sleep(), why does c++ make it necessary to include the whole header file for a single function anyway?
Isn't there a yield() function, that does the same thing as SwitchToTHread() and exists on windows and *n*x?
It should need a less "global" header than windows.h
well what I mean is hogging cpu as reported in task manager.
Yes, I know what you mean. Your program is using all that CPU time because it needs it. If you do anything to make it use less, you'll just make it slower.
I don't know what it does
It declares Windows API functions.
needlessly makes my executable bigger
This is false.
why does c++ make it necessary to include the whole header file for a single function anyway?
Each function declaration has modifiers that the compiler uses to be able to properly link to the system library. Some functions take data types that declared only in other Windows headers.
well there should be a #pragma search "windows.h" or something of that nature to make windows.h available but only include/search files included in windows.h if it encounters an unknown data type and then only compile the necessary code when found.
I don't know about the internals of a C++ compiler, but what makes you think it is not working like that already? As mentioned above, it is a false statement to say the inclusion of Window.h increases the size of the final executable. I think the compiler includes only the necessary symbols, not all of them (or is this a linker optimization?). In any case, I bet one or two of this thread's followers can probably clear this up.
wtf - are you talking about a debug or release build?
If you're using VC++, I think the debug build will link the whole compliation unit/obj file that a function is found in, whereas the release build goes to the trouble of chopping objs up into individual functions and only linking in the required ones (if you have Enable Function Level Linking enabled).
But I don't know if gcc supports Function Level Linking.
well there should be a #pragma search "windows.h" or something of that nature to make windows.h available but only include/search files included in windows.h if it encounters an unknown data type and then only compile the necessary code when found.
If only compilers were magical!
ok well then I meant to say #include <iostream>
>makes my executable unneccessarily bigger
.
That's false as well. What's using all that space is the code necessary to support all the features iostream provides.
How can I define my own my_cin and my_cout without using <iostream>?
What makes you think your implementation will be more compact that the one provided by the library writers?
Are you by any chance using MinGW? Some older versions generated rather large executables when iostream was used, so a Hello World could compile to a 500 KiB executable. Newer versions instead link dynamically to the runtime. The code is still there. It's just not copied onto every executable that needs it.
What makes you think your implementation will be more compact that the one provided by the library writers?
Does someone know for all Standard C++ libraries/compiler makers their implementation need to pass some performance guarantees before they can be released for public developers to use? This performance guarantees ensure the programs written using those provided achieve certain performance efficiencies ?
Does this then explain for the smaller number of Standard C++ libraries/compiler that is available currently ?
I meant that last post half as a joke. But seriously I would still like to know whats going on inside the software that I write. When I open up <windows.h> or virtually any other standard header file all i see is a bunch of #defines and a few #includes. This can't be all of the source code can it? Where's the rest?
One of my former colleagues had gotten himself on the scheme. He had a dongle which permitted him to access the Windows source. But I only ever got to look over his shoulder a couple of times!
I just thunk of something. Is it ever safe to use Sleep[0]; ?
I was in the process of changing certain constants used in my program to global constants to aid quick tweaking. Say I have this code that outputs data to the console, but I want to cout it slower than normal I can put a statement such as Sleep[pause_time]; in a for loop. And later if I decide that its pausing too much time, or if I don't want to pause at all, just change the global const pause_time to whatever or 0 respectively.
Would it be safe to use Sleep[0] if I'm not necessarily worried about making sure that another process gets queued ahead of mine?
Calling Sleep(0) is not the same as not calling Sleep() at all, except when the calling thread has highest priority. For lower-than-highest priorities, Sleep(0) is like saying Sleep(epsilon). A pause for an indeterminately short amount of time.
If you want to make it so that Sleep(0) does nothing, it'd be better to write a wrapper: