Code Syntax Highlighting in your Blog Posts

Do you want C++ highlighted code in your blog posts? If you use Kate, you can export the HTML-formatted version of your source code, if you have enabled the HTML export extension. Use File>Save as HTML. Open the resulting file in Kate and replace the spaces with   so the spaces are well defined in your post.

Copy the code snippet form Kate into the raw HTML editor of your blog, and there is it. For examples, check below.

Debug class implementation with templates

Here is the implementation of a debug reporting system in C++, with the same interface as cerr but with the plus of implementing a static debug level in your code.

template<int compiledDebugLevel>
class DebugCls {
  public:    /// Sends an object to the standard error.
    template<class T>
    DebugCls& operator<<(const T& a) const;
    /// Allows to use manipulators on the object.
    errorCls& operator<<(ostream& (*a)(ostream&));
    /// Allows to use the object as a function.
    DebugCls& operator()(const char* msg) const;
};

DebugCls<1> debug1; ///< Debug object for level 1.
DebugCls<4> debug4; ///< Debug object for level 4.
DebugCls<6> debug6; ///< Debug object for level 6.
DebugCls<10> debug10; ///< Debug object for level 10.

Reasonable limit for new neighbor requests which have fallen beyond the available memory for a person.
const int debugLevel = 0; ///< Chosen debug level for the current build.

template<int compiledDebugLevel>
template<class T>
DebugCls<compiledDebugLevel>& DebugCls<compiledDebugLevel>::operator<<(const T& a) const {
  if (compiledDebugLevel < debugLevel)
  cerr << a;
  return *this;
}

template<int compiledDebugLevel>

DebugCls<compiledDebugLevel>& DebugCls<compiledDebugLevel>::operator<<(ostream& (*a)(ostream&)) const {
  if (compiledDebugLevel < debugLevel)
  cerr << a;
  return *this;
}

template<int compiledDebugLevel>
DebugCls<compiledDebugLevel>& DebugCls<compiledDebugLevel>::operator()(const char* msg) const {
  if (compiledDebugLevel < debugLevel)
  cerr << "Program error: " << msg << "\n";
  return *this;
}

The functions have been written outline in this example so you get an idea of the required template nesting. However, these functions are short, so you might as well inline them.

Lexmark Z43 printer and Kubuntu 9.10

Hi. This post will present in detail the steps I took with the intent to fix a Kubuntu installation to use a USB Lexmark Z43 color printer.

The problem

Although this printer works fine under Windows (at least in the tests I did), this printer has been a source of trouble with Linux. In the current, updated Kubuntu installation, you can reproduce the following problem:

1. In System Settings > Printer configuration > Lexmark (the latter is the name of the printer), click "Print test page."
2. The Ubuntu test page is printed, up to a fraction of the Cyan color strip.
3. The printer stops and the power light blinks at 0.5-1.5bps, in an irregular fashion. The computer does not report any problem with either communication or printing. The Form feed button of the printer does nothing.
4. You press the power button, the printer takes a moment until the sheet comes out of the printer and it remains on.
5. You cannot print anymore, and CUPS does not report anything. Frequently CUPS reports that the print job was finished. The syslog reports no problem.
   

 This problem does not depend on the following:

1. The printer driver being either CUPS+Gutenprint or Gutenprint.
2. The configuration of app-armor.
3. Whether /proc/bus/usb is mounted.
4. The debug level of the kernel: It still does not report anything useful.

I am so stuck with this printer, I hope somebody comes out with a solution. The problem persists with CUPS-1.3.11 in my Gentoo box.

Threads and performance in scientific C++

I like the new C++ standard, with new, great features and tools for efficient programming. I cannot wait to try the new characteristics implemented in GCC.

My current programs make heavy use of threads; as many of you might know, threads tipically work with common variables and thread-local variables. The latter are only seen by the thread they are defined into, and they are implemented as a GNU extension to the ISO C++03 standard.

Thread-local variables in threads are a bit of a burden for the compiler, linker and ELF file format. Thread-local variables are ready for use with any number of threads, which means that they are not static.

I know that my simulations use two threads, because the running processors only have two cores. So for the sake of performance, I learned to use templates to implement static thread-local variables. Here is an example:

template<int iThread>
class ThreadLocal {
    protected:
    static int staticA;
};

template<int iThread>
int ThreadLocal::a;

template<int iThread>
class ClsA : public ThreadLocal<iThread> {
    private:
        typedef ThreadLocal<iThread> tLocal;
        int a;
};

template<int iThread>
class ClsB : public ThreadLocal<iThread> {
    private:
        typedef ThreadLocal<iThread> tLocal;
        int b;
        ClsA<iThread> embeddedA;
};

ClsA<0> A0;
ClsA<1> A1;

ClsB<0> B0;
ClsB<1> B1;

Each template instantiation has its own copy of the staticA variable. This certainly has given me good performance under GCC, but any comment on tests with different compilers is welcome.

A C++ trick: avoid #define

Hello, welcome to this space. I am a fan of C++; I use if for my scientific projects, with focus on high performance. So every now and then you will see a post about some trick for practical C++ programming.

Whenever you create a new program, the need for constants can arise; it is a common practice to use #define to solve the problem:

#define probability 0.75

You might be tempted to use #define because it only exists in preprocessing, so you are guaranteed memory is not allocated for the constant. Moreover, your definition can stand across source files by using #include. Your constant will also stand out of the rest of the code thanks to the syntax highlighting of your text editor.

However, using #define will prevent the compiler to help you check for the type safety and scope of the constant in your code. Here is an example inspired by Bjarne Stroustrup:

#define alpha 'a'
#define beta b[2]
class myCls {

int alpha;
int beta;

};

The g++ compiler will complain with

test.cc:8: error: expected unqualified-id before 'a'

So the bug about beta gets away and you might find yourself looking for the cause of some rare runtime bug months from now.
Your code must have room for improvement and evolution. It is not uncommon to have a simulation running OK but weeks later you want that precise constant to become a variable, so you want to repeat the program for a range of values. Given the preprocessor does not ensure type safety, it is likely that your program will not build when you finally switch from #define to const.
The computer is made to serve you, not the opposite. You should make all possible use of the power of your computer to help you check for type safety and overall consistency of the code you write. So take the opportunity of having the compiler give you a smoother programming experience by having const instead of #define. Use the compiler optimizations and learn about the cases in which const allocates space and cases in which it does not.