ecyrbe a écrit 633 commentaires

J'en suis surpris aussi, étant le premier posteur! J'ai même pas d'aggrégateur sur le monde informatique... je suis tombé sur la nouvelle par hasard en cherchant une autre info.
Je me suis alors dit que ça devait déjà faire l'objet d'un journal sur linuxfr... n'en voyant pas, j'ai posté le mien.
Du coup, ça fait bizarre, on a l'impression que tout le monde était collé devant son PC, sur les starting-blocks à attendre la nouvelle!

plutôt parce que les femmes ne portent pas ce genre de manteau je dirais... sans vouloir trop présumer des goûts et couleurs évidemment :)

Si j'ai bon souvenir, la gestion des exceptions des compilateurs c++ est dépendante du système d'exploitation. Histoire de pouvoir catcher certains signaux par exemple. ce qui peut impacter les performances.
De même, l'allocation mémoire via l'opérateur "new", ce qui n'est pas rien, est dépendante du système d'exploitation.
Ces deux éléments là, à eux tous seuls, peuvent changer pas mal de choses d'un OS à un autre...

vous pouvez toujours regarder ceux là : http://bashfr.free.fr

Mais si y a des moyens super clean, un max portable et standard de faire ça...
utilise la librairie boost : http://www.boost.org/libs/filesystem/doc/index.htm

la librairie est proposé comme standard c++ pour la révision TR2.
la portabilité est plutôt grande, ça supporte normalement tous les systèmes connues à ce jour même ceux ou les répertoires sont identifiés par un path du genre : "mydir::myfile" ... et permet d'y accéder en utilisant la syntaxe POSIX en faisant "mydir/myfile" ou en utilisant la syntaxe native du système...

ce qui serait bien à mes yeux, c'est que le w3c standardise une api haut niveau exploitant XMLHttpRequest... une api à plusieurs niveaux allant jusqu'aux widgets et exploitant css pour la mise en forme...
ce serait vraiment cool, ainsi on verrait plusieurs implémentations de l'api, mais une seule manière de l'utiliser. ça éviterais de devoir réimplémenter la roue à chaque fois.
ça semble illusoire, ça se trouve c'est même pas le rôle du w3c et tu me rétorquera que y a des frameworks déjà existant et à disposition du développeur. Mais l'intérêt que j'y vois, c'est de faire en sorte que les dévellopeurs de navigateurs puissent faire une seule série d'unit-test pour valider que la fonctionnalité et ainsi être certain que ça fonctionnera sur un maximum de navigateurs...
Bref la standardisation, à mes yeux a toujours du bon, et ça n'empêche personne de ne pas l'utiliser, mais guaranti à ceux qui le veulent que ça fonctionnera bien.

Hey, du calme... tu m'as mal compris, je t'ai mal compris aussi...
Moi je disais que l'ajax (même si c'est basé sur des technos standardisées), c'est pas standardisé... et là j'ai l'impression que tu me rétorque que c'est basé sur des technos standardisées... c'est pas la même chose à mes yeux.
Le format docx utilise xml (qui est standardisé), c'est pas pour autant que docx l'est aussi (à l'ecma, d'accord, mais c'est un exemple)...

ah bon, HTTP c'est le foutoir? sais tu au moins de quoi tu parle?
HTTP c'est un standard de l'ietf, y a rien de foutoir dedans.
Je soupçonne que tu n'ais lu que le mot "ajax" et "champion" dans ma phrase et tu n'a pas pu t'empêcher de bondir...

c'est ce qu'on appelle du lobbying...

Si le logiciel est libre, je vois pas comment on peut qualifier ça de protocole propriétaire, même si c'est la seule application à l'utiliser. Jabber a bien commencé comme ça, non? avant que d'autres ne l'utilise et que son protocole ne devienne une RFC...

Ce qui est plus grave, c'est d'avoir un protocole fermé dans des application réseaux...qu'elles soient web ou autres. ça limite leur interropérabilité...et aujourd'hui c'est vrai que le champion en la matière, c'est ce web 2.0 dont la couche haut niveau (ajax) est un vrai foutoir et aucun standard...

je comprend mieux ce qu'il cherche là.
Bon, c'est simple. Les drivers de ta caméra sont des drivers firewire.
Il y a un utilitaire qui est fournit qui permet effectivement de créer un device v4l via vloopback. il s'agit de :
dc1394_vloopback
regarde la doc pour comprendre comment l'utiliser.
mais voici un exemple :
dc1394_vloopback --vloopback=/dev/video0 --width=320 --height=240

celà va rediriger les flux de ta caméra vers le device /dev/video0.
n'oublie pas de charger le module vloopback, par exemple avec un :
modprobe vloopback pipes=1

ensuite tu pourra utliser ta caméra dans n'importe qu'elle application qui supporte v4l.

-es-tu sûr que les processus sont vraiment inutiles? ça m'étonnerai qu'un programme lance des processus pour le plaisir d'en lançer...

-s'il lance des programmes dont tu n'a vraiment pas besoin, peut être devrais tu te plonger dans la documentation de ton application pour voir comment désactiver les programmes en question.

je ne sais pas ce que tu cherche exactement, si tu souhaite programmer un emmeteur ou un recepteur pour vloopback va sur le site :
http://www.lavrsen.dk/twiki/bin/view/Motion/VideoFourLinuxLo(...)

si tu souhaite simplement dédoubler une source pour que plusieurs programmes puissent voir la même source voici la commande :
resize /dev/<deviceSource> /dev/<deviceDestination> x x

tu pourra alors dire a plusieurs programme de lire <deviceDestination> en même temps.

avec rsync tu peux faire des copies avec progress bar grace à l'option : --progress

Et kde aussi.
Le problème venait du fait que Scons manquait de certains outils de reconfiguration et de parfois de portabilité (sous osX)... et la réactivité des mainteneurs n'était pas à la hauteurs des espérances de dev de kde qui ont donc migré vers CMake.
Depuis Scons à fait du chemin, et pas mal de vides ont été comblés. L'un comme l'autre sont je crois très complets... je peux pas dire, je reste sur les autotools:p

on avance, j'ai l'impression que à mal lu mon premier commentaire, qu'est-ce que t'obtiens dans le cas :
struct iphdr *iph2;
iph2 = & g_array_index(P_to_Array, struct iphdr, i);

je pense que c'est ce cas là qui devrait marcher... et je vais t'expliquer pourquoi...

g_array_index est défini par :
#define g_array_index(a,t,i) (((t*) (a)->data) [(i)])

remarque ce qu'il fait... il cast a->data en t* !!!!

Or, toi tu lui dis de faire un cast en struct iphdr **, ce qui est faux je pense. Si j'ai raison, ça ne devrait marcher que pour le premier index, pour les autres ça devrait induire un décalage des données.
Or chez toi tu obtiens le bon résultat pour le premier index, pas pour les autres. Ce qui semble comfirmer mon hypothèse.
Essaie donc et dis moi si ça corrige quelquechose...

Dans quel cas, les deux? tu mets quoi dans ton GArray?
Peux tu donner plus d'infos sur la structure de ta variable m?

regarde bien, ton utilisation de g_array_index est fausse...

si c'est un tableau de iphdr tu dois faire ça :

struct iphdr *iph2;
iph2 = & g_array_index(P_to_Array, struct iphdr, i);

si c'est un tableau de iphdr* tu dois faire ça :

struct iphdr *iph2;
iph2 = g_array_index(P_to_Array, struct iphdr*, i);

voilà...

en plus de la solution utilisant les pipes, je te propose de jeter un oeil à la bibliothèque ncurses, qui te permettra de facilement faire la transition si jamais tu veux faire un programme en gtk plus tard...
cf :man ncurses

Ton problème revient à faire communiquer deux programmes executés dans deux consoles differentes.
Pour celà, l'outil classique ce sont les Pipes nommés, ça permet de faire communiquer simplement deux programmes, voir plus...
cf: man 3 mkfifo

voilà... amuse toi bien!

gni? comment ça, non?

Tu fais appel à quoi? si tu fait appel à g_tree_remove, ça fait aussi appel tout seul aux fonctions de desallocation mémoire si tu utilise g_tree_new_full() pour créer ton arbre.
d'ailleurs c'est explicitement écrit dans la doc des g_tree...

donc, qu'est-ce qui est faux dans ce que j'ai dit?

non, comme je l'ais dit, tu peux faire appel à g_tree_new_full(),
cette fonction te crée un b-tree vide, tu lui donne en paramètre les fonctions chargées de désallouer la mémoire pour toi.
pour désallouer la mémoire d'une chaine de caractère, tu fait appel à g_free(memoire_a_desallouer). donc pour qu'il te désalloue la mémoire allouée pour des chaines de caractère pour la clé et les données, tu fais :

g_tree_new_full(strcmp,NULL,g_free,g_free);

quand tu fera appel à g_tree_destroy(), pour chaque noeuds il videra la mémoire pour toi.

Pas con le coup du g_strdup_printf, c'est plus conci que le malloc que j'ai proposé...

Pour la désallocation, dans mon exemple, je lui dit d'utiliser g_tree_new_all qui permet de spécifier le destructeur pour la clé et le contenu, du coup c'est automatique, il n'aura pas besoin de désallouer à la mano.
par contre faudra remplacer free par g_free ...

Sache que t'es pas obligé de mettre des chaines de caractère dans un gtree,
cependant voici un exemple pour que ton application fonctionne :

#include <glib.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

GTree * redirected_connections;

int main(int argc, char **argv)
{
redirected_connections = g_tree_new_full((GCompareDataFunc)strcmp,NULL,(GDestroyNotify)free,(GDestroyNotify)free);

int i;
for (i=1; i < 250; i++)
{
int value = (i * i);

gchar* intkey = (gchar*)malloc(sizeof(gchar)*4);
snprintf(intkey,4, "%d", i);

gchar* intval = (gchar*)malloc(sizeof(gchar)*6);
snprintf(intval,6, "%d", value);

fprintf(stdout, "add %s:%s\n",intkey, intval );
g_tree_insert(redirected_connections, intkey, intval);
}

for (i=1;i<250;i++)
{
gchar intkey[4];
snprintf(intkey,4, "%d", i);

fprintf(stdout, "check value %s:%s\n", intkey, g_tree_lookup(redirected_connections, intkey));
}

gint numberofnodes = g_tree_nnodes(redirected_connections);

fprintf(stdout, "# of nodes : %d\n",numberofnodes);

g_tree_destroy (redirected_connections);
}

Évidemment, c'est du bon sens, si la complexité du système à décrire s'emballe je ne ferais pas ça. Tu as raison. Je dirais même que c'est totalement pourri, je te l'accorde.
Si le système est complexe, faut penser qu'il faudra le maintenir, et les liaisons redondantes, tu me l'accordera peut être, c'est pas non non plus la joie à maintenir si les proprio des voitures changent à tout va...
Je proposerais donc ça à la place:

Voiture
-> modèle
-> assurance
-> carte grise
-> contrat d'entretien
-> etc

mais pas de liens vers le Propriétaire

Propriétaire :
-> nom
-> Voiture
-> etc

Système (singleton)
-> proprietaires
-> voitures
- methode : rechercher_proprietaire_de_voiture()

Bref, pas besoin de redondance. beaucoup plus propre que ce que j'ai proposé plus haut.