|
In a new body of code I've "inherited" there is a lot of code that looks something like this (simplified somewhat):
public class A
{
private ArrayList list = new ArrayList();
private object m_lock = new object();
public A()
{
lock(m_lock)
{
list.Add("MyString");
}
}
}
Now am I going mad? That lock statement to my eye is marginally pointless. Is there ever any justification for locking on a non static, private object in a constructor?
Cheers,
E.
|
|
|
|
|
Probably not, and why have a separate object for the lock either (in the included code anyway)?
But it could be worse as well.
|
|
|
|
|
[I'll get there, just give me a sec. ]
From a coding perspective, people often use 'this' as the object to lock on, but that is not a preferred method of locking. The reason is that code outside of the class might want to use that object to lock on as well, there by possibly causing a deadlock. So, the recommendation is to often use internal private objects to do this.
Now, in this case, I would assume the array list would be the best item to lock on. But out of readability or perhaps if that array list is reinitialized later, they may have opted for a separate unchanging object reference for the lock to prevent any kind of concurrency issues.
So, in short, the lock in the constructor is needless, but the object used in the lock very well could be needed depending on the implementation of the class.
|
|
|
|
|
The previous position of the developer was in jeweller’s shop.
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]
|
|
|
|
|
|
|
I was going through our documentation and noticed this gem. We had a senior developer who created our development standards. This was part of the document he wrote for us. We had the .NET 2.0 framework available to us (hint: Generics) when this was written. I hope you find this as entertaining as I did.
On a side note, when the efficiencies were brought to his attention and refuted with a sample app, he was indignant and would not even consider any other way. He no longer works here!
There are times that information needs to be collected and distributed around the program. To aid in the collection of data and
passing it, Microsoft added collections. The two most popular are arrays and arraylists.
An array takes its space out of the near heap. It is very possible to run this out by adding to the array. Arraylist takes its
space out of the far heap and in 64KB chunks. When building the collection, arraylists are the best thing to use for speed.
HOWEVER, when passing the information from method to method, an arraylist is not the most efficient taking up to 60,000 flops to pass
the information therefore arrays are faster.
q: How do we strike a happy medium on this?
a: Use both. Since most of the data that we collect are strings, we can do the following. Build the arraylist when collecting
data, the pass the data to an array when collecting is complete. The following code is a great example on this:
string[] results = new string[arraylist.count];
arraylist.CopyTo(results, 0);
return results;
|
|
|
|
|
I believe he didn't learn any programming languages coverd Array before he jumped into Senior position of .NET
|
|
|
|
|
Yep. He often regaled us about the early days of his TRS-80 and the "Line Numbered BASIC" programs he wrote. I seriously wonder if he still fires up that machine at night...
Hogan
|
|
|
|
|
Why dont you write your own IList object like to your queries
|
|
|
|
|
snorkie wrote: We had a senior developer
I hope for your part, the tense is correct
xacc.ide - now with TabsToSpaces support IronScheme - 1.0 beta 1 - coming soon ((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))
|
|
|
|
|
Yeah, he is gone. But on the lighter side, we find all sorts of gems in our code that make us shake our heads and laugh.
Hogan
|
|
|
|
|
In that way the Senior is always with you, in both code and memory
|
|
|
|
|
snorkie wrote: string[] results = new string[arraylist.count];
arraylist.CopyTo(results, 0);
return results;
Of course this is utterly inefficient. Everybody knows that a recursive function is always faster than a non-recursive one. So CopyTo() needs to be replaced by a recursive function! And by the way, there is nothing to stop you from writing recursive subrounties in TRS-80 BASIC!
_____________________________________
Action without thought is not action
Action without emotion is not life
|
|
|
|
|
Did you say senior !!! my GOD
Redwan Al-Bougha
|
|
|
|
|
Redwan Al-Bougha wrote: say senior
Yes, he did, and in a reply he mentions the senior developer is no longer with them.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
I don't know what he was smoking, an ArrayList or generic List<> simply manage a single array under the covers, resizing it as required. You need to be able to allocate a contiguous array to hold all the elements.
Maybe he was confused with C++'s deque , which does generally manage multiple array segments.
.NET has no concept of near or far heaps. It does have a Large Object Heap which is used for large allocations; the belief is that large objects will generally be kept around so the Large Object Heap is swept at the same time as a Generation 2 garbage collection. This can keep otherwise short-lifed objects around. The choice of regular or Large Object heaps is only down to the size of the objects themselves: a 1MB array or a 1MB capacity for an ArrayList makes no difference.
One distinction between ArrayList and, say, an int[] is that ArrayList manages an object[] , which causes value types to be boxed when added to the collection and unboxed when they're used. In contrast the generic List<int> manages an int[] , but that means an actual copy of the implementation is required, and generated by the JIT, for every different value type that is used as a type parameter. The same implementation is used for all reference types.
string is, of course, a reference type.
Arrays themselves are reference types so there should be no difference in passing an array or an ArrayList between methods. He probably managed to measure JIT time and got an incorrect answer, or simply got a page fault or a reschedule in the middle of a measurement.
It can be convenient to build something in an ArrayList then copy to an array when you don't know how big the array needs to be at the outset, and you can't change the rest of the code to use an ArrayList instead. If you wrote your own, you'd probably end up mirroring the code in ArrayList itself. Many .NET controls and methods support binding to an IList to give you some flexibility in the container you use.
"Multithreading is just one damn thing after, before, or simultaneous with another." - Andrei Alexandrescu
|
|
|
|
|
IList obviously keeped back an HTable and under the sorting algorithim it has used the QuicSort. So it can be use an ArrayList of generic or any enumeratic variations that hold the algorithm.
There many ways to develop for any special queries by an arraylist.
There have some question;;;
1- Why?
2- What is our aim
3- What is our strategy it is linking to the platform and technology
4- which is cheaper for our credentials
5- Prefere
|
|
|
|
|
I don't get why people cling to arrays in C#, they are less easy to use than egneric Lists and hvae a similary large overhead (the amount of methods available for an array is pretty much the same as for a List).
From what heard there is also no speed improvement.
And Arraylist should be used as rarely as possible, if all elements have the same type, it's easier to work ith them instead of first having to cast each object.
Besides worker threads, that only have 1 object as possible parameter, I can't think of the nedd to hae differnt bkect types in the same collection.
modified on Tuesday, February 24, 2009 9:16 AM
|
|
|
|
|
Hello,
I do not know if this is a horror or not, but it was a horror for me.
In a project i wrote this little gem:
#define stdcall_api __stdcall
Do not do that ever. Now i cannot build any project in Visual C++ (2008).
I think this is really a horror, no?
|
|
|
|
|
Dunno, does it conflict with something? If not, what's the problem?
|
|
|
|
|
Judging by the "Now i cannot build any project in Visual C++ (2008).", I'd say that's quite a horror - although I can't see how a #define could affect "any project", unless added to a (very) commonly include header.
|
|
|
|
|
Right, but it must conflict with something. And did it work in 2005?
|
|
|
|
|
Hello thoru,
Although I was sure that this issue should not make any error . I gave it a try in my installed VS2008 in my machine.
I made a new C++ project with a precompiled headers and non-empty project, every thing went good .
Redwan Al-Bougha
|
|
|
|
|
Maybe this isn't the right place for this post since I don't have the code (so please move it if it doesn't belong), but it is clearly a horror on the part of the original programmers.
We use the enterprise shipping software of a major shipping company (that uses yellow trucks with red lettering). Whenever we ship something using the software, a floppy disk must be in the drive (even though it neither reads a file from the disk or writes a file to the disk), otherwise it will fail with a .NET error WHILE TRYING TO EXECUTE THE C# COMPILER!
While I'm sure that in some circumstances, writing code on the fly can be beneficial, I cannot even begin to imagine that it is even remotely necessary for shipping packages.
|
|
|
|