I just installed Windows Live Writer, which is basically a simple frontend to various blog engines. At least, it is faster than opening the browser, selecting my blog and clicking on write entry, so I hope that I'll be able to post more regularly in the future.
For a small project of mine, I needed a really simple DB (so simple, you can't call it a DB actually ;) ). The requirements were:
- Fast lookup
- Storage of raw byte streams for both key/data
- Pure MSIL - otherwise, I would have used the BerkeleyDB
- Checksumming for each entry to detect long-term corruption
I ended up with writing a very simple DB in C# ... the trickiest part was to get the paging right, as the pages get ref-counted just like everything else, but you do actually want to know when the last handle to them finishes and flush them to disk. The DB is ~16 kb large (Binary), allows storing/loading of entries (no update so far, delete does not compact) as long as the entries are smaller than the page size. All entries are hashed before storage, so data corruption can be detected. Moreover, the index and free page table can be recreated just from the storage file. I'm using it currently for a small mail storage system, where it works pretty fine and is really simple to use -- something which was crucial to me as I often need just one simple tool for something totally different and I hate spending hours just to fiddle around with some complex solution -- for example SQLite -- to write a simple wrapper around it for my own little needs (plus, most C# wrappers require the original binaries, which often run only on x86 but not on x64 as there are no binaries for that, let alone porting it to Mono ...).
Over the last two days, I've written an extremely simple ray-tracer in C#, just as a proof of concept that this can be done in less than two hours, even without preparation. See attached screenshot... In comparison, writing a simple ray/sphere intersection routine in HLSL took roughly 10 minutes, including phong lightning on the hit-point and binding the light to a FX Composer external light source, plus the performance was much more impressive :)
Due to popular demand, I've updated the "C++ background: Static,
reinterpret and C-Style casts"
article. The update clarifies that the compiler may put the virtual
function table (if it uses one) where it wants. The only guarantee by
the C++ standard is that members inside a single declaration block
private:) will not get reordered. I remember that the fact
that C++ does not make any stronger guarantees will enable things like
deriving a class from an object which is hosted on a different heap and
still have some part on another heap -- for example, having a class
which is in part a .NET object and lives on the garbage collected heap
and the other part is native and lives on the normal heap.
[Update] Found it:
Others had often questioned the use-fulness of C++'s leaving that implementation door open for the future, but the mixed type design -- where parts of the same logical object must be on different physical heaps -- vindicates Bjarne's design judgment.
from Herb Sutter's C++/CLI Rationale, page 18.
Ever needed to fire up a 32bit Explorer on Vista x64, for example, to
get the PDF Thumbnails? Run this from a command line:
%windir%\syswow64\explorer.exe /separate. That's it!