It might be a good idea to convert both of them into struct's to avoid allocation/GC for each call. This would remove the overhead almost completely (well, for `TimeCriticalBlock` at least, `TimedBlock` writes on each dispose). Also (as others have pointed out), the overhead of writing to the console is also not negligible (it's surprisingly slow, not to mention multithreaded access when you start getting lock contention), using a logging library combined with baretail (or something) might be a better idea. More performant, configurable, able to store logs history for months. Also doesn't lose all logs in case of a crash.

One question pops out though: why not protobuf.net? Protocol buffers provide extremely space efficient binary files, with versioning support, and .NET port can use reflection to configure the serializer without attributes. It's also among fastest serializers out there.

Rob Philpott wrote:

Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work (...)

Well, it did make it work, didn't it? Prior to that, you weren't able to provide any common functionality to an interface, without actually forcing all your subclasses to derive from a single common class. Since C# doesn't support multiple inheritance, this was the natural way to do it. And the fact that these are actually static methods that don't know anything about the concrete implementation is exactly what ensures that they will work with any implementation.

Rob Philpott wrote:

didn't really know how bad things could get

You should visit The Daily WTF [^] in that case. You will quickly learn that any programming construct can be abused beyond imagination.

Rob Philpott wrote:

Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system.

Well, that's one of the main prerequisites for loose coupling, and you cannot accomplish it without going functional (or OOP, which basically boils down to functional programming). If you want to be able to test individual parts of your system, make your program easily extensible, and follow other points of the SOLID OOP principle, then I'm afraid you have to go past plain ol' procedural programming.

I am aware of that, but it doesn't prevent an MITM attack. Whenever there are input boxes on a page which is not secured, nothing guarantees you that you are not being a victim of a MITM attack. All form post links could be rewritten to send the data elsewhere. Even worse, page could be running a key-logging JavaScript code, and no-one would have a clue that their passwords have being stolen before they even clicked the submit button.

Thanks, done.

Why does CodeProject provide insecure login at the top of the page? If I type the wrong password in the box first time, then it will take me to a https page, which is a good thing. But since CP already has SSL anyway, I don't see a reason to leave this vulnerability?

Why does CodeProject provide insecure login at the top of the page? If I type the wrong password in the box first time, then it will take me to a https page, which is a good thing. But since CP already has SSL anyway, I don't see a reason to leave this vulnerability?

Your example is using spaces to "indent" the cell contents to make them appear aligned. From what I've seen so far, it looks like RTB (at least the .Net wrapper) ignores horizontal alignment in table cells.

You will probably have to P/Invoke ChangeDisplaySettings http://www.xs4all.nl/~rjg70/vbapi/ref/c/changedisplaysettings.html[^] somehow? Check this example also: http://msdn.microsoft.com/en-us/library/ms812499.aspx#tbconchgscrn_gettingdisplayset[^].

Good point, resolution of the Now property is in ms, and depends on the system. In Vista it seems to have a 1ms resolution, I just tested it:

// a console app
static void Main(string[] args)
{
StringBuilder sb = new StringBuilder(16384);
for (int i = 0; i < 10000; i++)
sb.AppendLine(String.Format("{0:HH:mm:ss.ffff}", DateTime.Now));

Console.WriteLine(sb.ToString());
Console.ReadLine();
}

System.Diagnostics.Stopwatch on the other hand is much more precise:

static void Main(string[] args)
{
StringBuilder sb = new StringBuilder(16384);
Stopwatch sw = new Stopwatch(); sw.Start();
DateTime now = DateTime.Now;
for (int i = 0; i < 10000; i++)
sb.AppendLine(String.Format("{0:HH:mm:ss.fffff}", now + sw.Elapsed));

Console.WriteLine(sb.ToString());
Console.ReadLine();
}

You can create a new background thread with a manual reset event, waiting for a specified amount of seconds or an external Set.

// in your background thread
int msToWait = 5000;

do {

// wait for Start event
manualStartEvent.WaitOne();

Stopwatch sw = new Stopwatch();
sw.Start();
// wait for Pause event, or until time elapses
bool externalSet = manualPauseEvent.WaitOne(msToWait);
sw.Stop();

// check if Paused or elapsed
int actualMsElapsed = sw.Elapsed.TotalMilliseconds;
if (externalSet) // this indicates external set, so time did not elapse
{
msToWait -= actualMsElapsed;
if (msToWait < 0)
msToWait = 0;
}
else // this indicates we're done
{
msToWait = 0;
}

} while (msToWait > 0);

[EDIT] Code is posted only as an idea, you should take care of starting the thread, handling Stop situations and proper disposing all events.

modified on Thursday, April 9, 2009 8:39 AM

DateTime itself has a resolution of 1 tick, which is 100ns. What you probably wanted to say was that Windows.Forms.Timer is not very precise, because it always invokes the handler from a Gui thread, which means it will sometimes have to wait until OS is done doing Gui stuff before it actually calls the handler delegate.

Right click your project in VS and select "Add reference". Then select your COM object from the list of installed objects. .Net will create a managed wrapper class (RCW) which you can use to instantiate the object and access it like it was a managed object.

I agree, ManualResetEvent is IMHO the best solution. In your case you might not need a timeout, however, because a long pause does not indicate an exceptional case (if you are making a "play/pause" sort of functionality). But remember to implement IDisposable in your class, and signal the ManualResetEvent before Disposing to make sure that your background thread ends also, otherwise you will end up waiting forever.

But you still didn't say why you are trying to do this? Casting Int32 to a List<> doesn't make much sense, so it is natural that you will get this error. There may be a better solution to your problem, so try to explain what is the actual problem that got you thinking about casting with generic parameters?

Just a note - you should note that this line:

dummyColl = (T)SampleColl;

doesn't do anything to the actual dummyColl being passed to the method. So this kind of casting at the end of your method doesn't do anything.

It is not very clear from your sample what you are trying to do. If you are doing this to cast a collection (hence the dummyColl name?), you would probably want to do something like:

private static List CastToDerivedType(List list) where T : BaseType
{
List result = new List();
foreach (BaseType item in list)
result.Add(item as T);
return result;
}

Try explaining what is your goal first.