I believe our mind (esp. our memory) is like a muscle. If we don't
seriously use it, it tends to age, weaken and lose capacity.
Over the last 5 years, i spent 2009-2011 in the US on my own —
tremendous learning and improvement, perhaps the most active learning
period in my professional life. Then after I came back to SG, i
studied financial math program, c#/dotnet, and some c++.
I feel the serious study keeps my mind active. However, over the last
18 months, I notice various signs of my learning capacity reducing,
but it's not all due to aging —
* biggest factor is lack of concentration, due to kids and family commitment
* not enough time to periodically re-visit each topic,
After all, I feel it's vital and paramount to keep our mind in
constant learning mode. 活到老学到老.
With java, i think we get binary portability in the vast majority of cases. With c++ you usually get good source code portability unless obvious non-portable libraries are used.
———- Forwarded message ———-
From: Qiang Wang
Subject: Re: c++ portability
I think the answer is YES. You have portability problem if you want to move from Windows to UNIX, especially when applications have GUI, hardware driver, network functions. However, for a simple C++
application, you can run on both Windows and UNIX with minimal change after compiling on both systems separately.
On Tue, Aug 24, 2010 at 9:01 AM, Bin TAN (Victor) wrote:
> Hi Friends,
> One potential IV question to verify hands-on c++ experience — Java has a
> big selling point “write once run anywhere”. If you wrote c++ in windows and
> run in unix, did you have portability problems?
> Is there any?
Though this post is about dotnet, it is likely to be also applicable to non-dotnet apps.
You can create/delete custom event logs. The 3 built-in event logs (app, security and sys) can’t be deleted. All of the above are viewable on eventvwr
Except security log, all other event logs are writable – including app, sys and custom event logs. I feel this is a simple way to implement basic application logging in dotnet. The EntryWritten event firing feature looks neat.
Further, it looks like multiple (Local) processes can subscribe to the same EntryWritten event, so you could perhaps coordinate 2 processes using EntryWritten — IPC
You can even access remote event logs.
Perf counter is Another simple IPC mechanism. You can create custom perf counters, visible to other processes + perfmon.exe.
Since one process can update the counter and another process can see it in real time, it’s IPC.
I have yet to implement IPC this way.
All sync objects in windows, across languages, are based on primitive kernel sync objects. (How about sync objects in jvm on windows? I guess the same.) Sync objects are not language constructs, but provided by the OS. I feel the stream construct is also something provided by the OS.
([[cpow]] means [[concurrent programming on Windows]])
The CLR Mutex class is a “crude” wrapper over some kernel object(s). Crude because using this Mutex involves expensive kernel transition.
In contrast, The CLR monitor is Also based on kernel objects, but minimizes kernel transition and is more effcient/cheaper. See P188 [[cpow]]. I feel this efficiency is achieved at the expense of features. For eg, CLR monitors aren’t cross-process.
CLR monitor offers 1) mutual exclusion and 2) condVar features. Entire CLR monitor including the cond var is based on kernel objects, according to [[cpow]]. The CLR monitor is considered a “
higher level of abstraction from the basic kernel objects“.
From the above analysis, the CLR offers 2 categories of sync objects — 1) wrappers over kernel objects, and 2) CLR-specific constructs.
1) Examples in the wrapper category — anything based on WaitHandle including Mutex/Semaphore
2) Examples in the CLR category —
– monitor class including Wait/Pulse
– the *Slim classes
Key differences between the two —
$ slow – kernel mode “transition” required in the wrapper objects. Therefore much slower.
$ IPC – only kernel sync objects are usable across processes. If no IPC required, then the non-kernel constructs are better (much faster).
$ P/Invoke – you could use P/Invoke to simulate many WaitHandle-based constructs
$ predate – there are win32 constructs to access the same kernel objects. They predate CLR. I think the wrappers are similar to the win32 constructs.
At the heart of this price thingy is a __fwd-starting loan__. The price is related to the interest rate on this loan, also known as FRA rate or simply fwd rate. Traders basically guess at (“bet and “trade” are less intuitive) this rate.
Implicit – loan is 3M tenor
Implicit – loan starts 2 days after expiry of the futures contract.
Implicit – this fwd interest rate is always, always, always annualized