Garbage collector and local variables

If you are a C# programmer, then I have a question for you. How do you think, how many times the string "GC called" will be written to console by the following code:

using System;
using System.Threading;

class GarbageCollectorTest
{
   public static void Main()
   {
      Timer t = new Timer(CallGC, null, 1000, 1000);
      Console.ReadKey();
   }

   static void CallGC(object o)
   {
      GC.Collect();
      Console.WriteLine("GC called");
   }
}

Correct answer: depends on compilation parameters. In release build the string will be written only once. Debug version will write it until the user presses a key.


In C++ a local (automatic) variable's lifetime is defined by variable's scope - the variable will be destructed when program flow goes out of the scope.
In C# the lifetime of such variable is defined by how long the variable is used. I.e., the variable may be destructed before it goes out of scope, if garbage collector considers that it's not used any more.
In debug version variable's lifetime is artificially extended to its scope.

In Java, as far as I know, the JVM specification allows similar realization of garbage collector.

P.S.: If you are a C# programmer, but this post became an eye-opener for you, then read Jeffrey Richter's book "СLR via C#". You can find much more interesting and useful for.NET development in it.

C# quick question.

Can you quickly specify three advantages of automatic property over public field, as a member of a class?
I.e., why is the following code:

public string Foo{ get; set; }

better than this:

public string Foo;

The asnwer is (as often) on StackOverflow.

NOPs and debug

It's often necessary to edit source code during debug. To make this fixes to take effect, usually, you need to rebuild your application and restart the debug session. But there is edit-and-continue feature in Microsoft Visual Studio, which allows these fixes to take effect without restarting of the application. Ever thought about how it works?

The secret is in NOP instructions, which compiler inserts in certain places of executable code. These instructions can be replaced with new code later. Also, they allow to place breakpoints at those source code lines, which have no correspondent executable code. E.g., at the beginning of code block (opening brace in C++ and C#). Or at the operator, that would otherwise be replaced during optimization.

BTW: NOP-instructions may also be reasonable in application's release-version. E.g., to align code block for better caching.

C++0x will not have concepts!

C++ standardization committee voted to remove concepts from almost-ready C++0x standard, during it's meeting in Frankfurt in July.
Concepts are probably the most discussing innovation in C++ meta-programming paradigm. The main purpose of concepts is to specify template constraints clearly and intuitively, while improving the compiler's capability to detect and diagnose variations of these constraints. Also, concepts would allow to create a type map to use some type in template, if the type and the template are not compatible directly. As reasons for such a hard decision there were stated unfinished specification, complexity and absence of real experience. Since concepts could potentially become a new cornerstone of C++, it was decided not to standardize the "raw" specification. The time will tell whether concepts will be included in next standard, and whether they will be simplified, improved or just rewritten from scratch.

Stroustrup's post on this topic is on Dr.Dobb's.
Sutter also commented this on his site.
You can find more links, e.g., on StackOverflow.

Anyway, we are looking forward to other language innovations, such as lambda expressions, rvalue references and move semantics, generalized constant expressions, etc.

New SOR-application - coming soon!

You work with SOR-traces, and amount of your tasks is wider, than SOR Shell Extension allows to do, but existent SOR-applications are not good enough for you? Or you would just like to try new modern application in your field? We have a good news: our brand new SOR-application is almost complete.

Follow our site and be the first to download EasyViewer!

When and how to use SOR Shell Extension

Everything is good in its season.

(English proverb)

Sometimes we get e-mails with similar text: “I’ve just installed your SOR Shell Extension. How can I run it?” Users download an installer as usual, run it as usual, complete an installation as usual, as usual they try to find a new program to run in Windows “Start” menu. And they cannot. (Or, to be more precise, they can find only SOR Shell Extension Configurator).

The reason is that SOR Shell Extension is not a program in common sense. As you can guess from its name, this is an extension to Windows shell. This means, that after SOR Shell Extension has been installed, Windows looks like if SOR-file support is built-in into the operation system. I.e., you can see trace pictures directly in Windows Explorer window (as, for example, JPEG or BMP files) or edit specific trace properties in «File Properties» dialog, activated from context menu (as, for example, with MP3 files). And this applies not only to Windows Explorer. A lot of software use Windows API (often indirectly, through different libraries) to allow a user to access files – this is also the case for SOR Shell Extension to show its worth.

But there is sometimes another kind of misunderstanding: users expect SOR Shell Extension to substitute some full-weight OTDR traces workshop software (let’s call it SOR-viewer for short). And so there is another kind of emails: “I’ve just tried your SOR Shell Extension, and, you know, I will continue using Censored SOR-viewer”. It has the same sense, as to write: “I’ve just tried to view pictures in Windows Explorer, and, you know, I will continue using Google Picasa (ACDSee, Windows Imaging, your favorite software)”.

Every software is created for its own purpose, and SOR Shell Extension was not developed as a substitution for full-weight SOR-viewer. You should not expect SOR Shell Extension to do automatic analysis or OTDR measurement, for example. But, there are tasks to be solved with SOR Shell Extension with more convenience. Consider the following examples.

Let’s assume that you need to find a trace in a folder, but you have forgotten its filename. Though you remember how it looks. If you are using usual SOR-viewer, you need to open and look at all SOR-files trace-by-trace, until you find the required one. This procedure may take a long time if there are a lot of files in the folder. But if you are using SOR Shell Extension, all you need to do, is to open the folder in Windows Explorer, switch to “Thumbnails” view and look through trace images for the one you need.



Or probably you need to copy traces with 80 km distance range from the folder to an external drive. With usual SOR-viewer you have to open traces one-by-one, check each for its distance range, and copy relevant to the external drive. The more files, the longer algorithm. In addition, you can make a mistake and miss some relevant files. But if you have SOR Shell Extension, you just need to open the folder in Windows Explorer, switch to “Details” view, sort traces by “Distance Range, km” column (if you can't see this column, you need to add it by pressing right mouse button on the table header). And then, it’s trivial to select and copy files with 80 km distance range.



If you need to set SOR-specific “Comment” field for large number of traces, it’s a misfortune for you to have only usual SOR-viewer. In this case you need to open traces one-by-one and set this field in each. Having SOR Shell Extension allows you to succeed much faster. You just select the required files, press right mouse button, and select “Properties”. The “File Properties” dialog shows, which allows you to set “Comment” field value for all selected files at once.



These are only several from large amount of cases, in which using of SOR Shell Extension is much more convenient. Thereby, if you work with OTDR traces, then SOR Shell Extension will serve as nice and convenient add-on to full-weight SOR-viewer.

Distributed temperature sensing (DTS).

OptixSoft Company’s Blog has started new trend from now - "Invited Blogger". We will invite engineers and specialists in related fields from outside (fiber optics, software development, etc.) to post at our Blog. It may help us to hear and share different opinions and ideas.

Here is the first such post written by our friend and fiber optic specialist Andrew Luzgin (currently working for FOD Ltd).

Distributed temperature sensing – is a great technology on OTDR base.

A few words about theory. Well known, that original OTDR measures a backscattered Rayleigh light in the optical fiber. Except Rayleigh effect, there are another scattering effects in the oprical fiber (not in fibers only, of course). It is so called Brillouin and Raman scattering. The intensity of the Raman scattered light is very sensitive to optical fiber temperature. So, it is available to measure distributed temperature along optical fiber. It can be original singlemode (SM) or multimode (MM) fibers. Both fiber types application has merits and demerits.

Simplified schematic of DTS system is below.

At first glance, it looks like an original OTDR, but DTS includes optical filter (OF) and optical commutator (OC). These parts are necessary to choose Raman light from total backscattered signal. And then — a usual OTDR. In a simple case, it can be an OTDR interface with some special processing on the software level.
Nowadays, DTS system becomes a powerful attribute for environment research, fire alarm, piping control etc. Of course, most useful application is a long time temperature monitoring. This allows storing information about control object, producing necessary analysis and predictions.

Many thanks to Invited Blogger - Andrew Luzgin.