[Dev-C++] unsubscribe

[<sor...@mu...>]

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...]On Behalf Of
dev...@li...
Sent: 2002. június 11. 21:03
To: dev...@li...
Subject: Dev-cpp-users digest, Vol 1 #815 - 6 msgs


Send Dev-cpp-users mailing list submissions to
	dev...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
or, via email, send a message with subject or body 'help' to
	dev...@li...

You can reach the person managing the list at
	dev...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dev-cpp-users digest..."


Today's Topics:

   1. Re: unsubscribe unsuscribe (Hongli Lai)
   2. (no subject) (balamurali  muraleedharan)
   3. doubt (balamurali  muraleedharan)
   4. double no double query (Daniel Glenfield)
   5. Re: doubt (Abhijit Shylanath)
   6. Re: doubt (Mac Reiter)

--__--__--

Message: 1
Subject: Re: [Dev-C++] unsubscribe unsuscribe
From: Hongli Lai <h....@ch...>
To: "Garcia Sanchez, Jesus  "Angel <jag...@in...>
Cc: Dev...@li...
Date: 11 Jun 2002 14:47:18 +0200

On Tue, 2002-06-11 at 13:32, Garcia Sanchez, Jesus Angel wrote:
>
> unsubscribe
> unsuscribe
>

Have you ever read the *unsubscribe instructions* on the website....?

Here's a hint:
http://devcpp.everfloyd.com/help.html

Perhaps I should make the sentence "If you want to know how to
unsubscribe from this list, go to this page!" blinking and 1000 pixels
big.




--__--__--

Message: 2
Date: 11 Jun 2002 13:54:01 -0000
From: "balamurali  muraleedharan" <bal...@re...>
Reply-To: "balamurali  muraleedharan" <bal...@re...>
To: dev...@li...
Subject: [Dev-C++] (no subject)

confirm 399103
_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or
Abroad
http://monsterindia.rediff.com/jobs



--__--__--

Message: 3
Date: 11 Jun 2002 13:55:43 -0000
From: "balamurali  muraleedharan" <bal...@re...>
Reply-To: "balamurali  muraleedharan" <bal...@re...>
To: dev...@li...
Subject: [Dev-C++] doubt

Sir,
I know that when u open an image file in the text mode we cant see
the image but when we open it in binary mode we should be able to
read the data from it and store it in any structure.Since this is
what my doubt is all about I present it here.

struct bitmapfileheader
{
short int signature;/*2bytes*/
int filesize;/*4bytes*/
int reserved;/*4bytes*/
int dataoffset;/*4bytes*/
};

int main()
{
bitmapfileheader bmpf;
cout<<sizeof(bmpf);
}
here the result shows the size as 16bytes instead of 14bytes
also while reading into this structure using file.open and
file.read statement always wrong data is contained in the
structure where the read data is stored.Why is this so?
There is error only while reading into the structure as a whole as
in the case
file.open("file.bmp",ios::binary|ios::in);
file.read((char*)&bmpf,sizeof(bmpf));
This always reads erroneous values into the corresponding elements
in the structure.But
file.open("file.bmp",ios::binary|ios::in);
file.read((char*)&bmpf.signature,sizeof(bmpf.signature));
file.read((char*)&bmpf.filesize,sizeof(bmpf.filesize));
file.read((char*)&bmpf.reserved,sizeof(bmpf.reserved));
file.read((char*)&bmpf.dataoffset,sizeof(bmpf.dataoffset);
this reads the correct values into the respective elements of the
structure.
why is this so?
why cant we simply read the contents of the file into the
structure using the first statement?what really happens during
this process?
I am using G++ in Linux environment.
Please help me.
_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or
Abroad
http://monsterindia.rediff.com/jobs



--__--__--

Message: 4
From: "Daniel Glenfield" <sp...@ho...>
To: dev...@li...
Date: Tue, 11 Jun 2002 15:27:33 +0100
Subject: [Dev-C++] double no double query

if you are using the same object to write multiple variables into the text
document try destroying the object then re-creating it before you do the
next one.

It's a bit like the following.

e.g.
[code]
/**
	    Object with local scope
	    Notice how the strstream object is created with local scope. Local
scope
	    ensures the object is destroyed, then created the next time it
	    is needed. This has the effect of making sure that no previous
	    values will be carried forward to the next usage of the object.
	    */
		{  // Display X Resolution
		   strstream StrstreamObject;
	       StrstreamObject << "XResolution: " << m_nXResolution << '\0';
	       pListbox->AddString(StrstreamObject.str());
	       StrstreamObject.rdbuf()->freeze(0);
		}

		{  // Now for the Y resolution
		   strstream StrstreamObject;
	       StrstreamObject << "YResolution: " << m_nYResolution << '\0';
	       pListbox->AddString(StrstreamObject.str());
	       StrstreamObject.rdbuf()->freeze(0);
		}

[/code]

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



--__--__--

Message: 5
From: "Abhijit Shylanath" <mu...@gm...>
To: <dev...@li...>
Subject: Re: [Dev-C++] doubt
Date: Tue, 11 Jun 2002 21:05:47 +0530
Organization: Retrogression

AFAIK, GCC (and derivatives) don't store structures linearly, they pad the
elements for optimization reasons. So if you want to read in stuff, you'll
have to read them in separately.

I think there's a command-line option somewhere to disable this behaviour...
Over to you, <put_your_name_here>.

--------------------------
http://mudeth.tripod.com

----- Original Message -----
From: "balamurali muraleedharan" <bal...@re...>
To: <dev...@li...>
Sent: Tuesday, June 11, 2002 7:25 PM
Subject: [Dev-C++] doubt



> int main()
> {
> bitmapfileheader bmpf;
> cout<<sizeof(bmpf);
> }
> here the result shows the size as 16bytes instead of 14bytes
> also while reading into this structure using file.open and
> file.read statement always wrong data is contained in the
> structure where the read data is stored.Why is this so?
> There is error only while reading into the structure as a whole as
> in the case
> file.open("file.bmp",ios::binary|ios::in);
> file.read((char*)&bmpf,sizeof(bmpf));
> This always reads erroneous values into the corresponding elements
> in the structure.But
> file.open("file.bmp",ios::binary|ios::in);
> file.read((char*)&bmpf.signature,sizeof(bmpf.signature));
> file.read((char*)&bmpf.filesize,sizeof(bmpf.filesize));
> file.read((char*)&bmpf.reserved,sizeof(bmpf.reserved));
> file.read((char*)&bmpf.dataoffset,sizeof(bmpf.dataoffset);
> this reads the correct values into the respective elements of the
> structure.
> why is this so?
> why cant we simply read the contents of the file into the
> structure using the first statement?what really happens during
> this process?
> I am using G++ in Linux environment.
> Please help me.




--__--__--

Message: 6
Date: Tue, 11 Jun 2002 10:53:54 -0500
To: dev...@li...
From: "Mac Reiter" <re...@no...>
Subject: Re: [Dev-C++] doubt

Compilers are allowed to pack structures in memory any way they want.  The
only requirements on the compiler are that:
1. sizeof() will report the actual size
2. field access will work

x86 CPUs (386/486/Pentium/II/III/IV/etc and so on) are much more efficient
working with longs than with shorts.  More importantly, these processors
(and most others) are *MUCH* more efficient working with longs that are 4
byte aligned in memory (4 byte aligned means the memory address is evenly
divisible by 4 -- or that the bottom two bits of the address are 0, if you
prefer to think that way).  If the compiler packed your structure tightly,
the three longs would all end up 2 byte aligned, but not 4 byte aligned,
and accessing them would take over twice as long.  Since the compiler does
not know how you intend to use this structure, it adds some padding so that
the long fields will be properly aligned.

The effective struct you end up using actually looks like this (probably):

struct bitmapfileheader
{
short int signature;/*2bytes*/
short int PADDING1;/*2bytes*/
int filesize;/*4bytes*/
int reserved;/*4bytes*/
int dataoffset;/*4bytes*/
};

That explains why you can't just read the structure directly.  Using the
stream operators to push structures/classes into streams and pull them back
out is fine, but it requires that the stream operators be used for both
operations.  In your case (reading bitmap files), the header was not
written by a stream operator, so you can't read it back out that way.

*************
It is also unwise to attempt raw structure dumping like this because the
structure layout in memory will change between compilers, and can change
even between versions of the same compiler (GCC 2.95 and GCC 3.1 have some
memory layout differences).
*************

The most "object oriented" way of handling this (which is also the
idealogically correct approach when working with stream
insertion/extraction operators), is to write operator<<() and operator>>()
member functions for your structures.  Inside those functions, you use the
code you showed below:

>file.read((char*)&bmpf.signature,sizeof(bmpf.signature));
>file.read((char*)&bmpf.filesize,sizeof(bmpf.filesize));
>file.read((char*)&bmpf.reserved,sizeof(bmpf.reserved));
>file.read((char*)&bmpf.dataoffset,sizeof(bmpf.dataoffset);

but modified to make sense inside that member function.  Actually, what
would be _even_better_ is the following:

file >> signature;
file >> filesize;
file >> reserved;
file >> dataoffset;

or possibly even (forgive me if this is in error -- I'm not a big stream
user myself...)

file >> signature >> filesize >> reserved >> dataoffset;

Since you are working with built in data types at this level, the stream
extraction operator know how to read them from the stream directly.

Once you have written those member functions, you can then insert or
extract your structure directly into or out of streams.  Any decent book on
C++ programming *SHOULD* have samples of operator<<() and operator>>(),
since it is a relatively important functionality, and one of the primary
benefits of the stream system.

If you insist on raw memory dumping, most compilers have a method of
telling the compiler to pack tightly in memory.  This is frequently done
with one of the many "#pragma" directives.  Someone with more GCC
background will have to supply the actual command, or you can get it from
the man pages.  Using these directives is inherently unportable and will
limit your code to only functioning on GCC on the particular CPU
architecture you are using, so I would recommend using the more object
oriented approach from above.

Good luck,
Mac

At 01:55 PM 6/11/02 -0000, balamurali  muraleedharan wrote:
>Sir,
>I know that when u open an image file in the text mode we cant see
>the image but when we open it in binary mode we should be able to
>read the data from it and store it in any structure.Since this is
>what my doubt is all about I present it here.
>
>struct bitmapfileheader
>{
>short int signature;/*2bytes*/
>int filesize;/*4bytes*/
>int reserved;/*4bytes*/
>int dataoffset;/*4bytes*/
>};
>
>int main()
>{
>bitmapfileheader bmpf;
>cout<<sizeof(bmpf);
>}
>here the result shows the size as 16bytes instead of 14bytes
>also while reading into this structure using file.open and
>file.read statement always wrong data is contained in the
>structure where the read data is stored.Why is this so?
>There is error only while reading into the structure as a whole as
>in the case
>file.open("file.bmp",ios::binary|ios::in);
>file.read((char*)&bmpf,sizeof(bmpf));
>This always reads erroneous values into the corresponding elements
>in the structure.But
>file.open("file.bmp",ios::binary|ios::in);
>file.read((char*)&bmpf.signature,sizeof(bmpf.signature));
>file.read((char*)&bmpf.filesize,sizeof(bmpf.filesize));
>file.read((char*)&bmpf.reserved,sizeof(bmpf.reserved));
>file.read((char*)&bmpf.dataoffset,sizeof(bmpf.dataoffset);
>this reads the correct values into the respective elements of the
>structure.
>why is this so?
>why cant we simply read the contents of the file into the
>structure using the first statement?what really happens during
>this process?
>I am using G++ in Linux environment.
>Please help me.
>_________________________________________________________
>Click below to visit monsterindia.com and review jobs in India or
>Abroad
>http://monsterindia.rediff.com/jobs
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
-
 _____________________________     /"\
 Mac Reiter                        \ /    ASCII Ribbon Campaign
 Nomadics, Inc.                     X     Against HTML Mail
 re...@no...               / \   (To join the campaign, simply use
                                          this in your signature.)





--__--__--

_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users


End of Dev-cpp-users Digest