It was about a decade ago when Visual Studio .NET 2002 was launched. Having worked with Visual Studio 6 until then, the new interface was refreshing and powerful along with .NET and the suite of languages, tools and technologies. If you were there, you would have felt times were changing. Beyond the cool and modern interface, Visual Studio .NET 2002 had a lot more to offerβ compared to Visual Studio 6 ββ.NET. It was an exciting time for me back then. More ...
Today, we question our beliefs! Is string really immutable?
string message = "Hello World!";
Console.WriteLine(message); // Prints "Hello World!"
unsafe {
int length = message.Length;
fixed (char *p = message) {
for (int index = 0; index < length; ++index) {
*(p + index) = '?';
}
}
}
Console.WriteLine(message); // Prints what? See for yourself!
void SomeMethod(int x, double y) {
// some code
...
new Thread(ThreadFunc).Start();
}
What do you think about the code above?
Some may say nothing seems to be wrong. Some may say there is not enough information to comment. A few may say that it is awful to spin off a thread like that (the last line of the method), and that there is a probability for the thread to be garbage collected at an unexpected point of execution. That is something interesting to discuss about.
More ...
There are two facilities in C# to determine the size of a type β sizeof
operator andMarshal.SizeOf
method. Let us discuss what they offer and how they differ.
Before we settle the difference between sizeof
and Marshal.SizeOf
, let us discuss why would we want to compute the size of a variable or type. Other than academic, one typical reason to know the size of a type (in a production code) would be allocate memory for an array of items; typically done while using malloc
. Unlike in C++ (or unmanaged world), computing the size of a type definitely has no such use in C# (managed world). Within the managed application, size does not matter; since there are types provided by the CLR for creating \ managing fixed size and variable size (typed) arrays. And as per MSDN, the size cannot be computed accurately. Does that mean we donβt need to compute the size of a type at all when working in the CLR world? Obviously no, else I would not be writing this post.
I would not want to write chunks of code to spawns threads and perform many of my background tasks such as firing events, UI update etc. Instead I would use the System.Threading.ThreadPool class which serves this purpose. And a programmer who knows to use this class for such cases would also be aware that the tasks queued to the thread pool are NOT dispatched in the order they are queued. They get dispatched for execution in a haphazard fashion. More ...
Guess the output of the following program:-
class SomeClass : IDisposable
{
public SomeClass()
{
Trace.WriteLine("SomeClass - Attempting instance creation");
throw new Exception("Ohh !!! Not Now");
}
public void Dispose()
{
Trace.WriteLine("SomeClass::Dispose");
}
~SomeClass()
{
Trace.WriteLine("SomeClass::Finalizer");
}
}
int Main(string args[]){
try{
SomeClass sc = new SomeClass();
}
catch(Exception ex){
Trace.WriteLine("Main - {0}", ex.Message);
}
}
This will be the output of the program:-
More ...
Over the past few weeks, I have been involved with this module that got the best of both worlds - .NET and I, π.
Ok, this was the problem. We have a COM server, let us name it Server. I had to write an assembly in C#, let us call it Bridge, that will listen to all of the events fired by the Server and perform an action Action. To keep that Action simple, let us assume we have to log them to the database. But the Server fires hundreds of events, and it is not wise to write up static event handlers for all of them. Also, if more events are (ever) added in the future, the Bridge should be able to support it without code changes.
The twist in the game was that this was a brown + green field development project. That demanded a wise solution - learn from the past and better the future.
More ...