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);
 }

Na wszelki, skopiowany kod poprawki poniżej:

— ZSI-2.1-a1/ZSI/ServiceContainer.py 2007-08-08 00:56:37.000000000 +0200
+++ ServiceContainer.py 2008-06-19 13:50:11.000000000 +0200
@@ -5,6 +5,7 @@

import urlparse, types, os, sys, cStringIO as StringIO, thread,re
from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
+from SocketServer import ThreadingMixIn
from ZSI import ParseException, FaultFromException,
FaultFromZSIException, Fault
from ZSI import _copyright, _seqtypes, _get_element_nsuri_name, resolvers
from ZSI import _get_idstr
@@ -30,6 +31,7 @@
SimpleWSResource
SOAPRequestHandler
ServiceContainer
+ ThreadedServiceContainer
„”"
class NoSuchService(Exception): pass
class UnknownRequestException(Exception): pass
@@ -141,12 +143,16 @@
return SendFault(FaultFromException(e, 0, sys.exc_info()[2]), **kw)

-def AsServer(port=80, services=()):
+def AsServer(port=80, services=(), threaded=False):
”’port –
services — list of service instances
+ threaded — in modo multithread ?
”’
address = (”, port)
- sc = ServiceContainer(address, services)
+ if threaded:
+ sc = ThreadedServiceContainer(address, services)
+ else:
+ sc = ServiceContainer(address, services)
sc.serve_forever()

@@ -467,6 +473,11 @@
def removeNode(self, url):
self._nodes.removeNode(url)

+class ThreadedServiceContainer(ThreadingMixIn, ServiceContainer):
+ ”’Multithreaded version of ServiceContainer.
+ ”’
+ pass
+

class SimpleWSResource(ServiceSOAPBinding):

# gry - lista skladajaca sie z list reprezentujacych gre. Kazda reprezentacja
# gry to kolejna lista zaiwerajaca ilosc 'kijkow' na kolejnych stosach
def graj(gry):
    sg = (0, 0, 1, 1, 2, 2, 3)
    for gra in gry:
        g = []
        reszty = []
        for stos in gra:
            reszta = int(stos)%7
            g.append(sg[reszta])
            reszty.append(reszta)
        wynik = reduce(lambda x,y: x^y, g)

        if wynik :
            print "Julia wins."
        else :
            print "Robert wins.\n"

Lekki problem pojawia się przy ustalaniu ruchu wygrywającego. Nie wiem czy istnieje jakieś szybsze rozwiązanie niż takie trochę brute-force’owe która ja wykorzystałem. Polega ono na stwierdzeniu na jakiej pozycji ( wygrywającej czy przegrywającej ) znalazł by się gracz gdyby nie było jednego stosiku, a następnie obliczeniu czy da się odjąć taką liczbę patyczków żeby zostawić przeciwnika na pozycji przegrywającej.
Dodatkowo oprócz wskazania ruchu wygrywającego należy wskazać ten podczas którego bierze się najwięcej patyczków ze stosu o najmniejszym numerze, co w lekki sposób komplikuje sprawę.:

        stos_wygrywajacy = 0;
        licznik = 0
        blokada_5 = False
        blokada_3 = False

        # odwrocenie list, sprawdzanie od konca
        gra_rev = gra[:]
        gra_rev.reverse()

        g_rev = g[:]
        g_rev.reverse()

        reszty.reverse()
        for reszta in reszty:
            # lista reszt bez kolejnych stosow
            tmpr = reszty[:]
            tmpr.pop(licznik)

            # xor wartosci f. Sprague-Grundy'ego
            # bez kolejnych stosow
            tmpg = g_rev[:]
            tmpg.pop(licznik)
            tmpw = reduce(lambda x,y: x^y, tmpg ,0)

            if sg[reszta-5] == tmpw and int(gra_rev[licznik]) >= 5:
                wygrywajacy = 5
                stos_wygrywajacy = len(reszty) - licznik
                blokada_5 = True
            elif sg[reszta-3] == tmpw and int(gra_rev[licznik]) >= 3 and blokada_5 == False:
                wygrywajacy = 3
                stos_wygrywajacy = len(reszty) - licznik
                blokada_3 = True
            elif sg[reszta-2] == tmpw and int(gra_rev[licznik]) >= 2 and blokada_5 == False and blokada_3 == False:
                wygrywajacy = 2
                stos_wygrywajacy = len(reszty) - licznik

            licznik += 1

Jeśli ktoś zna szybsze rozwiązanie chętnie je przeanalizuję
Zaznaczam, że nie dam sobie głowy uciąć że algorytm jest poprawny, bo nie ma już możliwości zgłoszenia rozwiązania – upłynęły terminy.

EDIT:
Lekko poprawiona wersja, działa trochę szybciej, natomiast i tak nie umożliwia zdobycia maximum punktów. Jesli nie ma jakiejś sztuczki na ruch wygrywający, a podejrzewam że coś jest, to lepiej zakodzić to w C…

        stos_wygrywajacy = 0
        blokada_3 = False
        blokada_2 = False
        licznik = 0
        for reszta in reszty :
            tmpg = g[:]
            tmpg.pop(licznik)
            tmpw = reduce(lambda x,y: x^y, tmpg, 0)

            if sg[reszta-5] == tmpw and int(gra[licznik]) >= 5:
                wygrywajacy = 5
                stos_wygrywajacy = licznik + 1
                break
            elif sg[reszta-3] == tmpw and int(gra[licznik]) >= 3 and blokada_3 == False:
                wygrywajacy = 3
                stos_wygrywajacy = licznik + 1
                blokada_3 = True
            elif sg[reszta-2] == tmpw and int(gra[licznik]) >= 2 and blokada_3 == False and blokada_2 == False:
                wygrywajacy = 2
                stos_wygrywajacy = licznik + 1
                blokada_2 = True
            licznik += 1

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++