Thankfully, further search turned up a solution by Pieter Op de Beeck posted in microsoft.public.vc.mfc ten years ago. go figure.

In case you stuble onto this, you'll probably want the fix right away, so here it is: MemoryLeakDetector.zip

I had a very different concern. The package uses a rather wide margin, in order to place nice marginpars thruout the text. Thats fine by me, it also allows for a nice small text layout without resorting to multiple columns. I did not like this for the typesetting of figures, especially large figures spanning a whole page or the top half thereof. So, I ventured out to change this. After some searching I came across the neat changepage package, which most of all allows for save determination of even and odd pages. With this, it was fairly straightforward to implement. I chose to provide a widefigure environment to typeset full-width figures with [p] or [t].

% wider floats by use of changepage. 
% see changepage documentation for details on the underlying quirks
\usepackage[strict]{changepage}  
% calculate size of margin to use
\newlength\totalmargin
\setlength\totalmargin\marginparwidth
\addtolength\totalmargin\marginparsep
% layout using the full margin as well
\newenvironment{layoutfullwidth}{%
\checkoddpage%
\ifoddpage%
\begin{adjustwidth}{0pt}{-\totalmargin}
\else%
\begin{adjustwidth}{-\totalmargin}{0pt}
\fi%
% advance textwidth for use in float,
% e.g. includegraphics[width=\textwidth]
\advance\textwidth\totalmargin
}{%
\end{adjustwidth}
}
% new, wider figure to use where wanted.
% note that the caption will be layouted wide as well.
\newenvironment{widefigure}[1][!tpb]{%
\begin{figure}[#1] 
\begin{layoutfullwidth}
}{
\end{layoutfullwidth}
\end{figure}

This is a straightforeward way of doing it, changing the typesetting of all floats in general requires some really ugly plain TeX hacking. I got it to work out of playful ambition but decided against using it in order to keep the code clean and understandable.

1. Start X with an empty configuration or sudo nvidia-xconfig and only one monitor
2. Connect the second monitor
3. Start nvidia-settings and add the second monitor. Save the configuration.
4. If the Resolution is not sufficent, add Monitor sections for all Monitors and set the metamodes to auto

So, my xorg.conf now looks like this:

# twinview, both monitors set via section and nvidia-auto-select

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "ServerFlags"
    Option         "Xinerama" "0"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
  Identifier "Scott"
  Modelname "hr17c"
  VertRefresh 60-100
  HorizSync 42-80
  DisplaySize 325 243
  Modeline "1280x1024@75"  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync
  Option "DPMS"
EndSection

Section "Monitor"
  Identifier "Samsung"
  Modelname "226BW"
  VertRefresh 56-75
  HorizSync 30-80
  Option "DPMS"
  DisplaySize 474 296
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 7600 GT"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Samsung"
    DefaultDepth    24
    Option         "TwinView" "1"
    Option         "TwinViewXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DFP: nvidia-auto-select +0+0, CRT: nvidia-auto-select +1680+0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

// div width by number of virtual processors, min = 128, max = none
int slice = AP_MP::getSlice(width,128,-1); 
int xStart;
#pragma omp parallel for private(xStart)
for (xStart=0;xStart<width;xStart+=slice) {
  int xEnd = xStart+slice;
  if (xEnd>width) xEnd=width;
  calcSlice(..,xStart,xEnd); 
}

As I hoped, the calculations were indeed 1.3-1.8 times faster on a dual-core machine, which is quite nice for such limited effort. The following table gives the min/median/max times in ms for a 2.8s audio file sampled with 16bit at 22050Hz. Spectrum is a pure magnitude spectrum calculation, Spectrogram represents a rendering of a spectrogram image, the Auditory Spectrogram includes a rather lengthy masking calculation. g++ -O3 -ffast-math is up to four times faster for the core routines, but that lessens for larger code segments. The Auditory Spectrogram is slightly faster on Windows.

Undusting my R, I was able to generate a nice box-plot of the results:

The calculation is performed by splitting the 64 bit multiplicant in two halves. So far, so obvious.

Where is split again into the division canceled by 2^32 and the remainder (modulus). The modulus part may still be 64 bit, so it may have to be calculated by canceling appropriate powers of two via shifted by according to the MSBs.

That last part took me a bit longer than anticipated, given that it has in fact been years since I saw bits at all while coding. The MSB determination origniates in the astounding Bit Twiddling Hacks by Sean Eron Anderson. So, anyway, enjoy or abhorr the following end result:

/** the two 32 bit parts of an 64 bit integer */
typedef struct  { 
    uint32_t l : 32;
    uint32_t h : 32;
} uint64_uint32;

/**
 * determine the msb of a value in O(log log n)
 * @author Sean Eron Anderson
 */
inline unsigned int msb(uint64_t value)
{
    const int MAX_LOGLOG = 6;
    const uint64_t BIT_LL[MAX_LOGLOG] = {0x2, 0xC, 0xF0, 0xFF00, 0xFFFF0000, 0xFFFFFFFF00000000LL};
    const unsigned int EXP_LL[MAX_LOGLOG] = {1, 2, 4, 8, 16, 32};
    unsigned int r = 0; 
    for (int i = MAX_LOGLOG-1; i >= 0; i--)  {
        if (value & BIT_LL[i])  {
            value >>= EXP_LL[i];
            r |= EXP_LL[i];
        } 
    }
    return r;
}

/** 
 * multiply a 64 and a 32 bit value and divide them by a 64 bit value.
 * result bits above 64 are ignored, so overflow flags are not set.
 * @author Axel Plinge
 * @param number       64 bit multiplicant
 * @param numerator    32 bit multiplicant
 * @param denominator  64 bit divisor
 * @return  (number*numerator)/denominator (+/-) 1 
 */
inline uint64_t muldiv(uint64_t number,uint32_t numerator,uint64_t denominator)
{
    uint64_t num_h = ((uint64_uint32*)&number)->h;
    uint64_t num_l = ((uint64_uint32*)&number)->l;
    uint64_t mul = numerator;
    uint64_t res;
    // lower 32bit portions yield 64 bit product
    // that can be divded directly giving 64 bits of result
    res = (num_l * mul)/denominator;
    // upper 32bit have to be shifted, calculate modulus 2^32
    uint64_t product_h = num_h*mul;
    uint64_t div_h = product_h/denominator; // division main
    uint64_t mod_h = product_h - denominator*div_h; // modulus
    // upper bits
    res += div_h<<32;
    if (mod_h==0)  {
	return res;
    }
    // remainder of division
    // if msb modulus < 32 we can be quick about it	
    if ((mod_h>>32)==0) {
        res += (mod_h<<32)/denominator;
        return res;
    }
    // if we reach this point we have full 64 bit values i.e. a 96bit dividend
    // calculate an approximate result by shifting according to msb set
    int msb_nominator = msb(mod_h)+32;
    int msb_denominator = msb(denominator);
    int msb = std::max(msb_nominator,msb_denominator);
    int shift = msb-63;
    res += (mod_h << (32-shift)) / (denominator>>shift);
    return res;
}

class A {
public:
   virtual void foo(int i) {
      cout << "A::foo(int " << i << ")" << endl;
   }
   virtual void foo(double d) {
      cout << "A::foo(double " << d << ")" << endl;
   }
};

class B : public A {
public:
   virtual void foo(int i) {
      cout << "B::foo(int " << i << ")" << endl;
   }
   virtual void foo(double d) {
      cout << "B::foo(double " << d << ")" << endl;
   }
};

When calling them, the correct one is identified since foo(int) and foo(double) get seperate vtable entries. A quick test:

void callFoo(A& a) {
   a.foo(1.5);
   a.foo(3);
}
..
A a;	
callFoo(a);
B b;
callFoo(b);

However, things get confusing very easily. For both programmer and compiler. For example, when calling foo with an unsigned long, many compilers simply issue an error forcing you to cast explicitly or add another overload. Which has to be consistent over the whole class hierarchy, as everything you do here. This may not seem too difficult, however, its added risk. When working with some code I last touched 10 years ago, I stumbled more than once. So, to avoid confusion, one of the two has to go. Let's keep inheritance since it's most vital:

class C  {
public:
   virtual void fooInt(int i) {
      cout << "C::fooInt(" << i << ")" << endl;
   }
   virtual void fooDouble(double d) {
      cout << "C::fooDouble(" << d << ")" << endl;
   }

Now you as programmer have to choose the variant, not the compiler. A call to fooInt will cast any argument to (int) and that's that.

So, what if you REALLY need the compiler to choose, e.g. when using C in a template? The solution is a type-switch with a template method as proposed in the CppFaqLite. This is not especially beautiful, but leaves the above separation intact.

   template <typename type>
   inline void fooTemplated(type arg);

   template <>
   inline void fooTemplated(int arg) {
      cout << "templated ";
      fooInt(arg);
   }

   template <>
   inline void fooTemplated(double arg) {
      cout << "templated ";
      fooDouble(arg);
   }

};

template <typename type>
inline void C::fooTemplated(type arg) {
   throw runtime_error("fooTemplated called with unforseen type");
}

Suffice to say that the above type-switch has to be written inline as shown above to avoid visibility issues when compiling.

I may also remark that I wrote C++ happily for 12 year before introducing this construct. ;-) Nevertheless, remember to beware of clever code. It may come back to haunt you..

  [5] Fred, H., Z. Spät und H. Müller: Hobeln für Fortgeschrittene, 1. Auflage, Spanverlag, 2009

Habe ich mich nach Alternativen umgesehen. Da ich nicht gleich auf die volle DIN1505 Variante wechseln wollte, habe ich in einer Runde Mitternächlichem Syntaxraten den Stil zu einem für mich akzeptabeln Kompromiss angepasst. Es ware mit der Änderung von nur zwei Zeilen in format.names getan:

257c256
<         { s nameptr "{ll}{, jj}{, ff}{~vv}" format.name$ 't :=
---
>         { s nameptr "{ff~}{vv~}{ll}{, jj}" format.name$ 't :=
259c258
<             { "; " * t smallcaps * }
---
>             { ", " * t smallcaps * }

Hier die geänderte Datei: gerplain2.bst (Name, V.; Name, V. und Name, V.)

Somit habe ich jetzt Verweise der etwas kanonischeren Form

  [5] Fred, H.; Spät, Z. und Müller, H.: Hobeln für Fortgeschrittene, 1. Auflage, Spanverlag, 2009

Alternativ kann man auch grundsätlich mit den Initalen beginnen, hier ist nur eine Zeile zu ersetzen.

277c276
<         { s nameptr "{ff~}{vv~}{ll}{, jj}" format.name$ smallcaps }
---
>         { s nameptr "{ll}{, jj}{, ff}{~vv}" format.name$ smallcaps }

Hier die fertige Datei: gerplain3.bst (V. Name, V. Name und V. Name)

Diese Variante liesst sich etwas angenehmer, begünstigt aber weniger das vertikale Scannen der Nachnahmen:

  [5] H. Fred, Z. Spät und H. Müller: Hobeln für Fortgeschrittene, 1. Auflage, Spanverlag, 2009

Ist natürlich alles Geschmacksache, aber ich hoffe erstmal das ich sobald nicht wieder eine bst Datei lesen muß.

So, not without some complications, I set up my very own refbase installation.

It basically unties the usage of bibtex with web storage of the PDF files and a Database backend. While the latter could be more advanced, the possibilty to use and store plain SQL Queries makes up for a lot. I may not resist to contribute to the code, though.

As for now, I'll give it a try as it is, and see how it feels.

Cheers

Axel