MATLAB design faults

I love talking about (programming) language design. MATLAB is not one of those languages, I consider “intuitive” and “pragmatic” the very first time I saw it. Using it myself for my assignments at university, I continue my critical objections. I want to provide two elements, which disturb me:

1. Indexing is done with the parentheses operator. However, you cannot chain them.

>> a = [1,2;3,4]

a =

     1     2
     3     4

>> size(a)

ans =

     2     2

>> size(a)(1)
Error: ()-indexing must appear last in an index expression.
 
>> 

The solution is to address the value in the first indexing operator: size(a, 1). To be consistent in terms of syntax and semantics, both versions are required to work.

2. Rows and columns operators

>> a = [1,2;3,4]

a =

     1     2
     3     4

>> a = [1,2,3,4]

a =

     1     2     3     4

>> a = [1,2,
3,4]

a =

     1     2
     3     4

>> a = {'Lorem', 'ipsum', 'dolor', 'sit', 'amet,', 'consectetur', 'adipiscing', 'elit',
'Quisque', 'ornare', 'ante', 'eu', 'augue', 'pharetra', 'varius'};
Error using vertcat
Dimensions of matrices being concatenated are not consistent.

So basically “,” is the operator for defining columns in a matrix. “;” does the same for rows. However, if you use a newline, it turns out to be an operator for separating rows and overwrites any “,” provided. This is even worse if you try to define a sequence of words and use newline to avoid exceeding the 80-characters source code lines limit.

MATLAB design faults

constexpr is not a superset of const

Tags: C Plus Plus, C++11, const, constexpr, compile-time, static, char

There is some discussion going on whether or not “constexpr implies const”. I would like to show a snippet of source code that g++ (x86_64-linux-gnu, posix, 4.7.2) nowadays makes a difference between “const” and “constexpr const” (to be honest: only with a warning :-/ ):

The following source code uses only “constexpr”.

#include <iostream>
 
template<typename SPEC, int AGE=3>
class Monster {
public:
  static constexpr char* NAME = SPEC::NAME;
};
 
struct Cookie {
    static constexpr char* NAME = "Sesam";
};
 
int main() {
    std::cout << Monster<Cookie>::NAME << std::endl;
}

The output looks like this:

meisterluk@unix ~ % g++ -std=c++11 -Wall snippet.cpp
snippet.cpp:10:35: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
meisterluk@unix ~ % ./a.out
Sesam
meisterluk@unix ~ %

The warning is left out if we provide a “const” as well as “constexpr” declaration:

#include <iostream>
 
template<typename SPEC, int AGE=3>
class Monster {
public:
  static constexpr const char* NAME = SPEC::NAME;
};
 
struct Cookie {
    static constexpr const char* NAME = "Sesam";
};
 
int main() {
    std::cout << Monster<Cookie>::NAME << std::endl;
}

When compiling:

meisterluk@unix ~ % g++ -std=c++11 -Wall snippet.cpp
meisterluk@unix ~ % ./a.out
Sesam
meisterluk@unix ~ %

As far as I can tell I need all this non-intuitive source code, because I needed compile-time compilation. Templates require declaration as well as definition to be in the header file. But static const need the definition to be outside of the class. This is a contradiction. However, with constexpr and const it actually works.

constexpr is not a superset of const

Include cryptominisat as library with cmake

Tags: cmake, ExternalProject, cryptominisat, library, compilation, make, make install, automake

Usecase

I want to include cryptominisat as a library to my project using cmake for its compilation process. A blog article by msoos explains how to compile cryptominisat as a library to your C++ project, but as far as I am not triggering g++ myself but through cmake, I needed an integration into cmake.

Compilation

With root I mean the location of CMakeLists.txt (project root) which is provided as argument to cmake.

cmake has to trigger ./configure, make and make install for the library stored in libs/cmsat-2.9.6 (relative to root). The project will be compiled in the build/libs subdirectory (relative to root) as defined in the CMSAT_BUILD_DIR variable. If we compile the project with cmake .. && make, the CMSAT source code has to be compiled with automake and linked against the executable binary. In a second run (CMSAT has already been compiled and not modified) it should be linked without compilation. If you do a make clean before the make, the library will be compiled from scratch again.

ExternalProject

The folks at #cmake (freenode.org) suggested to use the ExternalProject module (cmake --help-module ExternalProject). Therefore you have to use this INCLUDE command and I defined the build directory as a separate variable. You have to include the header files with the INCLUDE_DIRECTORIES instruction and the LINK_DIRECTORIES command tells the linker where to look for libraries.

INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/includes ${CMAKE_SOURCE_DIR}/libs/cmsat-2.9.6)

INCLUDE(ExternalProject)
SET(CMSAT_BUILD_DIR ${CMAKE_CURRENT_SOURCE_DIR}/build/libs)
ExternalProject_Add(
  CMSAT
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/cmsat-2.9.6
  CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/libs/cmsat-2.9.6/configure --prefix=${CMSAT_BUILD_DIR}
  BUILD_COMMAND make
  INSTALL_COMMAND make install
)
LINK_DIRECTORIES(${CMSAT_BUILD_DIR}/lib)

After this definition I have to add it as a library for the linker to the executable binary:

TARGET_LINK_LIBRARIES(executable cryptominisat)
#ADD_DEPENDENCIES(executable cryptominisat)

ADD_DEPENDENCIES does not change the behavior. I think it’s better to add it for additional semantics.

Include cryptominisat as library with cmake