|
I have compiled the following program in MS Visual C++ 6.0
Its strange for me to know the output of the program.
#include <stdio.h>
struct struct1
{
int i;
};
struct struct2
{
char s[2];
};
struct struct3
{
char s[2];
int i;
};
struct struct4
{
char s1[2];
int i;
char s2[2];
};
struct struct5
{
int i;
char s2[2];
};
int main()
{
printf("\nSize of Structure 1 = %d",sizeof(struct struct1));
printf("\nSize of Structure 2 = %d",sizeof(struct struct2));
printf("\nSize of Structure 3 = %d",sizeof(struct struct3));
printf("\nSize of Structure 4 = %d",sizeof(struct struct4));
printf("\nSize of Structure 5 = %d",sizeof(struct struct5));
printf("\n\n");
return 0;
}
The size shown by the program for structure 1 and 2 is OK. But result of structure 3,4 and 5 is mind f***ing. Why; when I declare the integer and charector in the same structer, the compiler add 2 extra bytes?
Actually i am reading the data from a binary file using the structure. But this thing has made me fool from last 2
days.
If anyone knows the reason or solution of that problem, please reply.
----------------------Output of the program-----------------
Size of Structure 1 = 4
Size of Structure 2 = 2
Size of Structure 3 = 8
Size of Structure 4 = 12
Size of Structure 5 = 8
|
|
|
|
|
if I remember correctly, the compiler adds packing bytes in certain cases to align data properly in memory
I believe there's a #pragma (PACK,<something,possibly num packing bytes/alignment > ) statement/define that can be used to change this
that may give you enough info to google/search on to see how accurate my memory is at 11pm on a Sat night ....
'g'
|
|
|
|
|
The compiler want's to align data so that it can be accessed efficiently. This generally means aligning the data on an n-byte boundary (so the address of the data is a multiple of n), or whatever it takes because processor operations are optimised for reading aligned data. What this means in practise is that integers, floats and structures are on 4 or 8 byte boundaries.
When this is applied to data in a structure, it can mean that padding is inserted to ensure that items with alignment requirements (such as integers) are correctly aligned. This is what you are seeing.
For more information, here's a Wikipedia page on the subject[^].
|
|
|
|
|
Hi,
as the others said, there is some padding going on, i.e. the compiler skips a few byte positions by inserting NULL bytes, in order to get everything "naturally aligned", meaning a struct member with size n (n=1/2/4/8) should reside at an offset that is a multiple of n.
you typically don't have to worry about this, unless:
1. you need a lot of those structs, so memory usage becomes important
2. you have a union with another struct and expect things to overlap in a specific way
3. you are going to pass the struct to some other code (is basically same as 2)
4. you need to follow a certain data layout, maybe in a file or in a byte stream to/from a device
you can get a more compact struct by:
1. using a compiler switch or a pragma to tell the compiler not to perform natural alignment (not always
a good idea)
2. reordering your struct members, biggest first (not always acceptable) unless you happen to have
one whose size isn't a power of 2 (an array, another struct!), then biggest first but filling
the gaps yourself with the smaller ones.
BTW: structs themselves also get naturally aligned in memory; assume a struct with 14 useful bytes,
but due to its layout, it reports a size of 16; even when you manage to reorganize it so it shows
size=14, it will be located at an address that is a multiple of 16, so it will most probably effectively
occupy 16 bytes after all.
|
|
|
|
|
Thanks to All of you, for prompt response
|
|
|
|
|
I need a "Blum-Blum-Shub" PRNG implementation in plain C. Knows someone where I can find this stuff?
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
|
I can't find
lip.h
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
|
Thanks! I found it!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Deal!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
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 he was kidding until I googled it for him ....
'g'
|
|
|
|
|
Some people are smarter than others... 
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Thanks!
You've got a nice child (in photo)!![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
I forget the name of Disney Character in this serial. Is It BAALU?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
No.
:laugh: BALOO
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
I want to learn how to work with threads. I tryed the MSDN example
http://msdn.microsoft.com/en-us/library/kdzttdcb(VS.80,printer).aspx[^]
and it doesn't work. I'm receiving the message:
Compiling...
th.cpp
C:\programare\th\th.cpp(46) : error C2065: '_beginthread' : undeclared identifier
C:\programare\th\th.cpp(83) : error C2065: '_threadid' : undeclared identifier
C:\programare\th\th.cpp(120) : error C2065: '_endthread' : undeclared identifier
Error executing cl.exe.
What can I do ?
In VC++6 please...
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
are you
1) including <process.h>
2) linking against the Multithreaded libraries ? (Go to Project -> Settings, and select the C \ C++ tab. Under 'Category', choose 'Code Generation', and choose the Multithreaded Static item under the 'Use run-time library:' combo.)
?
|
|
|
|
|
Now it works!
Thanks a lot!
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
When the file is first open a read all around, it take about 40s. (The file is about 100MB)
Then I re-run it, it takes less than 1s.
And I tried to read the another file in the same directory, it takes less than 1s.
(the 2nd file is about 80MB).
Is it caused by the disk cache?
But I think the os should cache contents for the file under reading,
because the file is not necessary continuous on the disk.
So how could the 2nd file be read so fast? Because the os cache files in the same directory?
In my experince, some times it seems true, and sometimes not.
Is there any guide to make good use of the cache?
And I'm going to use the file mapping mechanism, will it be much faster?
PS: The size per file is about 100MB, and total size in one directory is about 1GB.
modified on Saturday, January 17, 2009 5:14 AM
|
|
|
|
|
Well, maybe the hard disk hard gone to sleep?
Reading the first file woke it up, moved the head to the right place on the disk, then splat, fast data.
On the next read, you're already at the right place and speed, so splat once more!
There's a huge difference between data rate and seektime. Just like you can have fast bandwidth, but high lag on an internet connection.
So, under my theory, whether you use ReadFile or memory mapping is irrelevant.
Iain.
Codeproject MVP for C++, I can't believe it's for my lounge posts...
|
|
|
|
|
I've tested the two mechanisms several times fairly.
23 files, 2.05GB
When not using file mapping it takes about 250s.
Otherwise, it takes about 150s.
And your theory explains why sometimes it is slow and some times it is fast randomly.
|
|
|
|
|
followait wrote: And I'm going to use the file mapping mechanism, will it be much faster?
PS: The size per file is about 100MB, and total size in one directory is about 1GB.
If you read the whole of the file into memory at once, file mapping isn't much faster in my experience. Best thing to do is abstract the file accessing mechanism into a separate class or module, so you can change it without impacting the rest of your code. Then you can try both methods and do some objective measurement - that's the best way to tell which approach is better for your scenario.
|
|
|
|
|
I've tested the two mechanisms several times fairly.
23 files, 2.05GB
When not using file mapping it takes about 250s.
Otherwise, it takes about 150s.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
