Anthony Jaguenaud a écrit 1967 commentaires

Un accident climatique n’est pas une preuve, une augmentation de leurs fréquences donne quand même une tendance…

En stat, il y a des points aberrants, mais quand de nombreux points aberrants se regroupe, ce n’est plus des points aberrant.

Après, le vent soutenus, il y a les rafales…

Il y a quelques années j’étais au ski lors d’une tempête qui a ravagé la station de ski. Dans certains appartement les vitres ont explosé malgré les volets fermés. Car la rafale pousse le volet vers la fenêtre et compresse l’air entre les deux. Sur de très fortes accélération, certains carreaux n’ont pas tenu.
Par contre, je ne serai pas resté près de la fenêtre.

Je ne sais pas si c’est le manque de ponctuation ou quoi, mais je n’ai rien compris à ton message. Je pensais que d’autre répondrait, mais personne en 36h, c’est que je ne dois pas être le seul dans l’incompréhension.

Merci, je regarderai.

Permet moi, je te prie, d’être d’accord avec Zenitram.

Ton discours sur le HW est bien et éthique. Hélas à la fin tu le replaces dans un cadre politique de désobéissance aux lois de mon pays et ça, ça me gène.

La ZAD et les ZADiste sont, dans mon esprit, des anarchistes qui s’opposent violemment aux forces de l’ordre avec des caméras pour ensuite inonder les réseaux sociaux de vidéo d’abus des forces de l’ordre sans montrer les actions ayant déclenchées la réaction des forces de l’ordre. En gros vous faites aussi bien que les politiques corrompus contre qui vous croyez vous battre…

Oui, le open hardware est important, oui les libristes existent dans des centaines de courant différents. Mais mélanger les discours libre et anarchiste… je ne suis pas sûr que sa fasse avancer le débat.

Alors, mon schéma n’était pas assez clair. C’est un tableau à double entrée : en colonne tu as les dépôts des différents dév. et en ligne 0 les dépôts publics en ligne 1 (en bas) les dépôts privé (généralement ton espace de travail).

Le dév moyen est un développeur occasionnel sur le projet…

Maintenant que j’ai compris ce que veut dire PR/MR, je ne vois pas le problème.

Git a été pensé pour que chacun est un dépôt privé et un dépôt public. La façon dont Linus ou autre l’a pensé au départ pour le kernel était ce schéma :

 Dépôt officiel       Dépot public
       ^      \       (dev. occ.)
       |       \      /    ^
       |        \    /     |
       |         \  /      |
       |          \/       |
       |          /\       |
       |         /  \      |
       |        /    \     |
       |       /      \    |
       V      V       V    V
   Intégrateur       Dév. moyen
(droit d’écriture)

dev.occ. = développeur occasionnel.

Le développeur occasionnel récupère le dépôt et fait ses corrections. Ensuite il pousse sur son dépôt public puis doit effectivement prévenir quelqu’un qu’il a fait le taf. (par mail, bugtracker…) l’intégrateur va récupérer les modifs. Si elles n’ont pas le niveau attendu, elles n’iront jamais sur le dépôt officiel. Si c’est bon, c’est l’intégrateur qui pousse sur le dépôt officiel.

Cas des forges (attention, si je commets des erreurs, merci de me corriger)

 Dépôt officiel <---->Dépot public
       ^              (dev. occ.)
       |                   ^
       |                   |
       |                   |
       |                   |
       |                   |
       |                   |
       |                   |
       |                   |
       V                   V
   Intégrateur       Dév. moyen
(droit d’écriture)

Du coup, l’intégrateur doit accepter la modification sur son dépôt public avant de pouvoir l’accepter ?

En tout cas, les échanges de dépôts ne suivent pas la logique initialement pensée.

Dites moi si j’ai bien suivi.

Donc il suffit de copier/coller le dossier?

Oui, mais attention aux droits d’accès. Le répertoire .ssh doit être en lecture/écriture/exécution seulement pour l’utilisateur. Sinon ssh refuse de s’en servir.
Après la copie, il est probable que tu ais des droits différents (fonction de ton umask)

Je pense que Georges Perec à essayer de la faire disparaitre de son clavier ;-)

Bon Ok, le roman à été écrit en 1968, donc peut-être à la machine à écrire.

Sur mon clavier, j’ai une maison, pas une fenêtre.

Et pourquoi pas utiliser la commande sftp ?

man sftp te dis qu’il y a l’option -b batch file. Donc la possibilité de scripter les transferts.

Salut,
Effectivement, linuxfr ne permet pas de recevoir des courriels en réponse aux messages postés. Néanmoins, j’entrevois une possibilité… mais je ne sais pas si c’est simple à mettre en place.

Tu peux utiliser weboob, dans les applications tu trouves QBoobMsg qui permet de suivre divers forums dans une seule application. Il y a aussi Monboob qui permet de récupérer les messages sur des forums et les envoyer par courriel.

Personnellement, je m’étais fait avoir sur un destructeur qui appelait une fonction virtuelle pure… ça lance une belle exception ;-).

Oui oui, c'est logique, je l'ai réalisé dès que j'ai repéré un bug lié à ce problème. Le principe de ma hiérarchie de classe est d'utiliser des méthodes génériques de la classe de base, et tout fonctionnait très bien jusqu'à ce que j'essaye de le faire aussi dans le constructeur.

Si tu as ce besoin dans le constructeur, c’est que ta hiérarchie est mal répartie. Ce n’est pas un problème de C++, tu aurais le même type d’ennuis dans tous les langages objets que je connais.

Pour chaque classe tu dois savoir quelles sont ses responsabilités. Avoir les données minimales pour gérer ces responsabilités.

Si je reprends ton exemple de Polygone, il est logique que le polygone possède la liste des points. C’est même à lui de retourner le nb de points mais en regardant le nombre d’éléments dans la liste.

int Polygone::get_nb_points() { return v.size(); }

Par contre positionner les points c’est à la classe fille de le faire… via une nouvelle fonction de Polygone : addPoint.

Ensuite, je ferais une classe spécifique comme ça :

template <int n> class PolygoneRegulier: public Polygone 
{
    PolygoneRegulier():Polygone() {
       // Ici Polygone est construit, donc on peut utiliser ses méthodes.
       for (int i = 0; i < n; i++) {
           Point p = Point(cos(i*360/n), sin(i*360/n));
           addPoint(p);
       }
    }
}

typedef PolygoneRegulier<3> Triangle;
typedef PolygoneRegulier<4> Carre;

J’ai tapé ça vite fait… je ne sais même pas si ça compile ;-) mais l’idée est là.

Pour être honnête, j'ai même pensé à passer this en paramètre du constructeur de la classe de base, mais j'ai rapidement décidé que je ne voulais même pas savoir si c'était légal.

Ce n’est pas nécessaire, le this est le même dans toute la hiérarchie. Juste qu’une méthode parente n’a pas à appeler une méthode d’une fille, car sinon comment choisir ? Ex :

class Mere
{
public:
    Mere() { Fille::methode(); }
};

class Fille:public Mere {
    …
    void methode();
};

class Fille2: public Mere {
    …
    void methode();
};

Fille2 var;
};

Comment peut-on construire var puisque var sera une Fille2 ainsi qu’une Mere. Mais pas une Fille ! Donc si ça compilait se serait catastrophique.

Pour la suite je ne suis pas certains d’avoir tous saisi.

Je suis quand même un peu surpris que le C++ n'ait pas un mécanisme simple pour s'assurer qu'une fonction est exécutée exactement une fois lors de la construction, sans pour autant contraindre la hiérarchie de classes (typiquement, pour réserver de la mémoire).

Je l’ai expliqué au dessus. Après tu peux faire une construction via une factory.

Dès que les classes filles appellent le constructeur des classes mères, on se retrouve à devoir choisir où réserver la mémoire ;

Je ne comprends pas.

soit dans le constructeur de la classe mère (et donc, de devoir se débrouiller pour passer des variables membres en paramètre du constructeur, ce qui est quand même étrange), soit dans le constructeur de la classe fille (ce qui rend presque mécaniquement la classe mère virtuelle).

Ton problème vient du fait que tu dois penser en terme de responsabilité :

• Mon objet c’est quoi ?
• Quel information caractérise se quoi.
• Quel comportement je lui donne.

Si a l’une de ses questions tu dois avoir des méthodes dans des classes qui hériteront c’est qu’il y a un soucis.

Disons que je comprends le pourquoi du comment techniquement, mais que ça me semble être un mécanisme légitime en POO…

Je pense que tu découvre la POO et que tu as trouvé génial l’héritage et les fonctions virtuelles, mais il faut bien comprendre se qu’elles permettent et pas leur donner des pouvoirs qu’elles n’ont pas.

L’exemple classique s’est la figure géométrique que l’on veut déplacer. Il suffit d’appeler la fonction dessiner dans la fonction deplacer. En rendant dessiner virtuelle, ça permet d’avoir une seule implémentation de deplacer.

Je te conseillerai un livre très bien écrit : Programmer en langage c++ de Claude Delannoy. J’ai une très vieille version 4° édition 1998… il manque le c++03, c++11… néanmoins, la présentation du livre est très didactique et une fois assimilé les concepts de base, les informations glanées sur internet n’ont plus à être aussi didactique.

Finalement, j’ai fais un paver ! J’espère que ce n’est pas trop indigeste.

Je comprends un peu mieux ce que tu veux faire… Ce n’est pas possible, car quand tu es dans le constructeur de polygone, le vtable (pointeur vers la table des fonctions virtuelles) est initialisé pour Polygone. Ce n’est qu’à la fin du constructeur de Polygone où le runtime modifie la vtable puis appelle le constructeur de Triangle.

Dans ce cas simple, la solution est de descendre l’information nb_de_point en paramètre au constructeur de Polygone.

class Triangle: public Polygon {
  public:
    Triangle(): Polygon(3) { } 
    int get_nb_points() const { return 3; } // pourrait être plus compliqué, lire dans un fichier, etc. 
};

Mais sinon, une méthode statique de construction de l’objet peut-être intéressante.

Pour comprendre l’ordre d’exécution, la vtable… tu peux ajouter des traces (un bête std::cout) et dump(this,sizeof(*this)) dans chaque constructeur. Ça devrait te donner une idée.

Dans un cas simple (sans héritage multiple ni virtuel), les constructeurs sont appelés dans l’ordre.

Dans le cas Derived2 :
D’abord Base::Base() qui s’il appelle init ne peut appeler que Base::init (il ne peut avoir connaissance des autres, et la table des méthodes virtuel pointe pour l’instant sur sa fonction.
Ensuite Derived::Derived() qui s’il appelle init peut appeler soit la sienne Derived::init() soit celle de Base::init().
Ainsi de suite.

Si ton but est que chaque niveau de la hiérarchie appelle sa fonction d’init il n’y a pas de problème.

Une solution a ton problème pourrait-être d’utiliser une classe de callback sur destructeur.

class CallBack {
public:
  CallBack(fct):my_fct(fct) {}
  ~CallBack() {my_fct(/* ancien this ? */);}

  modify(fct) { my_fct = fct; }
private:
  my_fct;
};

Je n’ai pas défini le type de fct. On doit pouvoir utiliser std::bind pour inclure le this dans l’appel.

Ensuite, tu crées ton constructeur un peu comme ça :

Base::Base (param, callBack(fct)) { callBack.modify(my_init); }

Le dernier appelé sera celui de plus haut niveau (le dernier exécuté). L’objet temporaire créé pour le passage de paramètre sera détruit à la sortie du constructeur et donc, hors optimisation, le destructeur de l’objet callback devrait être appelé. (je n’ai pas le temps de tester mon idée…).

Je ne sais pas si ça résous ton problème, mais je rejoins le commentaire au dessus pour dire que ça semble être un soucis d’analyse du problème.

Par contre, la fonction que tu utilises ne peut être que statique. Ou alors, tu dois enregistrer un pointeur vers ton objet et dans ce cas faire : obj.fct()

Oui, c'est pour ça que j'ai proposé scp qui fonctionne aussi au dessus de ssh. Mais ça doit être du ftps, et du coup l'URL lftp devrait être : lftp ftps://user:mdp@...

La commande lftp est-elle bien lancée avec le même uid que filezilla ?

Pour moi, lftp arrive a créer le fichier, donc écrire dans le répertoire distant. Par contre il n’arrive pas à écrire le contenu. Deux solutions :

• Il n’arrive pas à écrire…
  • Vérifier l’umask distant, se serait bête de créer un fichier dans lequel on ne peut écrire ;-)
• Il n’arrive pas à lire le fichier source.
  • Vérifier uid:gid et droit du fichier local.

Essaye avec un autre programme : scp

$ scp /home/mesfichiers/fichier.txt user@site.fr:/Share
…

Tu verras si ça passe. Par contre si tu ne fais pas d’authentification par clé, il faudra taper le mdp. Je ne sais pas si tu peux écrire :
scp /home/mesfichiers/fichier.txt user:password@site.fr:/Share

Changer la pile, si, finalement la machine part à la poubelle, ça ne vaut pas le coût écologique. Après, si la machine convient, alors là, oui il faudra changer la pile.

Penses à passer le sujet à [Résolu].

Au minimum, au boot du PC, tu le mets à l’heure dans le BIOS. Tant que tu ne l’éteins pas, il l’a conserve.

Je ne suis pas sûr que ça marche mieux, mais tu peux essayer.

Je me réponds, Cmake est sensible à l’ordre des instructions…

il faut mettre le find_package en premier se qui définie tout le reste.

Voici la version qui fonctionne :

cmake_minimum_required(VERSION 2.8.3)
project(test)
find_package(Qt5Test REQUIRED) # À mettre au début


# Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Instruct CMake to run moc automatically when needed.
set(CMAKE_AUTOMOC ON)

add_executable(test src/MainTest.cpp)


QT5_USE_MODULES(test Test)

Il faut ajouter : QT5_USE_MODULES(test Test) le premier étant le project et le second la bibliothèque Qt associé sans le Qt.

Par contre, maintenant, il ne me génère pas le moc… je regarde.

Le # est une erreur de copier/coller concaténation… en fait, j’avais :

/usr/include# ls x86_…/

Quand j’ai concaténé, j’ai gardé le #…

Je vais me répondre, j’ai trouvé une partie.

Je m'en souviens très bien, l'échange était pour les entreprises, le patch pour les particuliers.

Je m’en souviens vaguement… c’était en 1994, ça ne nous rajeunis pas ! J’étais à la FAC et je lisais les magasines d’informatique de l’époque. Hélas, j’ai fini par les jeter dans mes multiples déménagement. J’aurais bien relu des articles de l’époque pour me remémorer tout ça.

Lorsqu'il y a eu le bogue de la division des Intel Pentium, Intel à seulement fourni un patch qui désactivait le co-processeur mathématique dans certaines conditions…

Bah, il me semblait que intel avait proposé un échange de processeur. Mais peu de gens l’aurait demandé.