[isha_03]

Hi
Can someone say me what is slack byte with aproper example.When u write structure , classes or union do we ned to always take care of this thing?

[janotte]

Have a read here:
http://www.cintervie...slack-byte.html
and here
http://wiki.answers....structures_in_C

I am not what you mean by "take care of".
Could you expand on what you are trying to ask?

Your teacher probably gave an explanation of what they wanted in answer to this question in the notes leading up to asking this question.
Worth reviewing your notes or text book.

[isha_03]

Actually i went through the google and saw the deftn . Found very good example how to reduce the slack byte .sharing with u below :

int main()
{
struct word1
{
char a;
int b;
char c;
} ;
struct word2
{
char a;
char b;
int c;
};
clrscr();
printf("%d\t%d",sizeof(struct word1),sizeof(struct word2));

getch();
}

on compilation:
====================
Ans:Output: 6 4



The difference is only in the struct declaration .. how char and int sequence are called .
so i asked whenever in progs i will declare struct or union or class do i need to call all char data types first then int data type .

This post has been edited by NickDMax: 09 June 2010 - 06:01 AM

[janotte]

Please edit your posting (see the "EDIT" button in lower right).
( a ) Delete all your code.
( b ) Get a fresh copy of the code with formatting in place from your editor / IDE.
( c ) Paste the formatted code between code tags like this
( d ) Use the "Preview Post" button to check it's all good.
( e ) Use the "Submit Modified Post" button to finish the editing.

-----

"void main()" is wrong. Always use "int main()".
Read here the words of the man who invented C++:
http://www.research.....html#void-main
Can I write "void main()"?
The definition
void main() { /* ... */ }
is not and never has been C++, nor has it ever been C. See the ISO C++ standard 3.6.1[2] or the ISO C standard 5.1.2.2.1.

This post has been edited by janotte: 09 June 2010 - 04:20 AM

[janotte]

isha_03, on 09 June 2010 - 07:29 PM, said:

i nedd to call all char data types first then int data type .

Why do you care about the size of your structs?
Do you have serious memory limitations?
Are you programming on an AppleII or a TRS80 or something similar?
Or do you have a modern machine with gigs of RAM?
If you have a modern machine why do you care about a byte here and there?
Are you going to be dealing with thousands or millions of structs in your program?
Do you have tight performance requirements?

Again the purpose of your question passes me by.
Why do you care?

That's why I assumed you were doing this for school.
It's the sort of unreal stuff schools like to focus on to develop deep understanding of how things work that you will probably never use (in that form) in the real world.

But perhaps I am missing the obvious.
Is there a use case where you believe a stray byte here and there will be important to you?
What is it?

[isha_03]

Nothing as such janotte , like memory byte problm but when i came across this article i thought whenever i do coding i never take care of this like char first then int ..i asked as i was curious about good coding style , becoz i am not that good in coding . It is just out of my curiousness i asked .. i dont have any used case for this.

[Banfa]

janotte, on 09 June 2010 - 10:27 AM, said:

But perhaps I am missing the obvious.
Is there a use case where you believe a stray byte here and there will be important to you?
What is it?

A stray byte, or 10, in a structure which is instantiated multiple times on a platform with limited memory (of which there are a lot) is fairly important. I admit that on modern PCs this is not the case generally but knowing the theory of how to keep your structure sizes down is never a bad thing. In fact in general having extra knowledge is not a bad thing as long as you know when to apply it.

isha_03, on 09 June 2010 - 07:29 PM, said:

i nedd to call all char data types first then int data type .

To minimise the amount of padding bytes (or slack bytes) you should arrange the members of your structure in size order. It doesn't matter if you smallest to largest or largest to smallest.

It can have other effects, for instance if you try to use memcmp to compare 2 structures with padding bytes for equality (something I have seen new C programmers attempt) because on the stack the padding bytes are not initialised and can have any value 2 structures whose members have the same values can compare as not equal if compared like this. The solution being don't use memcmp to compare structure for equality.

Apart from that the compiler pretty much takes care of it all you don't really have to take account of them just be aware that they may be there and that different platforms can have them in different places or quantities.

This also means when marshalling data for transmission to another platform, you should not marshal a structure as a unit but rather marshal its individual members.

[janotte]

Banfa, on 09 June 2010 - 08:50 PM, said:

as long as you know when to apply it.

We are in complete agreement.

isha_03, on 09 June 2010 - 08:44 PM, said:

i was curious about good coding style

The key thing to remember about code is that it is written to be read by humans.
Except for rare cases where resources are very limited or the code efficiency is paramount (often because of huge numbers of transactions) the important factor for your code is that humans can maintain it.

Generic computing hardware costs fall every month and there is almost an unlimited supply at prices so cheap that hardware is, effectively, close enough to free to be treated as if it were free.

What is expensive is the humans who write and maintain the code.

We can be left with the choice of writing code that is efficient for the hardware to run or code that is easy for a human to read and maintain.
When presented with that choice (with the rare cases put to one side for them moment) the greatest good is done by writing code that saves a human an hour of head scratching even at the cost of another few cycles of CPU time or passing extra pages in and out of memory or whatever.
Don't increase the demand on the rare and expensive resource to reduce the demand on the freely available and cheap hardware.

However, as you, and Banfa and I agree, learning about the concepts and knowing this stuff is no bad thing. One day you might encounter a case when it is useful.
But, for the most part, you can happily and safely ignore trivia like this. Certainly don't be afraid to 'waste' a few bytes or cycles if that is what makes the difference between clean and easy to read code and ugly code (again, except for rare cases).

[NickDMax]

actually these "slack bytes" as you call them can be very irritating at times. Why? Because there is no standard to them. One compiler on one computer may align to 4byte boundaries, other might align to 2 bytes, others to 16 bytes... different compilers (heck even different build settings) may do things differently.

Most of the time this does not matter and is actually a good thing because it will make your program faster. BUT there are times when the consistency is more important than speed.

Take for instance communicating between two computers or pulling records from a file. In these cases we often want our structure to look exactly as we defined it.

Many compilers (probably all of them but I don't know) offer ways to control the "packing" of structure/classes. For example:

#include <stdio.h>

typedef struct {
    char a;
    int b;
    char c;
} Struct_Unpacked;

//Set alignment to 1 byte boundry
#pragma pack(push,1)
typedef struct {
    char a;
    int b;
    char c;
} Struct_Packed1;

//restore alignment
#pragma pack(pop)


//Set alignment to 1 byte boundry
#pragma pack(push,2)
typedef struct {
    char a;
    int b;
    char c;
} Struct_Packed2;

//restore alignment
#pragma pack(pop)

#define TEST_CASE(var) printf(#var ": %d\n", sizeof(var));

int main() {
    TEST_CASE(Struct_Unpacked);
    TEST_CASE(Struct_Packed1);
    TEST_CASE(Struct_Packed2);
    //getch();
    
    return 0;
}

The output on my VC++ compiler is:

> "C:\CProjects\Forum Help\packExample.exe " 
Struct_Unpacked: 12
Struct_Packed1: 6
Struct_Packed2: 8

SO as you can see you do have the option of controlling how the "slack space" (or padding). In fact if you look though your compiler's documentation you may find that there are all kinds of ways to take control of how the compiler lays things out in memory -- Just note that these features are not part of the standard and do change from one compiler to the next (actually '#pragma pack' is pretty common, but because there is no standard no one is required to implement it, or to make it work the way you might think it is supposed to).

So anyway -- I agree that this is a good thing to learn about. You will hardly ever need to think about it, just know that the compiler does this to aid you not hinder you. Most of the time there is no worries. But sometimes it is good to know what is going on under the covers!

[Salem_c]

@isha_03
> so i asked whenever in progs i will declare struct or union or class do i need to
> call all char data types first then int data type .
To use the minimum amount of space, you would arrange the struct such that the largest elements (and thus the most restrictive alignment) are at the start of the struct.

int followed by char will always pack closer (or more accurately, never pack worse) than char followed by int.
I suppose some far-out machine could align doubles on 6-bytes, and int's on 4 bytes. But as far as I've seen, the alignment restrictions are always multiples of the previous one (1,2,4,8 kind of thing).

@janotte
> Do you have serious memory limitations?
> Are you programming on an AppleII or a TRS80 or something similar?
> Or do you have a modern machine with gigs of RAM?
Mobile phone, dvd player, toaster, microwave, car, aircraft, camera, watch......
Find something elecrical which has a UI more complicated than a light-bulb, and it's probably got a programmable device of some sort or another.
And pretty much all of them have resource constraints of one kind or another.

@NickDMax
> Take for instance communicating between two computers or pulling records from a file.
Padding and alignment are not your only problems. Endianess really makes a mess of it.
http://en.wikipedia....wiki/Endianness

The only way to reliably communicate between two hosts is to turn the whole thing into a byte stream, and document your data sizes, and indicate whether they will be sent LSB or MSB first.

Even characters can be problematic. Whilst ASCII may seem ubiquitous, EBCDIC is still around in some corners of the world.
Floating point formats can be a real minefield if you can't ensure IEEE representations.

All of which makes "pragma(pack)" as a solution to data transmission problem a non-starter IMO.

[NickDMax]

@Salem_c -- indeed. All good points. It was an example of a situation where it *might* be important to control exactly how a structure was stored in memory. Maybe it was not the best example. It was what occurred to me. My point was just to demonstrate that you can take control over the packing of structures (though not necessarily in a standard way). It was not my intention to spark a conversation on all of the intricacies of computer communication and data compatibility.

[janotte]

@Salem_c

Absolutely agree.
That's why I was asking those questions.
They weren't rhetorical, they were seeking information.
I even offered myself up at the end as a dumbo that the OP could respond to with "Well obviously I am writing for a resource constrained or performance critical environment or I would not have asked. This is why I care <reason for caring goes here>."
Although the OP didn't make that response it is good that so many have pointed out the obvious use cases I was hoping to prompt.

I was trying to highlight that without including the fact that:
- "I am writing a device driver"
- "I am dealing with millions of transactions"
- "I am writing a phone app"
- <whatever>
"and therefore every byte counts".
the question was lacking the context that would make the issues at hand clear and obvious.

As it turned out the OP was doing none of those things (as far as I can glean from the thread).
So, in the context of a modern, well equipped, PC this is not as issue worth worrying about.
But it might have been.

Good conversation isn't it.