If you get errors that don’t make any sense (like when using std::map::insert(iterator, std::make_pair(T, Y)) ) make sure to compile/link with stlport4. The latter is provided by sun together with the compiler.
CC -library=stlport4 a.cpp
Boyer-Moore is a popular implementation of string search algorithm. Details are available here.
I implemented it for both Java and C. The test was to search a string of 6 characters from a file of 20MB which was previously read entirely in memory. Only the actual search was measured. I was expecting poor Java performance but I was bewildered of how bad it performed.
The C implementation found the searched string in about 310ms. The Java one found the same thing in about 44700ms. I didn’t make any effort to optimize the C or the Java implementations.
The test file is users.xml from the stackoverflow dump.
Java implementation is BoyerMoore.java
C implementation is boyer-moore.c
This is a simple problem: how do you go about copying keys of items you have in a map to a vector (containing items with the same type as the keys).
The simplest solution I have found is below
template
typename T::key_type key(const typename T::value_type& v)
{
return v.first;
}
...
std::map my_map;
std::vector dest(my_map.size());
std::transform(my_map.begin(), my_map.end(), dest.begin(),
key >);
...Could it be done simpler than this?
If you need to have state saved between two invocations of the same function you could use a global variable (using the “global” keyword). But we all know global variables are wrong leading to hard to find bugs. Another solution would be to use a “static” variable. In c++/c variables declared with the static keyword inside functions are not allocated on the stack but in the data segment. That means that they hold state between different invocations of the same function and are only initialized the first time the function is called.
Static variables do not exist in python but we can use a different trick: function default mutable parameters are only evaluated once:
def f(list = []): list.append(1) print(list)
The first time you call f() it will output [1], but the second time it will output [1, 1]!
The default mutable parameter is only evaluated once and, then, its reference is used inside the f function. We can use that to our advantage. Let’s say we need a static counter:
class Counter:
def __init__(self):
self.counter = 0
def get(self):
self.counter = self.counter + 1
return self.counter
def f(counter = Counter[])
print(counter.get())
Between different invocations of f() the counter will be incremented.
Postmortem debugging is analyzing leftovers (memory, list of threads) of a program that has fatally crashed.
When that happens there are two options in the Windows environment:
However if one wants to use a different debugger, like for example the excellent WinDbg, for
postmortem debugging, one needs to modify the registry so that WinDbg is launched in the place
of a Visual Studio debugger. That operation can be performed automatically by WinDbg when launched with the parameter “-I”. After execution WinDbg will report if it could modify the registry successfully.
Sadly there is no undo for the last operation. Once the registry is modified there is no WinDbg parameter to be able to use Visual Studio for debugging. For that we need to get our hands dirty and modify the registry ourselves (do I need to say you should be extra-careful with that?). The respective key is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
You need to modify it to
“C:\WINDOWS\system32\vsjitdebugger.exe” -p %ld -e %ld
This way vsjitdebugger.exe will offer you a choice of available postmortem debuggers and Microsoft Visual Studio is in there.
I searched hi and lo for a *simple* tracer for my c++ programs. It had to be:
I couldn’t find any to suit my needs so I developed my own which you can find
here.
Tried on g++ 4.1.3 on linux:
#include <iostream>
void x()
{
static int i = 0;
std::cout << "Depth " << i++ << std::endl;
x();
}
int main()
{
x();
}
There is a segmentation fault at “Depth 261811” 
I follow this guideline (which I read somewhere): assert around things that could never ever happen and throw exception for things that *might* happen. A short example:
int main(char* argv[], int argc)
{
// argv[0] always contains the program name, so argc always >= 1
assert(argc >= 1);
if ( argc < 2 )
{
// two parameters are expected.
throw std::runtime_exception("not enough parameters");
}
}
By default WinDbg will only break on second chance exceptions (that is there was no handle for the exception).
In order to break on first chance exceptions (where the exception was originally thrown) the right command is: sxe *
This will stop the debugger whenever any exception is thrown.
To undo: sxd * and the debugger will only stop on second chance exceptions.
Limited access destructors can be useful in order to enforce ownership of an object.
In the most obvious case a destructor is “public” and that is the case we all know.
When a destructor is declare as “protected” it cannot be destroyed from outside the class. That is you cannot declare an automatic variable of that type and if you allocate space on heap then “delete obj;” won’t work. The destructor is protected and the “delete” operator doesn’t have access to it. However you can call “delete” from inside the object by using some scheme of ownership management counted ref or other (ie when using a COM interface you first need to call AddRef and Release when you’re done).
If the destructor is private the compiler won’t allow inheriting that respective class. Alas I don’t think private destructors are very useful.