class Foo {
public:
  methodA() {
    printf("Wykonano...\n");
  }
}

struct data_t {
  int i_;
  Foo* obj_;
}

std::list<data_t*> data_;

for(std::list<data_t*>::iterator i  = data_.begin(); i != data_.end(); i++ ) {
   // operacje
}

W jaki sposób wykonać blok operacji ? Możliwości mamy kilka:

/* 1 */ i->obj_->methodA();
/* 2 */ *i->obj_->methodA();
/* 3 */ (*i)->obj_->methodA();

Rozwiązanie zagadki jest proste, ale wymaga znajomości priorytetów operatorów. Pierwsze wywołania jest całkowicie błędne, ponieważ lista przecowuje wskaźniki do strkutury, a nie samą strukturę. Zatem należy najpier wyłuskać strukturę znajdującą się pod wskazywanym adresem i dopiero wtedy wykonać metodę. Okazuje się że rowiązania 2 również jest nie poprawne, właśnie ze względu na priorytety operatorów. Dopiero numer 3 daje zamierzony efekt. Na szczęście błąd ujawnia się na etapie kompilacji…

// Copyright (C) 2001-2003
// William E. Kempf
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without fee,
// provided that the above copyright notice appear in all copies and
// that both that copyright notice and this permission notice appear
// in supporting documentation.  William E. Kempf makes no representations
// about the suitability of this software for any purpose.
// It is provided "as is" without express or implied warranty.

#include <boost/thread/thread.hpp>;
#include <;boost/thread/xtime.hpp>;
#include <iostream>;

struct thread_alarm
{
    thread_alarm(int secs) : m_secs(secs) { }
    void operator()()
    {
        boost::xtime xt;
        boost::xtime_get(&xt, boost::TIME_UTC);
        xt.sec += m_secs;

        boost::thread::sleep(xt);

        std::cout << "alarm sounded..." << std::endl;
    }

    int m_secs;
};

int main(int argc, char* argv[])
{
    int secs = 5;
    std::cout << "setting alarm for 5 seconds..." << std::endl;
    thread_alarm alarm(secs);
    boost::thread thrd(alarm);
    thrd.join();
}

Jednak ten sposób nie działa w przypadku korzystania z natywnego mechanizmu wielowątkowości dostępnego w każdym systemie *nix. Biblioteka pthreads nie radzi sobie z wywołaniem przeciążonego operatora (). Problem trzeba było rozwiązać jak najszybciej, żeby projekt mógł ruszy dalej. Dlatego powstał ten sprytny „work-around” umożliwiający uruchomienie dowolnej metody obiektu w nowym wątku. Jest to właściwie funkcja proxy, takie proste a ułatwia życie:

template<class T>
struct ThreadParams
{
	T *obj;
	void *params;
};

template<class T, void* (T::*method)(void*)>
void* run_thread(void *params)
{
	ThreadParams<T> *t = static_cast<ThreadParams><T*>(params);
	T* obj = static_cast<T*>(t->obj);
	(obj->*method)(t->params);
	return NULL;
}

Dodatkowy wkład pracy jaki należy włożyć aby wykorzystać powyższy kod ogranicza się właściwie tylko do wypełnienia struktury ThreadParams:

class Test
{
public:
	void* fun(void* params) {
	printf("Hello World! \n");
	printf("Params: %d\n", reinterpret_cast<int>(params));
	pthread_exit(NULL);
	}
 };

 int main() {

	pthread_t tid;
	void* status;
	Test test;
	ThreadParams<Test> params;

	params.obj = &test;
	params.params = reinterpret_cast<void>(123);

	pthread_create(&tid, NULL, run_thread<Test, &Test::fun>, (void*)(&params));
	pthread_join(tid, &status);
 }

Program('main.cpp')

Na Windows domyślnie zostanie wykorzystany (o ile dostępny) kompilator Microsoftu. Jeśli jednak chcemy użyć g++, wystarczy dopisać jeszcze jedną linię:

env = Environment(tools = ['mingw'], CC = 'gcc', CCFLAGS = '-O2')
env.Program('main.cpp')

Piewsze lody przełamane, kolejne próby będą sprawdzały łatwość dołączania zewnętrzych bibliotek jak boost czy qt.

Aby istniała możliwość ustawiania przezroczystości dla okna, musi być ono utworzone w sposób do tego przystosowany. Wystarczy skorzystać z innej funkcji tworzącej okno, nie CreateWindow, a CreateWindowEx

To co umożliwia później modyfikacje przezroczystości jest ukryte w ramach dodatkowego stylu okna, podawanego poprzez argument dwExStyle. Lista dopuszczalnych wartości jest długa, ale warto się z nią zapoznać. W tym konkretnym przypadku należy zainteresować się wartością WS_EX_LAYERED, utworzone wtedy okno będzie tzw. Layered Window, które obsługuje modyfikacje przezroczystości. Do ustawienia nowej wartości kanału alpha służy SetLayeredWindowAttributes(HWND hwnd, COLORREF crKey, BYTE bAlpha, DWROD dwFlags) – szczegóły w dokumentacji.
Pełny kod tworzący przykładowe, półprzezroczyste okno:

To co należy zrobić, aby kontrolować przezroczystość okien innych niż własne przedstawia się następująco:

1. 1. Pobrać wszystkie otwarte okna typu top-level
2. 2. Nadać oknom styl dwExStyle
3. 3. Zmienić wartość kanału alpha

1. Pobrać wszystkie otwarte okna typu top-level
Dobrym pomysłem wydaje się pobranie uchwytu do rodzica wszystkich okien(Desktop/Pulpit) i przejście w pętli po liście jego dzieci (jak wiadomo każde okno ma kilka przydatnych wskaźników, między innymi do okna-brata). Mogłoby to wyglądać tak:

Pomysł zły ! Okazuje się że taka pętla może działać w nieskończoność. Wzmianaka na temat takiego przypadku znajduje się nawet w dokumentacji. Dlatego należy wykorzystać inny sposób, polegający na użyciu funkcji BOOL EnumWindows(WNDENUMPROC lpEnumFunc, LPARAM lParam):

2. Nadać oknom styl dwExStyle
Wydaje się najtrudniejsze, przecież dodatkowy styl należy podać przy tworzeniu okna, a okna które widzimy zostały już przecież utworzone. Na szczęście z pomocą przychodzi funkcja LONG SetWindowLong(HWND hWnd, int iIndex, LONG dwNewLong):

3. Zmienić wartość kanału alpha
Bardziej uważni czytelnicy już na pewno wiedzą jak wygląda zestaw parametrów i jak skorzystać z SetLayeredWindowAttributes. Wykorzystanie pokazane 3 listingi wyżej, przy okazji tworzenia „własnego” przezroczystego okna.

I to tyle tym temacie, wypada jeszcze stworzyć GUI, może obsługę tray’a. Program wydaje się „magiczny” a korzysta raptem z 4 funkcji API systemowego.

Kompilator zrobi dokładnie to co chcesz. DOKŁADNIE!

i właśnie dlatego trzeba uważać. Ta zagadka jak i pozostałe ma na celu zwrócenie uwagi na miejsca które wydają się oczywiste a moga wprowadzić wiele zamieszania i niepotrzebnych nerwów. W końcu nie od dziś wiadomo że najgroźniejsze błędy znajdują się w „kodzie który napewno jest dobrze”. Tym razem zagadka wymaga trochę więcej od czytelnika, nie wystarczy znajmość C++, trzeba się jeszcze wykazać odrobiną znajomości biblioteki boost.
Na problem oczywiście musiałem trafić na klika godzin przed oddaniem projektu, była godzina 5:14 i nie trudno zgadnąć że odchodził istny eXtreme programming – programowanie gry sieciowej – 2 osoby – 24h. Dojście do tego co jest źle zajęło dobrą godzinę…
Poniższy kod przdstawia 4 najprostsze możliwe przypadki użycia boost::bind w połączeniu z boost::signal, nie różnią się między sobą bardzo:

#include <boost/signal.hpp>
#include <boost/bind.hpp>

#include <iostream>	

class Test
{
public:
  Test(int x) : x_(x)
  {}

  void metoda1(int i);

  int x_;
};

void Test::metoda1(int i)
{
  x_ += i;
}

int main()
{
  typedef boost::signal<void (int)> event_sig;
  event_sig signal;

  Test* t1 = new Test(0);
  Test* t2 = new Test(0);
  Test t3(0);
  Test t4(0);

  signal.connect(boost::bind(&Test::metoda1, *t1, _1));
  signal.connect(boost::bind(&Test::metoda1,  t2, _1));
  signal.connect(boost::bind(&Test::metoda1, &t3, _1));
  signal.connect(boost::bind(&Test::metoda1,  t4, _1));

  for(int i = 0; i < 10; ++i)
  {
    signal(1);
  }

  std::cout << "t1::x = " << t1->x_ << std::endl;
  std::cout << "t2::x = " << t2->x_ << std::endl;
  std::cout << "t3::x = " << t3.x_ << std::endl;
  std::cout << "t4::x = " << t4.x_ << std::endl;
  std::cout << "Powinno(?) byc 10" << std::endl;
}

Mogło by się wydawać że w wyniku, na ekran zostanie wypisana 4 razy liczba 10. Ci bardziej podejrzliwi zaczną się zastanawiać, jaki wpływ mogą mieć te „dodatkowe” symbole dostawione wewnątrz boost::bind. Okazuje się że w przypadkach 1 i 4 ( t1 i t4 ), mimo wysyłania sygnału, wartość pola x_ nie ulega zmianie, natomiast w pozostałych ulega. Dlaczego ?
Rozwiązanie tego problemu jest bardo proste, otóż tworząc binda, biblioteka boost w zależności od sposobu przekazania obiektu na rzecz którego zostanie wywołana metoda, utworzy jego kopię (internal copy) lub będzie operować na przekazanym obiekcie.
Niby proste, ale trzeba mieć świadomość o istnieniu takiego mechanizmu. Nie trudno się „przejechać” na złym przekazaniu obiektu, a tu nie będzie sugestywnego „segmentation fault”….

#include <iostream>

int main()
{
    for(double i = 0; i != 1; i+= 0.1)
    {
        std::cout << "Obrot petli i = " << i << std::endl;
    }
}

Odpowiedź na to pytania wymaga trochę więcej niż tylko znajomości składni języka. Na pierwszy rzut oka wydawać się może że pętla dokona 10 obrotów a następnie program się skończy. Gdyby to był 1 kwietnia wiele osób uznało by za żart stwierdzenie że pętla będzie działać w nieskończoność, choć tak naprawdę jest !! Program nie zauważy że dobił do 1 i powinien przestać działać. Co więcej, na ekran zostanie wypisana liczba 1 a mimo to działanie nie zostanie przerwane. Wyjaśnienia tego przypadku, trzeba szukać w komputerowej reprezentacji liczby 0.1

class A
{
public:
  A() {
    fun();
  }

  virtual void fun()  {
    std::cout << "A::fun" << std::endl;
  }

  void fun2()  {
    fun();
  }
};

class B : public A
{
  void fun()  {
    std::cout << "B::fun" << std::endl;
  }
};

int main() {
  A* a = new B();
}

Poprawna odpowiedź:
A::fun
dlaczego? W konstruktorze nie działa wirtualność. Zatem to ja miałem racje !
Za to gdyby dopisać jeszcze

a->fun2();

to byśmy zobaczyli już B::fun. Problem zapewne rzadko w praktyce występuje ale jest to genialne zadanie na wszelkiej maści testy mające sprawdzić zaawansowaną znajomość mechanizmów języka C++