C / C++ / MFC

CPallini17-Jan-09 6:50

17-Jan-09 6:50

Have a look at the 'two processes message queue' project in the 'gimme codez urgent' section of the website www.cpallini.free.productz.com.
Smile | :)

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]

Luc Pattyn17-Jan-09 7:34

17-Jan-09 7:34

... and if you don't trust that site, just search CodeProject. Most of the articles on CP
have been scrutinized by golden boys.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).

CPallini17-Jan-09 9:22

17-Jan-09 9:22

Luc Pattyn wrote:
... and if you don't trust that site

Are you communist?
-- Bob Roberts, 1992.

Big Grin | :-D

Luc Pattyn17-Jan-09 9:32

17-Jan-09 9:32

I'm not running for the senate. WTF | :WTF:

Luc Pattyn [Forum Guidelines] [My Articles]

I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).

CPallini17-Jan-09 9:43

17-Jan-09 9:43

I (Bob) am running for the Senate, you are the interviewer. Poke tongue | ;-P

Luc Pattyn17-Jan-09 9:55

17-Jan-09 9:55

What is the essence of your program?
Will it be ready in time? and within the budget limits?
What is your main problem?
(Please provide answers to each question in less than 14 seconds)

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).

Luc Pattyn17-Jan-09 9:57

17-Jan-09 9:57

Sorry, time is up.
Capitol Hill will not be yours, try Porta Vittoria instead.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).

CPallini17-Jan-09 22:30

Problem with record reading from a binary file

17-Jan-09 22:30

Oh, you communist looser... I (Bob) am actually not able to answer your questions, anyway I will win, 'cause I'm a true american patriot!

BTW Are you a terrorist?
Laugh | :laugh:

BTW2: welcome in the THHB[^], Luc!
Smile | :)

Umer Aziz17-Jan-09 1:05

Umer Aziz

17-Jan-09 1:05

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

Garth J Lancaster17-Jan-09 1:10

Garth J Lancaster

17-Jan-09 1:10

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'

Stuart Dootson17-Jan-09 1:16

Stuart Dootson

17-Jan-09 1:16

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[^].

Luc Pattyn17-Jan-09 4:24

17-Jan-09 4:24

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.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).

Umer Aziz17-Jan-09 18:21

Umer Aziz

17-Jan-09 18:21

Thanks to All of you, for prompt response

Blum-Blum-Shub

RomTibi17-Jan-09 0:04

17-Jan-09 0:04

I need a "Blum-Blum-Shub" PRNG implementation in plain C. Knows someone where I can find this stuff? Confused | :confused:

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

Garth J Lancaster17-Jan-09 0:30

Garth J Lancaster

17-Jan-09 0:30

http://www.mindspring.com/~pate/crypto/chap05/blumblum.c[^]

5 secs with Google - learn to use it

'g'

RomTibi17-Jan-09 2:55

17-Jan-09 2:55

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

Garth J Lancaster17-Jan-09 15:39

Garth J Lancaster

17-Jan-09 15:39

not very bright are you - maybe you should give up comp-sci and flip burgers for a living ?

its a long integer package - another 5 secs with google finds :-

http://math.albany.edu:8010/g/Math/Comp/cas/freelip.html[^]

http://www.lehigh.edu/~bad0/snfs773/lip.h[^]

ftp.ox.ac.uk:/pub/math/freelip/freelip_1.0.tar.gz

I'll try and be nicer in future if you try being smarter - deal ?

'g'

RomTibi17-Jan-09 22:39

17-Jan-09 22:39

Thanks! I found it! Smile | :)

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

RomTibi18-Jan-09 7:55