In the second of an unknown number of parts in my series of Beginning F# posts, I’ll be talking about record types. They’re a useful and powerful F# feature that you’ll probably find yourself using very widely. I’ll take a look at what they are, how they’re used and how they integrate with the rest of the language.
Continue reading Beginning F#: Records
Tag Archives: c++
C++: The oldest new kid on the block
Nobody could have failed to notice the recent resurgence of interest in the C++ programming language. In particular, the recent Build conference was the most we’ve seen Microsoft talking about C++ for several years. Why has a language that’s been languishing in the “prehistoric irrelevance” category for so long suddenly come back into vogue?
Continue reading C++: The oldest new kid on the block
Modifying the VC runtime to get better heap allocation stack traces
Today I was trying to track down some – how can I put this politely – “unusual” memory usage in some unmanaged code running inside Excel. I broke out WinDbg and tried the usual suspects to get an idea of how memory was being used. Unfortunately, the way that msvcr80.dll is built stopped me from getting decent stack traces for the allocations, so I decided to try and rebuild it with a fix to remedy the situation.
Continue reading Modifying the VC runtime to get better heap allocation stack traces
Where’s my window?
On Windows, if you regularly change screen resolution or size, perhaps by accessing a machine remotely, you might find some of your application windows are no longer visible; they’re positioned outside of the visible display area. If you can’t see the window, it can be a little difficult to use the application. How can you get that window back?
Continue reading Where’s my window?
Beware of using stack-based COM objects from .NET
There are all sorts of nasty things to be aware of if you’re mixing reference-counted COM objects with garbage-collected .NET. For instance, if you’re implementing COM objects in C++ then you’re free to allocate them anywhere you like; on the heap or perhaps on the stack if you know they’re only used in some specific scope.
But what happens if during the lifetime of that stack based COM object, it gets used from .NET? A runtime callable wrapper (RCW) will be created around the object. And this RCW expects to be able to keep the underlying object alive by incrementing its reference count. Of course, the stack-based object will soon go out of scope, and regardless of its reference count the object will be destroyed and the pointer that the RCW contains will no longer be valid. It points into the stack, so when the RCW gets cleaned-up, the CLR will call via this pointer into memory that contains garbage and you’ll get something nasty like an access violation or illegal instruction exception.
Continue reading Beware of using stack-based COM objects from .NET
Don’t do anything in DllMain… Please
Novice Windows programmers can often think that DllMain is a good place to get that one-time set-up and tear-down work done. It seems to offer an ideal opportunity to know when your DLL has just been loaded, and when it’s about to be unloaded. What better place to add all that expensive, complicated initialisation…? STOP! WAIT! Before you add anything in DllMain, make sure you understand what state the process will be in when it gets called. Once you know that, you may well change your mind…
Continue reading Don’t do anything in DllMain… Please
Comparing lambdas in C++ and F#
The other day someone pointed me to the new MSDN article on C++ lambdas in Visual Studio 2010. Interesting. C++0x has been a long time coming, but in my opinion anything that makes C++ usable at a higher level of abstraction is a good thing. There’s nothing wrong with a little abstraction, as long as you can get to the fundamentals if you need to. Otherwise you wouldn’t be using C++, would you?
But one of the things I couldn’t get over from that article is the verbosity. I’ve just got too used to the succintness of F#. I know this is only example code, so it’s intended to demonstrate usage, but the whole point of lambdas is to reduce boilerplate and make the intent of your code more obvious. So, let’s compare the C++0x implementation with the F# version.
Continue reading Comparing lambdas in C++ and F#
Finding the largest free block of address space
I’ve been seeing problems recently with fragmented virtual address space. During the lifetime of a process, bits and pieces of memory are allocated throughout the 2GB 32-bit address space to such an extent that large contiguous blocks of free space are no longer available. If anything subsequently requires a large block of memory (like, for instance, a somewhat out-of-date version of the GHC runtime), it will fail to get it.
It’s obvious looking at the output from VMmap or windbg’s !address command what the largest contiguous block is, e.g.
0:008> !address -summary .... Largest free region: Base 07300000 - Size 63ed0000 (1637184 KB)
But what if you need that number in order to make a decision at run-time? For instance, to decide whether your process is in a fit state to continue, or if it should instead commit hara-kiri. In that case, you need to access the information programmatically. That’s where the immensely useful VirtualQueryEx function comes in…
Continue reading Finding the largest free block of address space
Static libraries are Evil
In my opinion.
Why? Well, because it’s too easy to use them as an excuse for not defining your shared library interfaces properly.
The reason this is on my mind recently is that several hundred, yes, you heard that right, several hundred DLLs have been released by my group over the last, ooh, 10 years or so. They are all still in use. Each of them has burned into it a copy of the library that deals with interfacing with Excel. That means each of these has it’s own little internal copy of the current state-of-the-art. The problem with that is; the state-of-the-art moves on. And how do you go about updating the DLLs that are already in production? You have to re-release them. In an environment where thes DLLs are used for marking the profit and loss on a large derivatives trading book, that’s not a small undertaking. And it’s made worse if, say the DLL in question was last released with a different version of the compiler.
My approach would be to refactor this shared static library (.lib) into a stand-alone DLL.
At this point, people start saying “oh, but then you’ve got a single point of failure, if you release a broken version of that DLL, everything will stop working!”. Not exactly a compelling argument. If the functionality of the DLL is well defined, and there are well known entry points it should be easy to put together a comprehensive black-box test suite. In fact we already do that with all our other DLLs (COM servers). The fact that this shared library *isn’t* a DLL has meant that it’s fallen through the testing cracks; another good reason to refactor it.
The internal interface to the shared library is already relatively well defined. It has a set of header files that define all of the functions and classes that are consumed by others. It’s a relatively small step to compile it as a DLL, rather than a static library. The problem then becomes one of maintenance, dealing with the inevitable changes to the external interface in a backwardly compatible way.
And that’s the problem. It requires some effort. Elsewhere in our codebase we use COM as a magic cure-all for avoiding having to deal with versioning: interface immutability rules. All interfaces are public, no published interface ever changes, object identity is based purely on interfaces supported. If you haven’t got these crutches to rely on, then you have to enforce the rules yourself, which can be both logistically and technically difficult when you’re dealing with C++.
But it’s not impossible. And I really think it would be better than having hundreds of DLLs all containing subtley different versions of the same code, and being unable to change behaviour across the board without having to build, test and release them all.
Maybe you’ve got a different opinion?