|
Sorry but this is not the solution for my Problem. I need help with my C++-Code above. That's why i have asked in this forum and not anywhere else 
|
|
|
|
|
|
Hi,
it is a bit more complex than you seem to expect. You need Win32_NetworkAdapterConfiguration. It will return several rows, some have IPEnabled set to true; those should correspond to physical network adapters, which each can have one or more IP addresses; these are returned as a string array through IPAddress.
A little Google action should turn up sample code in the language of your choice.
|
|
|
|
|
Marcel Vogt wrote: How must i change this, to show the IP-Adressses of the Computer? Only with Changing to "Win32_NetworkAdapterConfiguration" and "IPAddress" instead of "SerialNumber" doesn't works.
I believe that using WMI is the easier but not the best option to work with IP addresses.You have entire IP helper API right here http://msdn.microsoft.com/en-us/library/aa366071(VS.85).aspx[^] which contains set of functions for IP management.For example GetIpAddrTable function will help you to examine IP-v4 mapping table.
Life is a stage and we are all actors!
|
|
|
|
|
Hey folks!
I was just wondering, which of these would be faster:
RECT R1, R2;
POINT Offset;
...
R1 = R2;
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;
or
RECT R1, R2;
POINT Offset;
...
R1.left = R2.left + Offset.x;
R1.right = R2.right + Offset.x;
R1.top = R2.top + Offset.y;
R1.bottom = R2.bottom + Offset.y;
As a "sub question of this", would this:
R1.left += Offset.x;
R1.right += Offset.x;
R1.top += Offset.y;
R1.bottom += Offset.y;
be faster than this:
R1.left += Offset.x;
R1.top += Offset.y;
R1.right += Offset.x;
R1.bottom += Offset.y;
? I mean, in the first version when the first addition is done Offset.x is already loaded into one of the registers so the second addition needs less memory access, while in the second version, it would need to retrieve Offset.y to do the addition, then retrieve Offset.x again and then Offset.y again. In the first version it has to retrieve both Offset.x and Offset.y only once during the 4 additions, so that's half the memory access from Offset's point of view. Right? If so, I also wonder if the compiler is smart enough to change the order of these to produce a more speed optimized code (i personally highly doubt this).
Thanks for any sharing of thoughts.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <
|
|
|
|
|
The only way to find out is to write some tests, compile and run them on your system. Arguing thoretically about what's faster is fairly pointless.
Cheers,
Ash
|
|
|
|
|
I guess you have a point there...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Hey, in case you care, i wrote a little tester that uses the high performance counter to check how much it takes to do the given equations 100million times, here are the resuls, 1a being the first method, 1b being the first method with the different order and 2 being the second method:
<1a> 0.698949 sec
<1b> 0.750401 sec
<2 > 0.527537 sec
----------
<1a> 0.711031 sec
<1b> 0.701738 sec
<2 > 0.508943 sec
----------
<1a> 0.699821 sec
<1b> 0.710665 sec
<2 > 0.514772 sec
----------
<1a> 0.695679 sec
<1b> 0.693272 sec
<2 > 0.510279 sec
----------
<1a> 0.697279 sec
<1b> 0.696093 sec
<2 > 0.569204 sec
Seems like method 2 indeed wins, changing the order doesn't seem to make much of a difference (diff. between 1a and 1b).
[Edit] Tests were done with a no-optimization debug build.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
modified on Saturday, June 19, 2010 11:59 AM
|
|
|
|
|
That's interesting 'cause on three compilers (VC++2010, Digital Mars latest and gcc 4.1) I got pretty much the same execution times for all three cases (the variation between runs was of the same order as the variation between methods). VC++ and Digital Mars went a bit bonkers and optimised the entire calculation away until I did some fiddling to make sure that the results were referenced by something else.
Cheers,
Ash
|
|
|
|
|
I used a debug build to avoid optimisations, and the compiler comes from VS2003 (i know, i know, it's old...)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Doesn't switching the optimiser off defeat the idea of having an optimising compiler?
And I wouldn't worry about using VC++ 2003. It's under 10 years old and actually supports a reasonable amount of the C++ 98 standard unlike all the numpties who painted themselves into a corner using VC++ 6 and now can't move off it because they were programming to MS's standard.
Cheers,
Ash
|
|
|
|
|
As said here[^], probably the compiler modifies the code to its likes to produce the -possibly- fastest way to do it. Which kinda renders the whole question obsolete i guess, since no matter how i do it the result will be the same, or at least, which is faster will depend on the used compiler/optimization method.
So i'd say, turning off optimizations is only important from the "hypothetical question's" point of view.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Aescleal wrote: Doesn't switching the optimiser off defeat the idea of having an optimising compiler?
And the whole point of a speed test, I would say.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Wrong. The only way is to create the .COD file and see what the compiler generates for that code, then with a debugger, see what load time optimization may be done during loading. It is this final machine code that tells the story during execution.
Dave.
|
|
|
|
|
CAVEAT: This doesn't apply if you're talking about embedded systems where you have a greater degree of control over what's running.
On your average desktop looking at an assembly listing won't tell you how fast a piece of code runs. It might give you an idea, might even tell you some idea of the relative speed [1] and where you could speed it up if you wanted to manually code it but won't tell you how fast it actually runs.
As for "load time optimisation" I'm not sure what you mean in this context but load time shouldn't be a factor in measuring how fast a particular lump of code runs. Load time is long over by the time you start measuring how fast a particular piece of code runs.
Cheers,
Ash
|
|
|
|
|
2
no
|
|
|
|
|
In case you care, here[^] are some test results, seems like you are right. 
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Thanks. I had already seen your other message. You should make clear what build you used (debug/release) and what optimization level, it may be relevant, not to the outcome, but to the relative difference.
And the conclusion should be: moves are not free; try and combine them with actual calculations.
|
|
|
|
|
You may have a look at the assembly code (compile with /E option).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Yeah, i thought of that too...
I think i will just try to write a small proggie that test these methods and see which performs better.
Thanks for your answer.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
both compiled down to the same code for me.
|
|
|
|
|
Try with optimizations turned off.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
|
That's odd...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
In case you care, i did the testing, here are[^] the results.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
