QList<QMdiSubWindow > subWindows = ui->mdiArea->subWindowList();
QMdiSubWindow mySubWindow = subWindows.at(0);
mySubWindow->setWindowIcon(QIcon());


En C++, une classe est automatiquement amie d'elle même. Ce qui explique l'on puisse appeler un objet privée de la classe dans le constructeur de copie. Ahhhhh !!! Je comprends mieux.

Exemple :

class MyClass {
public:
MyCLass() : myVar(0) {}
MyClass(const MyClass& parent) {
myVar = parent.myVar; // will work and is possible
// myVar = parent.myVar(); // won't work like this. myVar() has to be "int myVar() const;"
}

private:
int myVar_;
};


J'ai installé la béta 1 de SnippetVamp : http://www.warriordudimanche.net/article157/snippetvamp-beta-1-0 A voir comment je m'en sers.
En tout cas, chapeau WarriorDuDimanche ! Léger, facile à prendre en main, yeah !

Trier une liste d'objet en Java est relativement facile :
[code]
Collections.sort(myList, new MyComparator());
[/code]

Où MyComparator implémente l'interface Comparator. Je n'ai pas trouvé de classe abstraite pour cela, donc pas de sucre syntaxique particulier ici.
Un Comparator implémente la méthode compare(o1, o2) qui doit retourner :

• 0 si o1 = o2
• -1 si o1 < o2
• 1 si o1 > o2

Par exemple :
[code]
public class MyComparator implements Comparator {
@Override
public int compare(MyObject o1, MyObject o2) {
if (o1.getInt() == o2.getInt()) {
return 0;
}
if (o1.getInt() < o2.getInt()) {
return -1;
}
return 1;
}
[/code]

Les tests unitaires en Java, c'est le pied grâce à JUnit ! C'est vraiment le pied ! Dans un projet, j'ai même eu l'occasion de m'en servir pour des tests d'intégrations !
Cela devient plus compliqué dès qu'il faut tester des méthodes asynchrones utilisant des callback (ou listener, as your prefer). Je n'ai rien de complètement figé dans ma tête actuellement, mais voilà ce que je note :

• Le framework Awaitility (http://code.google.com/p/awaitility/) permettrait de faire ça proprement, mais ça ne m'a pas tenté.
• Certains disent qu'il faut mocker et faire en deux étapes... Mouais, à mon avis ce n'est pas adaptable dans tous les cas. Pour un test d'intégration système par exemple, il vaut mieux éviter de mocker.

• La solution générique consiste à attendre l'appel du thread à l'aide de synchronized, wait et notify. Dans la réalité, il semble qu'il vaut mieux utiliser CountDownLatch (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CountDownLatch.html) afin d'éviter que le callback n'arrive avant que l'on est eu le temps d'attendre... ce serait dommage ;-)
  Actuellement, pour moi, la meilleure solution consiste donc à utiliser un code du type :
  
public class AsynchronousTest
{
/**

  • Asynchronous helper
    */
    private CountDownLatch lock = new CountDownLatch(1);
    /**
  • Received data from the asynchronous call
    */
    private Object receiveddata;

  @Test
  public void testAsynchronousCall() throws Exception
  {
  Object parameters = null;
  myAsynchronousCall(parameters, new MyCallback()
  {
  @Override
  public void onSuccess(Object data)
  {
  receiveddata = data;
  lock.countDown();
  }
  });

  boolean releaseBeforeTimeout = lock.await(2000, TimeUnit.MILLISECONDS);
  // Check timeout
  if (!releaseBeforeTimeout) {
          // Do stuff
          fail("Timeout");
  }
  
  assertNotNull(receiveddata);
  // Other tests

  }
}