|
actually they're both right.
What Tess is saying is that even though the total free memory you have may be in theory enough to satisfy the request, it may be fragmented into many free blocks. None of these free blocks is large enough to satisfy the request.
Silence is the voice of complicity.
Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python
Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
|
|
|
|
|
That is indeed what Tess is saying, but she also says "that is what happens when you get an OutOfMemoryException". The other party claims the garbage collector will perform defragmentation (which is part of garbage collection, after all) before throwing OutOfMemoryException, and if that is true you wouldn't get OOM as long as the new allocation requires less than total free memory.
If so, the only time you should get the exception should be when the live objects are pinned. (Very large objects are said to be "pinned" because they are never moved in defragmentation due to the hard work it would be moving such big objects around.)
I guess if you want very much to conclude that they both are right you could assume Tess was talking about pinned objects, but that is a rather contrived way of getting there, and I frankly don't see the point. For me the important thing isn't who is right but what the fact is. And that is unfortunately still no more clear for me.
|
|
|
|
|
the point 2. seems to be very clever solved.
Greetings from Germany
|
|
|
|
|
because in another post someone mentioned the lack of knowledge of arrays in childhood i got reminded of a funny spam-mail i once received.
they have such nice things like
var status1 = "";<br />
var status2 = "";<br />
var status3 = "";
or <a HreF="blah"> .
enjoy here[^]
|
|
|
|
|
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
(Now I've forgotten who said it; I had to find a post by leppie to get it.)
Need a status? Make one.
Need a second one? Go right ahead.
Need a third? Hey! They don't grow on trees!
It reminds me of a job I used to have... I was assigned the maintenance of the credit card processing part of the system. Each member's account had fields for credit card number, type, and expiration. So far so good.
Then we got a new client who wanted a backup credit card... OK, we added a second set of credit card number, type, and expiration plus a field to indicate which one was used last time to the table.
Then we got another new client who wanted to do EFT and before anyone told me about it, they added account and routing number (or whatever) to the table.
When I went to talk to the DBA and suggest we should have some sort of PaymentSource table that could have any number of sources associated with an account. His response was that, although it was a good idea, the inmates had taken over and there was nothing we could do at that point.
|
|
|
|
|
PIEBALDconsult wrote: The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
Yes, very true.
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
I found this code somewhere:
...
if (x == true)
return true ;
else
return false ;
Actual code was the body of a C# 3 lambda expression. Anyway, horrible.
|
|
|
|
|
Could be for debugging, for a breakpoint.
|
|
|
|
|
It's not THAT horrible. Yes, it's not exactly elegant, but sometimes this is done to make things clearer to other coders (especially less-experienced ones).
|
|
|
|
|
AEternal wrote: sometimes this is done to make things clearer to other coders (especially less-experienced ones).
But then how would they learn?
|
|
|
|
|
The senior programmer could place comments like this:
if (x == true)
return true;
else
return false;
codito ergo sum
|
|
|
|
|
Fair enough.
|
|
|
|
|
Then it should be
return x ;
|
|
|
|
|
PIEBALDconsult wrote: I'll have you tied to an anthill and covered in honey!
Cute. This should get a Vote of '5'.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
or he could just save the time it takes to write that long, verbose comment and just write
return x;
|
|
|
|
|
No time or effort should be spared in the process of education of the younger generation.
Even better would be.
return (x == true) ? true : false;
codito ergo sum
|
|
|
|
|
With longer conditions and expressions, ternary operator becomes tedious to debug.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
It IS that horrible when you join a project and the other "experienced" consultant is writing a pile of redundant crap like that:
if(x == true)
{
control.Enabled = true;
}
else
{
control.Enabled = false;
}
The above adds an extra comparison operation in addition to being ugly. Besides, as someone already mentioned, How will the juniors ever progress?
Forgiveable for the OP though
The project i joined has a metric buttload of that garbage. Even worse is these guys "architected" classes without methods (can you say pre-OOP structures boys & girls?) and then created a function library (which they called a "fascade" and is NOTHING like the fascade design pattern) where you pass in an instance of this methodless "class" to the method of a fascade class to do work on it (i.e. persist it). The reasoning? They thought adding methods to the class would make it too slow. It has been a rollercoaster of emoticons.
e.g.
class Person
{
public string FirstName;
public string LastName;
}
class PersonFascade
{
public void InsertPerson(Person p) { /* do stuff */ }
public void UpdatePerson(Person p) { /* do stuff */ }
public void DeletePerson(Person p) { /* do stuff */ }
}
|
|
|
|
|
codemunch wrote: class Person
{
public string FirstName;
public string LastName;
}
class PersonFascade
{
public void InsertPerson(Person p) { /* do stuff */ }
public void UpdatePerson(Person p) { /* do stuff */ }
public void DeletePerson(Person p) { /* do stuff */ }
}
Isn't your example standard practice?
Person = Business Object
PersonFacade = Database Wrapper
You get exactly the same when you generate any DB Mapping using an ORM system, and i see nothing wrong with it.
I always operate on the aim to separate data structure from functionality.
That said, the naming conventions are misleading.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Well, the example wasn't too detailed but as-is it took OOP and bastardized it into a function library (PersonFacade) + simple data structures (Person).
You do want your persistance layer (data) to be separate but working at the business layer (often from a different class) and calling data layer specific persistance methods is ugly not to mention a pain in the ass to manage.
A much cleaner solution is to have a Save() method (and depending on your scheme, a Delete()method) which then passes itself to a data layer so in your business & UI logic you don't need to call data layer specific methods residing in a completely different class. The business object takes care of itself and your code is better organized. The data layer could look like the "facade" thing or could be a smarter all-encompasing gate keeper.
|
|
|
|
|
Great point. Never thought of it that way. But it wasn't a sennior programmer making things clearer, nor a junnior one making misstakes. It's just some guy who has been programming for a while and I guess has no clue how boolean expressions work. It's started on C# by the way. Original code
x => if (SomeBoolMeth(x) == true) return true; return false ;
If you were a professor and find this in some test, not from a basic course, what would you do??
Again: Great point!!
|
|
|
|
|
Either you've understood that "(x < 5)" is a boolean expression every bit as much as the boolean constants "true" and "false", or you haven't. There's nothing in between. The code makes it look as if the condition is somehow not a boolean expression, and therefore highlights the author's lack of understanding, of something quite fundamental, and therefore deserves to be on display as a coding horror, in my opinion.
For some reason I see this done a lot with ternaries in C#:
return (s == "toto"? true : false);
Unfortunately proper use is less commonly seen, such as
return (row != null? (int)row["count"] : -1);
|
|
|
|
|
What is x declared as? It's not a var is it?
|
|
|
|
|
Good catch!
Here could be trying (although not recommended) for "object == true".
|
|
|
|
|
what if x was a nullable boolean ?
<br />
static bool getX(Nullable<bool> x)<br />
{<br />
if(x==true)<br />
{<br />
return true;<br />
}<br />
else <br />
{<br />
return false;<br />
}<br />
}<br />
</bool>
|
|
|
|