We pay for user submitted tutorials and articles that we publish. Anyone can send in a contributionLearn More
Getting an array length in C# is a trivial task. All we need to so is call the Length property of the Array Class:
int arr = new int; int arrLength = arr.Length;
Getting an array length in C++ might be less trivial:
int arr; int arrSize = sizeof(arr) / sizeof(int);
Notice that sizeof(arr) returns the array size in bytes, not its length…
We all know what breakpoints are, they tell the debugger that an application should break and pause execution, at a certain point. If we want to get certain information at this point, we need to copy it down to a paper or to the notepad. There are breakpoints which get hit hundred of times during the execution of a program, so it may be very exhausting to write down the breakpoint information each time it is hit. Well, last week, while I saw John Cunninghams session at PDC 2008 about Visual Studio Debugger Tips & Tricks, I learned something new. The Visual Studio debugger has another feature called tracepoints.
From Wikipedia: “A deadlock is a situation wherein two or more competing actions are waiting for the other to finish, and thus neither ever does”. Deadlocks are terribly difficult to find and even more difficult to debug. Debug Inspector is a free tool that allows you to view the call stacks of multiple threads at the same time, plugs in to the internals of the CLR and automatically detects deadlocks.
The most powerful feature of this tool is that it works on both managed and unmanaged code. It is actually a Visual Studio extension which can be used to detect managed deadlocks and a standalone executable to detect unmanaged deadlocks. Besides detecting deadlocks, there are more features to this tool:
If you have read the Unhandled Exceptions - Handle Them article, you are already familiar with unhandled exceptions in C#. Most people don’t really know that C++ also, have a mechanism to allow a clean termination of our program. I am writing this post to introduce you with that mechanism.
When an exception is unhandled by our program, no cleanup occur, meaning the destructors are not called. Moreover, you may want to do operations such as logging or presenting a friendly screen announcing about the occurrence of a problem. Wrapping out Main function with a Try Catch(…) block is not recommended due to performance issues. Fortunately, the…
Is it OK to throw exceptions from constructors? Some of us may have heard that it is wrong but don’t really remember why. There are lots of philosophical arguments about this question, you may become confused trying to understand what’s the right thing to do. Does it mater if we are developing with C++ or any other .Net language like C#? I am writing this article to shed some light on the “throwing exceptions from constructors” topic.
Constructors can’t return values, so we pretty much have to throw an exception to indicate that the object couldn’t be constructed. Some of you may grasp that constructors are supposed to handle simple tasks…
This is part B of the 10 Ways To Programaticly Shoot Yourself In The Foot article. As I already stated in part A, there are several things a software developer can do to make his life much more difficult in the future. In this article I will talk about another 5 issues that even the best developers have to be aware of. In other words, I will try to prevent you from programaticly shooting yourself in the foot.
There are four access modifiers: public, protected, internal and private. Don’t use public everywhere you can! Choose the correct access modifier!…
After publishing the How To Get Free Disk Space And Other WMI Stuff (.NET) article, I learned two new things. One is about a better way to get free disk space and the other is about a better and easier way to use WMI in general. This is what is good about blogging, you share your knowledge and then learn from others.
Karl Agius left the following comment:
“I agree that WMI is extremely powerful, and that it lets you get to details that are not otherwise available in managed code. In this case though, the free drive space can be derived through the AvailableFreeSpace method in DriveInfo. What are the arguments for using WMI instead of this?
Great article, by the way That WMI object browser looks handy … sure beats trawling through MSDN looking for stuff Thanks!”
I am currently working on a SaveAs feature to some special file formats, those files are very very big. Before actually saving the file, I need to compute its anticipated size and compare it with the free disk space to see if there is enough storage for that operation. After searching a bit about how to get the free disk space, I came across the solution which uses the System.Management namespace. This namespace provides access to a rich set of management information about the system, devices, and applications instrumented to the WMI infrastructure. But, what the hell is WMI?
WMI is Windows Management Instrumentation and is part of the Windows operating system that provides management information and control. WMI provides extensive instrumentation to accomplish almost any management task and help us obtain information about our system. Applications and services can query for interesting management information such as how much free space is left on the disk, what is the current CPU utilization, which database a certain application is connected to, and much more, using classes from the System.Management namespace. Here is the MSDN page about the Windows Management Instrumentation.
Let me show you how to query the free disk space using WMI:
The thirteen post of the series of programming job interview challenge is out, Only 13 comments with answers were provided to job interview challenge #12. This is a small amount comparing to the previous challenges, but I realize and understand that it was language specific and not very trivial challenge…
Jason Kikel was the first one to solve the question, and here is his short answer:
UnmanagedClass is referencing an address on ManagedClass without pinning it. The ManagedClass instance needs to be pinned so the GC won’t move it to another location during a collection.
When you join a team, it’s important to bend your preferences a little to accommodate the generally accepted coding practices of that team. Not everyone has to agree on every miniscule detail of the code, of course, but it’s a good idea to discuss it with your team and decide on overall approaches and philosophy beforehand. It promotes team harmony, and more than that, it’s just common courtesy. As they say, when in Rome, do as the Romans do.
Jeff Atwood is talking about the fact that it is important to obey the coding conventions and practices of your team. Every one of us as its own preferences but as a team we need to have some rules, we all should work with the team, not against it. I must admit that I totally agree with Jeff’s attitude, no questions about it.
But, in addition to what was said before, Jeff continues:
Still, there are some coding preferences people may feel.. strongly.. about. If that’s the case, try to clear the air and address those strong preferences up front, as early as possible. Don’t let them simmer. For me, the use of #region is one of those things. I tried to make myself clear in this twitter message: No, I will not use #regions. And no, I DO NOT NEGOTIATE WITH TERRORISTS. Shut up.
I am not going to talk about the #regions issue, but to have my own say about another coding preference:
Copyright © 2012 Dev102.com
Breeze : Designed by Amit Raz and Nitzan Kupererd