|
my pleasure, thanks to you.
|
|
|
|
|
How big is a bool value?
For example an int is 4byes...
Common sense tells me its just one bit, either a 0 or a 1... but id like to know for sure. Thanks ^^
|
|
|
|
|
bool is also 4 bytes
Paul
|
|
|
|
|
Oh right, thanks 
|
|
|
|
|
pmarfleet wrote: bool is also 4 bytes
No, it's one byte.
---
single minded; short sighted; long gone;
|
|
|
|
|
|
The size of a bool is one byte.
How much memory that is needed to store a bool depends on where you store it. Variables in a class or struct are generally aligned on a four byte boundary, but if you have bools that are declared next to each other, they are aligned inside the same four byte boundary.
Example:
struct A12ByteStruct {
bool test1;
int test2; bool test3;
}
struct An8ByteStruct {
bool test1;
bool test3;
int test2; }
---
single minded; short sighted; long gone;
|
|
|
|
|
Wouldn't the compiler be smart enough to recognize this and align the bools inside the same boundary?
|
|
|
|
|
One would think so, but appearently it doesn't. Perhaps it will in future versions.
---
single minded; short sighted; long gone;
|
|
|
|
|
Well, it shouldn't rearrange the fields.
|
|
|
|
|
Hmmm...I thought that in the managed world you weren't guaranteed the order in a struct. That is why most structs used for P/Invoke calls needs the [StructLayout(LayoutKind.Sequential)] attribute so it told the compiler not to rearrange the fields.
|
|
|
|
|
I concur.
The order is not specified, unless you use LayoutKind.Sequential or explicit offsets.
AFAIK the padding is also not specified.
Nevertheless there must be some mechanism to let different CLR languages work together
on the same structs. Do they all use the same conventions, or is the JIT taking into
account some available metadata ?
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Apparently, I was only partially correct. According to the MSDN docs:The members of the object are laid out sequentially, in the order in which they appear when exported to unmanaged memory. The members are laid out according to the packing specified in StructLayoutAttribute.Pack, and can be noncontiguous.
And the docs for StuctLayoutAttribute.Pack say:This field indicates the packing size that should be used when the LayoutKind.Sequential value is specified. The value of Pack must be 0, 1, 2, 4, 8, 16, 32, 64, or 128. A value of 0 indicates that the packing alignment is set to the default for the current platform.
The default packing size is 8, except for unmanaged structures that typically have a default packing size of 4. So, it sounds like as long as the struct stays inside managed code, the fields are packed along an 8 byte boundary, but if the struct is exported to unmanaged code and has LayoutKind.Sequential set it is exported in the order in which they appear in the definition.
|
|
|
|
|
Hi Scott,
thanks for clarifying this.
On the same MSDN page it says "The common language runtime uses the Auto layout value
by default. To reduce layout-related problems associated with the Auto value, C#,
Visual Basic, and C++ compilers specify Sequential layout for value types."
So they know how to act smart, but choose not to do that by default!?
Seems to me Auto should be the default, and a warning should be given when a struct
gets P/Invoked without an explicit LayoutKind specification (so explicitly saying Auto
or Sequential or Explicit would suppress the warning).
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Sequential is the default for structs, Auto must be the default for classes.
Confusing documentation.
|
|
|
|
|
My bad. I thought that only controlled whether or not fields were packed together.
On the other hand:
"
C#, Visual Basic. NET, and C++ compilers apply the Sequential layout value to structures by default.
"
|
|
|
|
|
PIEBALDconsult wrote: C#, Visual Basic. NET, and C++ compilers apply the Sequential layout value to structures by default.
Yes, but...according to the MSDN docs:
The members of the object are laid out sequentially, in the order in which they appear when exported to unmanaged memory. The members are laid out according to the packing specified in StructLayoutAttribute.Pack, and can be noncontiguous. And the docs for StuctLayoutAttribute.Pack say:This field indicates the packing size that should be used when the LayoutKind.Sequential value is specified. The value of Pack must be 0, 1, 2, 4, 8, 16, 32, 64, or 128. A value of 0 indicates that the packing alignment is set to the default for the current platform.
The default packing size is 8, except for unmanaged structures that typically have a default packing size of 4. So, it sounds like as long as the struct stays inside managed code, the fields are packed along an 8 byte boundary, but if the struct is exported to unmanaged code and has LayoutKind.Sequential set it is exported in the order in which they appear in the definition.
It definately seems like they could have made the explanation a lot clearer.
|
|
|
|
|
In other words; "Pay no attention to the man behind the curtain."
I think the main thing is that the compiler won't reorder struct fields unless you tell it it may (with LayoutKind.Auto).
|
|
|
|
|
Well, how big a bool would you like? I could get you one from as small as one byte all the way to avaliable memory. 
|
|
|
|
|
I am developing an MDI application in Visual Studio 2005 and I would like to capture the key down events in a menustrip control. For some reason, the keydown event does not fire no matter what keys I press while the focus is on the menustrip control. If I press the left arrow, I do move to the left on the strip, right arrow moves to the right, etc., but the keydown event does not fire. Can anyone tell me what I need to do to ensure the MenuStrip's keydown event fires?
Thank you...
|
|
|
|
|
Ok, I have a button event, that when I fire it needs to chedk the states on several CheckBoxes and a pair fo RadioButtons.
What I trying to understand is how to set the events to fire after I click the button.
Currently when I make a change to one of the CheckBoxes or RadioButtons, it is firing the event under that control.
private void btnFind_Click(object sender, System.EventArgs e)
{
try
{
int StartPosition;
StringComparison SearchType;
if (chkMatchCase.Checked == true)
{
SearchType = StringComparison.Ordinal;
}
else
{
SearchType = StringComparison.OrdinalIgnoreCase;
}
StartPosition = mMain.rtbDoc.Text.IndexOf(txtSearchTerm.Text, SearchType);
if (StartPosition == 0)
{
MessageBox.Show("String: " + txtSearchTerm.Text.ToString() + " not found", "No Matches",
MessageBoxButtons.OK, MessageBoxIcon.Asterisk);
return;
}
mMain.rtbDoc.Select(StartPosition, txtSearchTerm.Text.Length);
mMain.Focus();
btnFindNext.Enabled = true;
mMain.rtbDoc.Select(0, 0);
mMain.rtbDoc.ScrollToCaret();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message.ToString(), "Error");
}
}
I want to be able to Change the CheckBoxes or RadioButtons and not make the event fire underneath.
Thanks,
|
|
|
|
|
Add a boolean field to your class that is normally false.
In the Click event handlers for the items, check the boolean.
If it's false, set it to true and perform the processing, then set it back to false.
If it's true, do nothing.
|
|
|
|
|
For the handles, use the CLick method vice CHeckChanged?
|
|
|
|
|
|
Image img;
DataPhoto = new Byte[File.ContentLength];
img=Image.FromStream(DataPhoto);
the above code convert Byte to Image
my quastion how to convert image to Byte ???
Palestine
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
