Michaël a écrit 2935 commentaires

"le C++ est trop difficile à apprendre", ça se discute.

Vu que moins d'un programmeur sur dix est capable d'écrire proprement un opérateur d'affectation entre deux objets (transac-quoi?) on peut dire qu'au moins neuf personnes sur dix qui essaient d'apprendre C++ n'y arrivent pas. Pour moi c'est tout vu, le C++ est trop difficile à apprendre.

Le pire c'est que, si on ne veut pas se frotter au problème il faut quand-même prendre une mesure active et déclarer private l'opérateur d'égalité — et ne surtout pas l'implémenter!

Et ta fonction mafonction n'est jamais appelée avec un pointeur nul déréférencé en argument. Un exemple du genre

MaStructure* macopie = monargument->clone();
mafonction(*macopie);

est bien-sûr complètement artificiel et n'arrive jamais dans du vrai code.

Sauf que là tu as dû jouer avec un… pointeur, qui permet en effet de bidouiller en C++, comme en C vu que tu manipules directement l'adresse.

Désolé mais les pointeurs font partie du langage C++ ce qui veut en particulier dire qu'il existe des fonctions qui renvoient des pointeurs. (Pour la bonne raison que les références n'ont pas de sémantique de propriété mais seulement d'alias.) Donc qu'on passe des arguments de type référence avec comme valeur des pointeurs déréferencés — qui peuvent bien-sûr être nul.

La vraie différence entre une référence et un pointeur est qu'une référence ne peut pas être deleted.

Sur le fond je suis complètement d'accord avec toi, seulement, je ne présente pas du tout l'héritage, donc en particulier pas de façon biaisée, et au contraire de toi

(Est-ce que l'héritage est la bonne façon de voir les choses ?).

j'ai répondu à EmilienR en essayant de lui apportant les informations qu'il demandait:

Je souhaite aujourd'hui me lancer dans un projet où je devrai gérer de l'héritage. J’aimerais avoir ton avis sur le langage à utiliser :
[ C, C++, C avec table de méthodes à la mano]

Mais dans un autre cadre j'aurais pu écrire la même chose que toi.

et tu es sûr qu'il n'est pas NULL.

Tu veux dire comme dans

int &ma_ref = *mon_int_ptr;

c'est ça?

on a donc : m_a(a); qui corresponds a m_a=a;

Comme je l'ai écrit, c'est la syntaxe d'initialisation de type constructeur. Ceci a deux inconvénients car:

• les entiers ne sont pas des objets donc la notation pousse à confusion;

• les initialisations par = n'ont pas été abandonnées.

Cela contribue au fait que C++ est un langage tout pourri™.

donc ca ne fait pas excatement 213,

Il y en a plus que deux ce qui fait déjà largement plus que dans la plupart des langages.

mais une fois qu'on a compris ca va mieux

C'est quoi que je n'ai pas compris d'après toi?

Il est clair que si l'allocation d'un objet de quelques octets échoue, c'est que ta machine est à la ramasse partout car elle n'a de mémoire nulle part et doit swapper à mort depuis un moment. Que l'application crash à ce moment (sans destruction de données bien entendu) est un traitement d'erreur qu'on pourrait considérer comme acceptable car après tout à part quitter tu n'as pas grand chose à faire.

Ça dépend complètement de l'application! Si tu fais du calcul numérique en C++ tu as intérêt à gérer correctement l'épuisement de la mémoire disponible pour ton processeur. Ce type d'application favorise grandement la fragmentation de la mémoire et alloue de gros objets: le système peut très bien tourner sainement et quand-même refuser une alloc trop grosse.

Dans un domaine différent on peut mettre des quotas sur les processus, ça peut aussi être une raison pour lesquelles la demande de mémoire échoue, sans que le système ne soit particulièrement sous pression.

Sinon il y avait aussi:

Un faucille est plus « simple et cohérente » qu'une moissonne batteuse. Mais je préfère utiliser une moissonneuse batteuse.

Mais c'est déjà assez sympa de ne pas avoir fait appel à la traditionnelle voiture.

Si tu veux des détails, il suffit de demander.

Tu peux initialiser les variables non objet avec la syntaxe du constructeur, comme dans:

int a (5);

À part pousser les gens à croire qu'un int est un objet, à quoi sert cette syntaxe?

Le C++ est plein de mécanismes complexes qui n'intéragissent pas très bien entre eux, par exemple
la surcharge d'opérateur qui ne se combine pas super bien avec les namespaces.

Ensuite le C++ propose beaucoup de mécanismes analogues avec quelques petites différences subtiles:
il faut donc souvent faire des choix d'architecture, et c'est difficile les choix, surtout pour les débutants. Par exemple, on peut très bien utiliser un struct à la place d'un namespace la plupart du temps. Les particularités sont que le struct peut être argument d'un template et pas le namespace, tandis que le namespace peut-être déclaré par petits bouts et pas le struct.

Le C a ses propres défauts (qui ont presque tout été gardés en C++) mais le C++ est bien pire.

Sinon si tu veux des arguments supplémentaires sur les 1001 incohérences du C++ tu peux regarder là

http://yosefk.com/c++fqa/index.html

Il est aujourd'hui ridicule de choisir le C face au C++. Je m'explique: Le C++ étant multi-paradigmes, it est à la fois de bas niveau et de haut niveau. Prenant le meilleur des deux mondes.

Non, comparé à C++, le C est un langage simple et cohérent — c'est dire l'état de C++!

Si tu trouves que le C++ est trop compliqué, tu n'est pas obligé d'utiliser les exceptions

Tu conseilles d'utiliser la forme de new qui renvoie des NULL?

ou des templates dans ton application.

Dans ce cas, ça va être assez dur d'utiliser la biblitohèque standard, boost ou Qt, comme tu lui suggères:

La bibliothèque standard du C++ est déjà bien fournie. Mais tu peux aussi utiliser Qt ou boost qui sont de bonnes bibliothèques. Et toutes les bibliothèques C sont aussi accessible via C++.

C'est vrai que le noyaux linux est trop complexe pour être réalisé en C.

Il y a plein de sortes de complexités. Puisque dans la question de EmilienR il y a écrit

Je souhaite aujourd'hui me lancer dans un projet où je devrai gérer de l'héritage. J’aimerais avoir ton avis sur le langage à utiliser

on peut largement déconseiller le C dans ce cas de figure pour les relations d'héritage complexe.

Sinon des logiciels complexes au sens large écrits en C, il y en a une paire effectivement.

Si c'est possible évite d'éviter C++ pour ton projet. Les raisons qui pourraient te faire choisir C++ sont:

• ton chef;
• ton client;
• tu connais C++, tu ne veux pas apprendre un nouveau langage et ton projet est trop complexe pour être raisonnablement réalisé en C;
• tu veux consolider tes compétences en C++ pour contribuer à un projet C++.

Si aucune de ces affirmations n'est vraie, alors choisis un autre langage, qui est vraiment de haut niveau.

Je suis plutôt pour OCaml ou Common-Lisp mais d'autres ont suggéré des langages que je ne connais pas (Vala, Go, etc.) qui peuvent t'attirer. J'ai déjà mené à bien un moyen projet (6 mois) en Python et justement, pour les moyens projets, je ne te le recommenderais pas.

Est-ce la bonne façon ou juste un gros hack bien moche qui marche juste dans ce cas, je ne sais pas.

Ton programme d'avant est faux, tout simplement.

MaClasse* nouvClasse (nouveauSocket);

ne fait pas du tout ce que tu penses: cela initialise un pointeur nouvClasse sur type MaClasse avec la valeur nouveauSocket. En l'absence de surcharge d'opérateurs etc., c'est exactement comme si tu avais écrit

MaClasse* nouvClasse = nouveauSocket;

et le message du compilateur devient limpide. En C++ (langage tout pourri™) il y a deux-cent treize façons d'initialiser les variables qui se mélangent avec les initialisations des objets. Tu viens de te faire avoir par un des aspects deagréables du langage qui favorise la confusion entre les variables «immédiates» et les objets (les premières n'ont pas de constructeur).

Tu peux aussi écrire

int n (1);

pour initialiser un entier.

C'est quoi ton livre pour le C++? Comme apparemment tu débutes dans le langage, je te recommande:

http://www.parashift.com/c++-faq/
http://yosefk.com/c++fqa/index.html

(En anglais.) Cela devrait t'aider à avoir une vision plus claire du langage plus utile qu'une conception basée sur «les gros hacks bien moches».

Et ta version avec le new est bel et bien la façon idoine de faire.

Bon courage!

Lors de la compilation, j'ai cependant l'erreur

Quel est le code qui produit l'erreur? Le constructeur?

Mon hypothèse est que tu tentes une allocation de type

QTcpSocket* a;
MaClasse* b = a;

qui ne fonctionne pas pour la bonne raison qu'elle ne veut rien dire et que tu n'as pas défini de conversion dans ton exemple (comme tu as l'air de le croire).

Mais sans ton code qui déclenche l'erreur, c'est impossible d'être catégorique.

Whaou! ça c'est du conseil!

Saytun site de qualitay ici ;)

Ce qui est toujours important c'est de correctement définir la tâche qu'on veut accomplir: la problématique «màj de la version de la base de données» est une description de très haut niveau qu'il faut définir pour pouvoir l'implémenter: le plus important est donc de définir les critères de succès (écrire des phrases qui doivent être vraies lorsque le processus est terminé) et comme on peut rarement avoir une procédure qui donne des bons résultats dans tous les cas de figure il faut arbitrer pour déterminer ce qui est important et ce qui l'est moins.

Ton nouveau schéma est-il un sur ensemble strict de l'ancien (cas facile)?

Je ne suis pas sur de comprendre cette remarque.

Ce que je veux dire est que dans le cas où la nouvelle version A' de ton schéma A diffère de la première seulement par l'ajout de tables et de colonnes (hors clef) tu es dans un cas favorable, nettement plus facile à traiter que le cas où tu dois changer la clef principale d'une table, détruire une table ou pratiquer une transformation non réversible sur tes données. C'est donc un type d'évolution à privilégier tant qu'il est possible, soit dans les màj soit déjà dans la conception de la bd.

Voilà merci pour ton aide. Ca a été très instructif !

Avec plaisir, bonne chance!

que tu voulais écrire?

Quitte à faire des vannes complètement perraves autant les faire mal! :-) Merci de le relever!

Mais t'as un besoin précis pour ce genre de dessins, ou bien tu me dis juste ça parce que ton cerveau bouillonne de transfo mathématiques et que tu te dis que c'est cool, mais en vrai t'utiliserais pas?

Je n'ai aucun besoin précis et Gimp ne fait pas vraiment partie des logiciels que je maîtrise — ni que j'ai besoin de maîtriser.

Ma motivation est tout simplement «Tiens, peut-être qu'il connaît pas et qu'il trouve ça rigolo.»

rigolo: adj. synonyme ringard de cool.

ringard: adj. contraire de cool mais pas de triste.

Quoi, la façon dont on écrit un mot peut changer le sens!?

Sauf les palindromes qui n'ont qu'un sens. :)

En lisant ton message, je me suis demandé pourquoi se limiter aux symétries axiales et centrales! (Mathématicien@inside)

Il y a plein d'autres sortes de symétries, et puis on peut les combiner entre elles, ce qui donne deux directions:

1. Peux-tu envisager d'appliquer plusieurs transformations successives au coup de pinceau?

2. Peux-tu envisager d'utiliser des transformations non euclidiennes, comme les transformations homographiques (les perspectives) ou les transformations hyperboliques (comme dans les jolis dessins d'Echer).

La difficulté consiste essentiellement à proposer une interface compréhensible pour spécifier la chaîne de transformations. Mais dans certains cas cela semble assez facile, comme par exemple le cas de la géométrie hyperbolique à la Echer où tu pars des mêmes transformations initiales que l'artiste et peinturlure ton disque ou bien le cas des groupes paveurs, où tu choisis un groupe paveur (liste finie de groupes) et un triangle de base qui va être reproduit partout sur le plan.

Un autre genre de transformation intéressante serait peut-être celle qui permet de dessiner une scène et son reflet dans un miroir concave — à la mode des peintres flamands.

Aussi, pour terminer sur une question existentielle: la civilisation de l'écrit est-elle en voie d'extinction? :)

Commence par prouver qu'elle a déjà existé!

que tu cite*!* … mon téléphone portable […] ont*!* … qui y est intègre*!* …

La tablette n'ai pas faite pour la saisie

C'est pas beau de tout coller sur le dos du matériel! :D

La curiosité essentiellement.

Et qu'est-ce qui t'a fait rester sous i3?

Je viens vers vous pour savoir comment vous géreriez ce cas là.

C'est une problématique très large, la réponse peut tenir en trois lignes… ou bien occuper une service de devs pendant plusieurs mois!

En inglishe, cela s'appelle un «database scheme upgrade» et une «data migration» — juste pour t'aiguiller dans tes recherches.

Pour définir ta stratégie, tu dois définir tes objectifs et faire la liste de tes contraintes. Voici quelques questions pour commencer.

Pour définir tes objectifs:

• Après la mise à jour de sa BD consécutive à la MÀJ de 1 à 2 de ton soft, l'utilisateur remarque que sa fonction préférée qui marchait très bien dans 1 ne marche pas dans 2. Il ne peut se permettre d'attendre une MÀJ et souhaite retourner à la version 1. Comment fait-il?

• Les système en prod peuvent-ils avoir un downtime?

Tes contraintes:

• Quels sont les systèmes de BD supportés?

• L'upgrade de BD se fait côté soft ou bien avec un script SQL/sh?

• Qui fait l'upgrade (admin, utilisateur inexpérimenté?)

• Ton nouveau schéma est-il un sur ensemble strict de l'ancien (cas facile)?

• Que doit-il se passer si la version 1 de ton soft tourne sur une BD avec le schéma de la version 2?

(Complètement hors-sujet.)

Moi, j'aurais plutôt dit «Bla, bla, bla,» une chanson de Katherine qui donne la banane:

http://www.youtube.com/watch?v=oIlporX0pok

C'est juste qu'elles emploient - pour des raisons culturelles et pratiques - des méthodes moins efficaces.

Pourtant, depuis l'apparition de la scie-sauteuse et du paracétamol, l'homme et la femme sont sur un plan d'égalité, non?

Plus sérieusement, la tentative de suicide n'a pas toujours pour but principal de se donner la mort, elle peut aussi être un cri de désespoir: pour moi il serait pertinent d'essayer de savoir quelle est la proportion des suicides ratés parmi ceux dont le but était effectivement de mourir, et de savoir quelles si le genre est un facteur explicatif.

pas mal de gens ne fait pas cette différence

Tu as accordé le verbe avec «pas mal» qui est singulier, c'est ça? :)

Dans la liste Apple, il manque bien-sûr le nom de Jef Raskin, auteur de “The Humane Interface.”

http://meatballwiki.org/wiki/JefRaskin

Juste par curiosité, est-ce que tu écris toujours un journal de 9 pages lorsque tu réalises que la plupart des gens n'ont ni culture ni perspective? (On peut par ailleurs avoir raison tout en étant inculte, soit dit en passant.)