|
I am pretty sure a bool actually takes "at least 1 byte", i.e. it would take 1 byte
if you need four class fields of type bool, they would sit together and not disturb
any alignment requirements of adjacent data members. And they would occupy 1 byte
when a lot of them are stored in an array.
In most other cases they would end up taking more bytes, often 4 (or even 8 on Win64);
and when boxed into a Collection, they would grow from 1 to 40/44: alignment grows them
from 1 to 4, administration (object info) adds some 32, and the collection itself needs
a pointer (either 4 or 8), assuming the hashing and/or links in the collection don't
add to that.
Hence IMO the statement "bool = 1 byte" is an oversimplification.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
modified on Sunday, April 20, 2008 7:59 PM
|
|
|
|
|
In the first paragraph I think I understand what you're trying to say. However in RAM the smallest ammount of space you can use is one byte. So once you declare a bool you've used up one byte and can't use the rest for 7 more bool's. A similar problem exists in hard drives. When you view the properties of a file you see two fields: "Size" and "Size on Disk". Size is the true size (number of bytes that the file requires) and Size On Disk is the number of bytes the hard drive alocates for the file.
However regarding the second paragraph; I don't have a clue. When you say Win64 I assume you mean 64 bit processors.
|
|
|
|
|
Jordanwb wrote: When you say Win64 I assume you mean 64 bit processors
indeed
Jordanwb wrote: However regarding the second paragraph; I don't have a clue
the OP and my first reply were about boxing, and how it turns a little bool into a
full-fledged object.
Jordanwb wrote: However in RAM the smallest ammount of space you can use is one byte
I am convinced the smallest amount of information you can store is a bit, and nowadays
8 of them typically fit into a byte. And most microprocessors have assembly instructions
to operate on a single bit into a larger memory byte or word.
When a .NET bool takes at least 1 byte, that must be due to some artificial limitation,
possibly in the compiler involved, more likely because of limitations in the IL (intermediate
language).
But I am a bit puzzled how all of this became relevant in this thread.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Luc Pattyn wrote: the OP and my first reply were about boxing, and how it turns a little bool into a full-fledged object.
Gotcha
Luc Pattyn wrote: I am convinced the smallest amount of information you can store is a bit, and nowadays 8 of them typically fit into a byte. And most microprocessors have assembly instructions to operate on a single bit into a larger memory byte or word.
You are correct, but this limitation is not artifical. When you create a bool type variable in memory you allocate a complete byte to it even though you're using only one bit of data for the actual value. The other 7 bits are completly wasted and you can't use them again until the bool is destroyed by garbage collection. For example: In my compuer I have ~1280 MB (1.25 GB) of RAM. That means that I can have a maximum of 2061584302080 bools (1280 * 1024 * 1024), not 16492674416640 (1280 * 1024 * 1024 * 8) [Re-reads your message] I think we're both saying the same thing but in a very different manner.
Luc Pattyn wrote: But I am a bit puzzled how all of this became relevant in this thread.
It's relevant because we're talking about OutOfMemoryExceptions. The dude is using to much memory and he doesn't know why. A few weeks ago I had a near exact problem. He was creating a Dictionary that - I assume - maps a key to a value. He had 2147483647 records in the dictionary. 2147483647 Int's each using four bytes equates to ~8 GB of RAM. Don't forget the space that bools take up which is 2147483647 bools each taking a byte / 1024 / 1024 equates to ~2 GB. He wants 10 Gigs of Memory.
|
|
|
|
|
Hi All;
Tnx for the input(s) everyone.
I shall (try to) work around by working on individual bits. I will be creating byte[] and work on individual bytes. I will work out true or false depending on the value of the bit at a particular address.
Ian
No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced.
|
|
|
|
|
I managed to do it this way. I created a class to do the work of mapping the bits inside a byte array and will post a short article soon.
Tnx to everyone.
Ian
No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced.
|
|
|
|
|
Article here[^].
No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced.
|
|
|
|
|
Building a dictionary like this is going to be expensive. Why do you need to use a Dictionary? It looks like you could get by with a much simpler array:
bool[] _numbers = new bool[_Max];
for (int i = 0; i < _Max; i++)
_numbers[i] = true;
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Hi Scott;
Tnx for the input.
Tried a bool array and I still get the same error.
Ian
No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced.
|
|
|
|
|
Well you're still asking for 2 Gigs or RAM just from the booleans alone, so that's your problem.
|
|
|
|
|
I think your best option then is going to be to work with the individual bit values, as you mentioned in your other post[^].
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
hi
i write this code to generate a simple source code with CodeDom :
CodeCompileUnit compileUnit = new CodeCompileUnit();<br />
CodeNamespace ns = new CodeNamespace("MyNameSpace3");<br />
ns.Imports.Add(new CodeNamespaceImport("System"));<br />
ns.Imports.Add(new CodeNamespaceImport("System.Text"));<br />
CodeTypeDeclaration ctd = new CodeTypeDeclaration("MyClass3");<br />
ctd.IsClass = true;<br />
ns.Types.Add(ctd);<br />
compileUnit.Namespaces.Add(ns);<br />
<br />
CodeMemberField field1 = new CodeMemberField(typeof(string), "_message");<br />
field1.Attributes = MemberAttributes.Private; <br />
ctd.Members.Add(field1);<br />
<br />
CodeConstructor constructor1 = new CodeConstructor();<br />
constructor1.Attributes = MemberAttributes.Public;<br />
ctd.Members.Add(constructor1);
in above code, i have a private field (_message) in generated class code.
now i want to initialize and encapsulate that field with CodeDom, but how to do ?
thanks.
|
|
|
|
|
Hi, you need to use the CodeAssignStatement class to set a value for the _message field. Try this:
CodeAssignStatement fieldAssign = new CodeAssignStatement(
new CodeFieldReferenceExpression(
new CodeThisReferenceExpression(), "_message"),
new CodePrimitiveExpression("message value"));
constructor1.Statements.Add(fieldAssign);
Good luck (I think everyone needs a bit when using codeDom!)
Rob
"An eye for an eye only ends up making the whole world blind"
|
|
|
|
|
Hello,
I am trying to create a form filler program and came across a gap:
some of the sites's DOM fields simply can't be edited - for example:
https://login.bankhapoalim.co.il/cgi-bin/poalwwwc?&bank=414
the fields - "userid" and "id" can't be edited using the following code:
if (i_Webbrowser.LocationURL == "https://login.bankhapoalim.co.il/cgi-bin/poalwwwc?&bank=414")
{
HTMLInputElementClass input = GetInputElement("userid", i_Webbrowser);
input.value = "someValue";
}
does someone have any explanation/suggestions?
it is not the httpS issue since gmail fields can be filled.
thanks!!!
|
|
|
|
|
Help anyone?!?
|
|
|
|
|
Hello everyone,
Two conflicting points about how to implement Finalizer, which one is correct?
1.
I always heard from people that in Finalizer we should not refer to any other objects, since the order of Finalizer is non-determistic, means the referred object in Finalizer might not alive any more.
2.
From the following article from MSDN, seems we are safe to refer to any wrapped objects (in my understanding, it means referring to member variables in Finalizer is always safe)?
http://msdn2.microsoft.com/en-us/library/ms973837.aspx#dotnetgcbasics_topic2
--------------------
"How Finalization Affects Collection
When the garbage collector first encounters an object that is otherwise dead but still needs to be finalized it must abandon its attempt to reclaim the space for that object at that time. The object is instead added to a list of objects needing finalization and, furthermore, the collector must then ensure that all of the pointers within the object remain valid until finalization is complete.
....
Since the internal object pointers must remain valid, not only will the objects directly needing finalization linger in memory but everything the object refers to, directly and indirectly, will also remain in memory. If a huge tree of objects was anchored by a single object that required finalization, then the entire tree would linger, potentially for a long time as we just discussed."
--------------------
thanks in advance,
George
|
|
|
|
|
Not sure how you're making the jump from the quoted text to your second point...but...
1. The order of finalization is non-determistic, so there is no guarantee that if you access another object from within your finalizer that it will still be available.
2. If by "wrapped objects" you mean an object that your are internally maintaining, it is safe under certain circumstances.
Finalizers shouldn't do anything more than ensure that memory is cleaned up by calling the appropriate Dispose methods (or other means for unmanaged code). Almost all of the assumptions that can be made about the internal state of the .NET runtime (and your object) that would normally be valid are not when running in a finalizer.
What is it that you're trying to do that you think requires the use of a finalizer? In the large majority of cases, it isn't necessary to write one.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott's assessment is correct and in addition, in Microsoft's book CLR via CSharp[^] the advice given by the author is that a finalizer is used to ensure that native resources are released. And the only native resources that are mentioned in the text are Handles. So as I understand it, unless you are using items by their windows handles, don't bother. Highly recommend getting the book.
Scott P
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
|
|
|
|
|
Cool, carbon_golem!
1.
One further question, if in my class, there is a StreamWriter data member, in the Finalizer method, if I do not close the StreamWriter, there should not be any resource leak, right? (because the Finalizer of StreamWriter itself will clean up native file handle resource wrapped by StreamWriter?)
2.
So, C# I/O class like StreamWriter is managed resource, not unmanaged resource?
regards,
George
|
|
|
|
|
George_George wrote: 1.
One further question, if in my class, there is a StreamWriter data member, in the Finalizer method, if I do not close the StreamWriter, there should not be any resource leak, right? (because the Finalizer of StreamWriter itself will clean up native file handle resource wrapped by StreamWriter?)
Fairly certain that's the case.
George_George wrote: 2.
So, C# I/O class like StreamWriter is managed resource, not unmanaged resource?
Yes.
Scott P
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
|
|
|
|
|
Thanks carbon_golem,
I have made some further study.
http://msdn2.microsoft.com/en-us/library/ddae83kx.aspx
Seems that we can only access base.Finalize in Finalizer method of current class? Any comments? Please feel free to correct me if I am wrong.
--------------------
An object's Finalize method should not call a method on any objects other than that of its base class.
--------------------
regards,
George
|
|
|
|
|
That's right. The garbage collection can't guarantee that anything will be available - think of the case that your finalizer is the absolute last thing that is done in your application before it shuts down, all other resources have been reclaimed including all the members inside your class. That's what you have to deal with. The purpose of a finalizer is to give you one last chance to free any native resources that your class may use. One case is that you decide that you want a class with a Hook created by CreateWindowsHookEx and you own that hook. Finalizer implementation would be advised because you are using a native resource directly, and you don't want to leak that resource. As long as the finalizer exists, the runtime will call it, you don't need to. One special case is when you release the resource in your Dispose method, at then end of the Dispose, make a call to GC.SupressFinalize and the finalizer won't get called. Getting the idea?
If your class is using a built in .NET class that owns native resources, you can be pretty sure that .NET takes care of the finalizer for you. IF you implement a finalizer, the runtime calls it. The same holds true for the finalizers that .NET is using. Oh, one last thing, if you do decide to use a native resource by handle, look into .NET's SafeHandle classes, and that will shed some insight on what you're doing.
Again
1) If you implement a finalizer, the runtime will call it when it's being reclaimed by the garbage collector - UNLESS you have explicitly made a call to GC.SupressFinalize.
2) Implement a finalizer when you are using Native Resources, notably Handles.
3) You can never be sure what other data will be available when your finalizer is called.
4) Get Lutz's Reflector, and see how .NET does it's finalizers. I won't answer questions about Reflector, stfw.
Scott P
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
|
|
|
|
|
Cool, Scott!
I agree with you in Finalizer we should only deal with releasing of native resource. I have got CLR via C# book, and referred the chapter 20, GC chapter. For the managed resource in Finalizer, it is suggested we only access the ones which do not have Finalizer method, because if there is finalizer method, the GC order of current object and referred object is not decided.
(section "Using Finalization with Managed Resources").
Do you agree or have any comments?
(So, our conclusion is, dealing with unmanaged resource and manged resource without Finalizer?)
regards,
George
|
|
|
|
|
That's it. Bravo.
"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand
|
|
|
|
|
Thanks carbon_golem,
It is clear now.
regards,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
