|
jkirkerx wrote: I learned from experience that a customer will call me and say that's not the size of the file, and start asking all kinds of questions, so I want to get it right
Keep in mind that a megabyte is 10242 bytes, not 10002. You also have to take into consideration the actual size of the file vs. the number of bytes that it consumes on disk. If your customer is looking at one and you are reporting the other, ...
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 21-Nov-11 16:58pm.
|
|
|
|
|
So my calculation is correct, but I just fell into the customer category, thus asking all kinds of questions.
Could you point me someplace where I can take the lesson?
I would like to show the customer the 767 value, and keep the other value to myself. It's just for decorative purposes.
|
|
|
|
|
That was a brain twister, required a Jeopardy question
(1000*1000) because it was already bytes, and I was just rounding it down.
Thanks Dave
|
|
|
|
|
0x2d76c718 is exactly 762758936 and dTotal = 727.423606, I see no contraddiction, here.
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]
|
|
|
|
|
I think when I got the value out of debug, I copied the value after conversion. My bad.
I don't have the experience or knowledge to read the long value yet.
|
|
|
|
|
You have asked the eternal question that will plague normal people and engineers until the end of time.
How Big Is 1K?
Normal people will say 1K = 1000, engineers will say 1K = 1024.
However, what if I told you the units were dollars? Why is it that nobody is confused if I say $1K?
Computer people use 1K = 1024, 1M = 1024*1024, 1G = 1024*1024*1024, etc. This is because they are used to using computer terminology where everything is a power of 2.
Everybody else, including Hard Disk manufacturers use the standard metric system definition of 1K = 1000, 1M = 1000*1000, and 1G = 1000*1000*1000.
So, if you ask Microsoft how big the file is, they will answer you using 1024 as the base, they are computer people. Also, hard drives are formatted into sectors that, regardless of the actual sector size, will contain 512 bytes of user data. So disk drive allocations will be expressed in powers of 2 simply because of this.
Finally, Performance Engineers will describe performance of computer systems using terms such as Megabytes per Second (MB/Sec) and that will be in base 10, 1000*1000 because, as a rate, you are talking about how much data is being moved, not the "chunk size" of the movement.
I am a computer software engineer doing performance work on disk drives. You can see I flip between numbering systems all the time. Keeps me on my toes.
And, by the way, this propensity of computer systems to use 1 Kilobyte to be 1024 has caught the attention of the international standards organizations that deal with Metric systems. As you'd expect, they are annoyed by computer people ursurping one of their definitons that has been around for a hundred years or so. So they have come up with new definitions for the stuff that's based on powers of 2, Kibibyte a "binary kilobyte".
http://en.wikipedia.org/wiki/Kibibyte[^]
So the eternal struggle continues
|
|
|
|
|
Oh, I had no idea that there was a holly war between 1024 and 1000 being fought today. I would of never know if it wasn't for the c++ programming I dove into.
I finally figured out Dave's statement, and realized that the value I already had was the Microsoft format, and I just had to do 1000*1000, so thats where the 5% loss came from, the extra 24.
That was an excellent and en-lighting explanation, and deserves a 5. Now when my friends try to talk about the subject, I can think of your explanation. Oh, maybe that's why disk drives format less than the size printed on the label.
Thanks
|
|
|
|
|
As you used 1024*124=1048576 instead of 1 million, the difference is actually 4.8576%, to be precise 
|
|
|
|
|
It adds up with larger file sizes
|
|
|
|
|
How can I get the size of a scroll bar? In case, Width from vertical scroll, and Height from Horizontal scroll bar. They're windows DEFINES?
Omar - VC++ Programmer
|
|
|
|
|
Hi,
Have a look at the GetSystemMetrics function[^]. You probably need the SM_CXVSCROLL and SM_CYHSCROLL indexes.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks, its works
Omar - VC++ Programmer
|
|
|
|
|
Hi all,
I am getting some "Access violation writing " for memset for every 30 min after i run my application.
And the cursor goes to the below line:
memset(pSharedBuffer2, 0, sizeof(*pSharedBuffer2));
Here is the function i am using i am trying,and this function i am calling in timer:
#define BUF_SIZE 2048
const int max_msg = 2048;
char *pSharedBuffer2 = (char*)malloc(max_msg);
int WriteToShared()
{
HANDLE handleMappedFile;
LPVOID lpMsgBuf;
handleMappedFile = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, HIWORD(BUF_SIZE), LOWORD(BUF_SIZE), szName4);
if (handleMappedFile == NULL)
{
printf("Could not create file mapping object.\n");
LocalFree( lpMsgBuf );
}
memset(pSharedBuffer2, 0, sizeof(*pSharedBuffer2));
pSharedBuffer2 = (char*)MapViewOfFile(handleMappedFile, FILE_MAP_ALL_ACCESS, 0, 0, BUF_SIZE);
if (pSharedBuffer2 == NULL)
{
printf("Could not map view of file.\n");
CloseHandle(handleMappedFile);
}
sprintf(i,"%d",Test);
addMsg1(i, pSharedBuffer2);
return 0;
OnTimer()
{
WriteToShared()
}
}
Can anyone guide,whats exactly going wrong.
Thanks
Sharan
|
|
|
|
|
may be give
memset(pSharedBuffer2, 0, max_msg );
|
|
|
|
|
manju 3 wrote: memset(pSharedBuffer2, 0, sizeof(*pSharedBuffer2));
That is probably NOT what you intended to do, because it sets just 1 byte (sizeof(char) is ONE). Did you mean
memset(pSharedBuffer2, 0, max_msg);
?
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]
|
|
|
|
|
Hi,
Thanks for your reply.Even i tried with
memset(pSharedBuffer2, 0, max_msg);
but getting the same "access violation for writing"
Thanks
Sharan
|
|
|
|
|
What is i (i.e. how is it declared/defined?)?
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]
|
|
|
|
|
CPallini wrote: What is i
"i" is a flag may be 0 or 1.
i am making it 0 initially,and later making it 1 and writing to shared memory
|
|
|
|
|
Then
sprintf(i,"%d",Test);
is evil (sprintf assumes i is an array of characters).
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]
|
|
|
|
|
and what is addMsg1() and what does it do? It is blowing up in there?
Also, you have a macro that defines to 2048 and max_msg that is set to 2048 and then use both in the code, interchangably. Pick one and use it exclusively otherwise you'll get bit one of these days.
|
|
|
|
|
You arent checking the return form malloc for a valid allocation.
==============================
Nothing to say.
|
|
|
|
|
manju 3 wrote:
pSharedBuffer2 = (char*)MapViewOfFile(handleMappedFile, FILE_MAP_ALL_ACCESS, 0, 0, BUF_SIZE);
This doesn't really make a lot of sense since you are just copying the pointer, not the contents!
First, you overwrite the only pointer to a memory block on the heap that you allocated with malloc, so you create a memory leak, right there.
Second, while the pointer is global and will survive the call to WriteToShared, the HANDLE you get from MapViewOfFile() will not: at the latest, it will be invalidated when you leave the function, upon which your handleMappedFile gets destroyed. At that point, pSharedBuffer2 will point to garbage! The address stored therin is invalid, and you may not access this memory. And this, exactly, happens, when next you call memset! That is your crash.
|
|
|
|
|
Hi,
thanks for your reply,
so how can i avoid the memory crash now.
thanks
sharan
|
|
|
|
|
Easy: don't call memset!
Two possibilities:
1. if you don't use pShardedBuffer2 outside this function, then (a) declare it inside the function as a local parameter and (b) don't malloc, and don't memset (in this case I really don't know what you do that for)
2. if you do use it elsewhere, then you must copy the data, not the pointer! You should be aware though, that changes to that copy won't affect the original data, you can use that copy only to read from! Anyway, if you copy data to your buffer, memset is not required - the value you set your buffer to gets overwritten anyway!
Note that I have no idea how to go about copying the data, as MapViewOfFile returns a HANDLE, not a string, and does not provide any information about the structure or size of that data. Accessing it like a string sounds like calling for trouble, especially if there are 0 bytes within. I'm not familiar with this function or the data structure it delivers, but I suggest you read up on it and how to use it properly.
What you need to do may also depend on how you use the data later, such as in your call to addMsg1(). What does it do?
|
|
|
|
|
Hi
How to change the background color of CIPAddressCtrl .
Thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
