Linux command cheatset

A; B    Run A and then B, regardless of success of A
A && B  Run B if A succeeded
A || B  Run B if A failed
A &     Run A in background.

get from here.

Памятка по компиляции shared libraries

Для начала код разделяемых библиотек (три файла: foo.h, foo1.cpp, foo2.cpp):

// foo.h #ifndef foo_h__ #define foo_h__ extern "C" __attribute__ ((visibility("default"))) void foo(void); #endif // foo_h__ // foo1.cpp #include <stdio.h> #include "foo.h" __attribute__((constructor)) void foo_init() { puts("Init shared library 1"); } __attribute__((destructor)) void foo_deinit() { puts("Deinit shared library 1"); } void foo(void) { puts("Hello, I'm a shared library 1"); } // foo2.cpp #include <stdio.h> #include "foo.h" __attribute__((constructor)) void foo_init() { puts("Init shared library 2"); } __attribute__((destructor)) void foo_deinit() { puts("Deinit shared library 2"); } void foo(void) { puts("Hello, I'm a shared library 2"); }

Теперь код, загружающий библиотеки и использующий их функционал (main.cpp):

#include <stdio.h>
#include <dlfcn.h>
 
//gcc -o main main.cpp -ldl
 
int main() 
{    
    void *h1, *h2;
    // define function prototype
    typedef void (*foo_fn_ptr)(void);     
    // function pointers
    foo_fn_ptr foo1, foo2; 
    char *error;
 
    // open first library
    h1 = dlopen ("./libfoo1.so", RTLD_LAZY);
    if(!h1)
    {
        fputs(dlerror(), stderr);
        puts("");
        return 1;
    }
 
    // get function from first lib
    foo1 = (foo_fn_ptr) dlsym(h1, "foo");
    error = dlerror();
    if (error) 
    {
        puts(error);
        return 1;
    }
 
    // use function
    foo1();
 
    // load second lib
    h2 = dlopen ("./libfoo2.so", RTLD_LAZY);
    if(!h2)
    {
        fputs(dlerror(), stderr);
        puts("");
        return 1;
    }
 
    // get function from second lib
    foo2 = (foo_fn_ptr) dlsym(h2, "foo");
    error = dlerror();
    if (error) 
    {
        puts(error);
        return 1;
    }
 
    // use function
    foo2();
 
    // unload libraries
    dlclose(h1);
    dlclose(h2);
 
    return 0;
}

Как все это собирать. Сначала соберем наши shared objects:

gcc -Wall -Werror -o libfoo1.so -shared -fpic foo1.cpp
gcc -Wall -Werror -o libfoo2.so -shared -fpic foo2.cpp

Теперь соберем наш исполняемый файл, который загружает и использует эти библиотеки:

gcc -o main main.cpp -ldl

У нас все собрано и готово, надо только добавить папку, где лежат наши библиотеки в список путей, откуда их можно загружать:

export LD_LIBRARY_PATH=$PWD

Теперь можно запустить:

./main 
Hello world!
Init shared library 1
Hello, I'm a shared library 1
Init shared library 2
Hello, I'm a shared library 2
Deinit shared library 1
Deinit shared library 2

Ниже пояснения.

Код библиотек.
Зачем нам нужен extern "C"? Строго говоря, не нужен, потому что по умолчанию GCC (нынешняя версия, по крайней мере), экспортирует все функции и они доступны для использования, но есть один нюанс. Можно закомментировать эту строчку, пересобрать библиотеку и вместо увидеть ошибку "./libfoo2.so: undefined symbol: foo". То есть функция dlsym не находит символа "foo" в библиотеке, хотя мы точно знаем, что он там есть. С помощью nm мы просмотрим таблицу экспорта нашей библиотеки:

$ nm -D ./libfoo2.so
0000000000201028 B __bss_start
                 w __cxa_finalize
0000000000201028 D _edata
0000000000201030 B _end
00000000000006b4 T _fini
                 w __gmon_start__
0000000000000548 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 w _Jv_RegisterClasses
                 U puts

0000000000000733 T _Z10foo_deinitv
0000000000000720 T _Z8foo_initv


00000000000006a0 T _Z3foov
$ 

Вот эта последняя строчка "_Z3foov" и есть имя нашей экспортированной функции и это очевидно не то же самое, что "foo". Теперь раскомментируем строчку extern "C", пересоберем библиотеку и запустим nm еще раз:

$ nm -D ./libfoo2.so
0000000000201028 B __bss_start
                 w __cxa_finalize
0000000000201028 D _edata
0000000000201030 B _end
000000000000075c T _fini
0000000000000746 T foo
                 w __gmon_start__
00000000000005d0 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 w _Jv_RegisterClasses
                 U puts
0000000000000733 T _Z10foo_deinitv
0000000000000720 T _Z8foo_initv
$ 

Теперь мы видим "foo" и у нас все опять работает:

./main 
Hello world!
Init shared library 1
Hello, I'm a shared library 1
Init shared library 2
Hello, I'm a shared library 2
Deinit shared library 1
Deinit shared library 2

Это все связано с правилами наименования экспортируемых функций, можо погуглить "name mangling", а extern "C" принудительно заставляет компилятор именовать функции по простым и ясным правилам языка C.
Что же насчет __attribute__ ((visibility("default"))), то по умолчанию все функции и так имеют видимость default, но, во избежание всяких неожиданностей типа нестандартных флагов компилятора, мы добавляем этот флаг в каждую экспортируемую функцию.

Сборка библиотек.
Компилируем и создаем из объектного файла shared object двумя отдельными командами.
Компиляция:

gcc -c -Wall -Werror -fpic foo1.cpp

Все нюансы тут состоят в использовании флага pic (Position Independent Code), что необходимо для динамически загружаемых библиотек (статические библиотеки не нуждаются в таком флаге).

Сборка происходит так:

gcc -shared -o libfoo1.so foo1.o

gcc -Wall -Werror -o libfoo1.so -shared -fpic foo1.cpp

тут используется специальный флаг shared для создания динамических библиотек. То же самое одной командой:

gcc -Wall -Werror -o libfoo1.so -shared -fpic foo1.cpp

Сборка main.

Все как обычно, но линкуем библиотеку dl, которая содержит dlopen, dlsym, dlclose и прочие фукции:

gcc -o main main.cpp -ldl

Настройка окружения и запуск.

В linux библиотеки лежат в строго определенных местах и откуда-то еще их загрузить не получится (в отличии от Windows), поэтому, когда мы запустим программу в первый раз, мы увидим что-то такое:

$ ./main 
./libfoo1.so: cannot open shared object file: No such file or directory
$ 

Чтобы добавить новый путь, делаем следующее:

export LD_LIBRARY_PATH=$PWD

В bash переменная окружения PWD хранит текущую папку. Теперь все работает.

Ссылки:
http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html
http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
http://www.keil.com/support/man/docs/armcc/armcc_chr1359124983511.htm
https://www.cyberciti.biz/faq/linux-list-all-environment-variables-env-command/
http://www.cprogramming.com/tutorial/function-pointers.html
http://www.microhowto.info/howto/build_a_shared_library_using_gcc.html

C++ command line helper

Иногда надо исполнить какую-то команду ОС. Это легко делается с помощью создания нового процесса и получение данных от него через пайп:

#include <iostream>
#include <stdio.h>
#include <memory>
 
bool run_shell_cmd(const std::string & cmd, std::string & outputStr)
{
    int closePipeResult = -1;

    // deleter to close pipe
    auto pipeDeleter = [&closePipeResult](FILE* pipe)
    {
        if(pipe != NULL)
            closePipeResult = pclose(pipe);
    };

    // create smart poinetr with custom deleter
    std::unique_ptr<FILE, decltype(pipeDeleter)> pipe(popen(cmd.c_str(), "r"), pipeDeleter);
 
    if(pipe.get() == NULL) 
        return false;
 
    // read output and save it to string
    char buffer[128];
    while (!feof(pipe.get()))
    {
        if (fgets(buffer, 128, pipe.get()) != NULL)
            outputStr += buffer;
    }
 
    // reset pointer to get result of pclose before exit of function
    pipe.reset();
 
    return (closePipeResult == 0);
}

Google Test Gmock

Предположим, мы разрабатываем клиента для некоего сервера, а сервер разрабатывается совсем другой командой и на данный момент он либо неработоспособен, либо вообще недоступен (очень частая ситуация на самом деле). Единственное, что у нас есть - это интерфейс этого сервера без имплементации в виде исходных файлов или бинарей. В таких случаях обычно делают какой-то простой сервер-заглушку, который по крайней мере позволяет проводить на нем отладку клиентской части. Это достаточно трудоемко и именно для того, чтобы избавить программиста от ненужной работы, и был создан gmock как часть Google Test Framework.
Лучше всего показать на примере.

// our server (we have interface only)
class IMyCalcServer
{
public:
    virtual int add(int a, int b) = 0;
    virtual int mult(int a, int b) = 0;
    virtual ~IMyCalcServer() {}
};
 
// client class
class MyClient
{
public:
    MyClient(IMyCalcServer * server) : srv(server) {}
    void doMath()
    {
        std::cout << "add " << srv->add(2, 2) << std::endl;
        std::cout << "mult " << srv->mult(1, 2) << std::endl;
    }
private:
    IMyCalcServer * srv;
};
 
// implementation of IMyCalcServer interface by gmock
class CalcServerMock : public IMyCalcServer
{
public:
    MOCK_METHOD2(add, int(int a, int b));
    MOCK_METHOD2(mult, int(int a, int b));
};
 
TEST(MyGmockTest, test1)
{
    // create instance of "InSequence" class to force gmock expect function calls in stict order
    ::testing::InSequence dummy;
 
    // here we create server instance, define calls order, parameters and return values
    CalcServerMock calcSrvMock;
    // we expect add() is called with parameters (2,2) and returns 4
    EXPECT_CALL(calcSrvMock, add(2,2)).WillOnce(testing::Return(4));
    // we expect mult() is called with parameters (2,2) and returns 4
    EXPECT_CALL(calcSrvMock, mult(2,2)).WillOnce(testing::Return(4));
 
    // do calculations
    MyClient cl(&calcSrvMock);
    cl.doMath();
}

Использование is_base_of и enable_if и детектирование типов во время компиляции

Допустим у нас есть некая функция, которая должна быть определена только для наследников определенного класса. Можно сделать это в рантайме, но детектирование типов в рантайме это дорого и к тому же некрасиво. C++11 предлагает более красивое решение.

#include <iostream> #include <type_traits>   class A { public: virtual void do_work() = 0; };   class B : public A { public: void do_work() override { std::cout << "B::do_work()" << std::endl; }; };   class C { public: void do_work() { std::cout << "C::do_work()" << std::endl; }; };   template<typename T> typename std::enable_if<std::is_base_of<A, T>::value, void>::type execute_work(T &t) { t.do_work(); } UPD 03.12.2016: можно сделать это гораздо проще: //... template<typename T> bool execute_work(T &t) { static_assert(std::is_base_of<A, T>::value, "T must be subclass of A"); t.do_work(); }   int main() { B b; C c; execute_work(b); //OK execute_work(c); //compile error } И теперь у нас компилятор будет выдавать именно то сообщение, которое мы указали в static_assert

Передача определений прекомпиляции из cmake

Довольно частая задача, чтобы например подключать те или иные заголовки и делать это можно конечно только во время прекомпиляции.
Допустим есть такой CMakeLists.txt файл:

set(MYTARGET  "target")
# we have some string var that we want to convert to correct define for pre-compiler
set(INTERFACES_VERSION_STR  "-2016.10.23-" )

# remove all points (".")
string(REPLACE "."   ""   MY_INTERFACES_VER   ${INTERFACES_VERSION_STR})
# remove all "-" symbols
string(REPLACE "-"   ""   MY_INTERFACES_VER   ${MY_INTERFACES_VER})
# print them
message(STATUS "INTERFACES_VERSION_STR  ${INTERFACES_VERSION_STR}")
message(STATUS "MY_INTERFACES_VER   ${MY_INTERFACES_VER}")

add_library(${MYTARGET} my_source.cpp)

add_definitions(-DMY_INTERFACES_VER=${MY_INTERFACES_VER})

Тогда в исходном файле пишем:

//...

#if MY_INTERFACES_VER==20161023
#include "v20161023/include/interfaces.h"

    std::cout << "---- MY_INTERFACES_VER==20161023 ---" << std::endl;

#else
#include "mainline/include/interfaces.h"

    std::cout << "do some by default " << std::endl;

#endif

Far auto save option

Чтобы Far Manager открывал те же папки, которые были при закрытии, нужно просто поставить галочку напротив "Auto Save Setup" (F9 -> Options -> System Settings):