Printable View
Is it fair to say that the Win API contains all of the methods that the C languages contain collectively and it would be faster executing the API commands directly Vs. the methods provided by the languages?
Does that then for all intents and purposes make the Methods practically Macros to the API?
Cy
The Windows API builds upon the standard C API. Some C functions on Windows may be implemented in terms of the Windows API, but on the whole I would expect the reverse to be true. For the sake of portability, if a function is provided by both Windows and standard C, you should generally stick to the standard API where possible.
Windows API is a language-independent call interface to Windows OS functionality.Quote:
Originally Posted by Cy_
C language is an abstract and OS-independent programming language that has nothing common with OS API. A hint: the C runtime, that is taken for a kinda integral part of C language very often, is just a library that interfaces with particular OS.
And finally, it would be absolutely fair to admit that the issues of program efficiency and performance have generally nothing to do with both.
It's always good to take a look at some (Visual C++ in particular) C runtime implementation to get rid of the questions of the kind. At least for some time. ;)Quote:
Does that then for all intents and purposes make the Methods practically Macros to the API?
Cy
Well, thanks for the responses so far. Here's what raised the questions for me in the first place.
In C#, you have StreamWriter and then, in API there's EM_STREAMOUT Message.
Now, isn't StreamWriter a macro of sort to EM_STREAMOUT?! I haven't checked but doesn't StreamWriter end up using EM_STREAMOUT? In fact doesn't every method end up sending API messages and so utilizing the API messages directly shouldn't be more efficient?
Well C/C++ comparing to C# are totally different in their nature. So C#/.NET forums belong with your question about .NET guts much and much better.
Besides, the fact that some high-level library function ends up in particular WinAPI call in a particular case never means you should throw the library out and go with plain API. Typically, you trade a little bit of performance degradation for a huge development speedup, and only very specific tasks can make you give the high-level library up.
Another point is that you must be really good at low-level WinAPI programming to benefit from using it.
But... you really need to get some experience in plain WinAPI to understand the high-level libraries better.
Thanks Igor, that makes sense. The programing languages do facilitate getting the job done but I'm growing a lot of interest for the API and, like the idea of learning what goes on behind the scene as well as getting closer to the machine that could save me a few milliseconds which means a lot for my purpose.
It's nice to confirm I wasn't on the wrong track...
Cy
If you really need to get close to the machine then you might prefer a lower-level language, like C or FORTH, or possibly even assembly. However, I doubt that you do (although of course it's still worth it for educational purposes).
I just want to mention that switching to assembler with the purpose of getting higher performance is not so true these days anymore. The modern C++ compilers are pretty good at generating assembler and will most of the time outperform any hand coded assembler unless you are very very good at writing assembler.
I would not be so confident, at least in the very particular case you mentioned.Quote:
Originally Posted by Cy_
From MSDN:
Quote:
StreamWriter class
Implements a TextWriter for writing characters to a stream in a particular encoding.
As for me, there's not a faintest relation between the two. :)Quote:
EM_STREAMOUT Message
--------------------------------------------------------------------------------
The EM_STREAMOUT message causes a rich edit control to pass its contents to an application–defined EditStreamCallback callback function. The callback function can then write the stream of data to a file or any other location that it chooses.
This is one of the points that I had in mind being saying "you must be really good at low-level WinAPI programming to benefit from using it."Quote:
Originally Posted by Marc G
I don't know about C++ — it has a fair amount of overhead stemming from the book-keeping involved in the extra features. Depends on the compiler, of course. For C that's certainly true, and for FORTH even moreso, since it's closer to the machine (and yet manages to be less cumbersome to write, hmn).
Don't underestimated the modern C++ compilers. I would encourage you to give it a try ;)
As I said, it does depend on the compiler :) I remember g++ used (a month or so ago) to be significantly behind gcc in most benchmarks, but it seems that's no longer the case. Either the g++ folks did some good work in that time or else the benchmarks are even screwier than we thought :)
Writing directly in assembler involves different techniques. An example, writing a loop in C requires to handle a memory location holding the loop variable, while writing it in assembler keeps the loop variable directly in the EBX register, requiring no memory access at all.Quote:
Originally Posted by Marc G
Also the C language will need explicit comparisons to end the loop, while in the assembler language they're performed internally by the processor.
It's a big difference. Try to process all the pixels on the screen using a C program, the program will be simply unusable. Try to do the same using assembler and you'll get the results virtually instantly.
That's not entirely true. Remember that the C code is compiled down to assembly eventually. The situation you mention is exactly the kind that a smart C compiler can easily spot and optimise to the assembly you've described.
The difference between code generated by a modern C compiler and code written by hand is small enough that ‘simply unusable’ vs. ‘virtually instant’ will never occur in smart code. Of course, if naïve code is written, it's anybody's guess — it's possible to write stupid code in assembly that takes a hundred times longer to run than smart code in C, too. :)