Il me semble juste comme ça qu'il y a un moment qu'on a pas revu dnob dans le coin...

d'apres sa carte de visite, ca fait 3 semaines qu'il ne s'est pas loggue.

"En 3d, ton dessin defini un cercle sur la sphere de centre B, queles sont donc les points qui t'interessent?"

merci de ta réponse godrik. les points qui m'intéressent sont les coordonnées maximales du cercle dessiné, donc le plus haut, le plus bas, les deux valeurs extrêmes latérales.

le théorème de pythagore? bien vu, ab²=ac²+r², donc à partir de là, il devrait être facile d'en déduire la longueur ac... ça m'avance déjà un peu.

merci bien, je vais essayer de régler le problème en partant de là.

ah, merci pour l'arcsinus aussi, j'avais lu un peu vite... tu viens de me donner la solution complète, il n'y a plus qu'à l'implémenter.

Salut tout le monde !

Je suis entrain de lire le livre effective C++, mais il y a un passage d'ange l'item 23 qui me pause un petit problème,

Voici les bouts de code : http://pastebin.com/i0gQegH6

je vous colle l'extrait :

Item 23: Prefer non-member non-friend functions to
member functions.

"....
So which is better, the member function clearEverything or the non-
member function clearBrowser?
Object-oriented principles dictate that data and the functions that
operate on them should be bundled together, and that suggests that
the member function is the better choice. Unfortunately, this sugges-
tion is incorrect. It’s based on a misunderstanding of what being
object-oriented means. Object-oriented principles dictate that data
should be as encapsulated as possible. Counterintuitively, the mem-
ber function clearEverything actually yields less encapsulation than the
non-member clearBrowser. Furthermore, offering the non-member
function allows for greater packaging flexibility for WebBrowser-related
functionality, and that, in turn, yields fewer compilation dependencies
and an increase in WebBrowser extensibility. The non-member
approach is thus better than a member function in many ways. It’s
important to understand why.
...."

Question 1 : Pourquoi clearEverything apporte moins d'encapsulation que clearBroswer ?
Question 2 : Pourquoi clearBrowser offrirait une plus grande flexibilité, et moins de dépendance de compilation ?

Et dernière question, non-située dans cette extrait :

Si l'on veut créer une méthode non-membre,non-amies telle que clearBrowser, où devrions-nous la mettre ? Dans browser.h avec un namespace contenant la classe et les fonctions non-membres,non-amies ? Dans un autre fichier ?

Merci de vos éclaicissement

Je vais te donner mon interprétation.

Tu as 3 méthodes de bases dans une classe (clearCookies, clearCache, clearHistory). Puis tu as une fonction utilitaire qui fait tous ces 3 à la fois.

Si ta fonction utilitaire est non-membre, il faut penser qu'elle peut être dans un fichier séparé, ce qui fait que tu peux décider de l'inclure ou non. Et ca te donne la possibilité par exemple de ne pas l'inclure et proposer ta propre version de clearEverything().

SI j'ose un parallèle un peu boîteux, dans la STL ils n'ont pas par exemple cherché à proposer une méthode de tri, d'inversion des valeurs ou de sommage dans les structures de données comme vector ou list.
Si tu veux ces fonctionnalités de commodité, elles sont dans un fichier .h séparé que tu peux inclure si tu comptes réellement les employer, y renoncer si tu n'en as pas d'utilité, tout comme tu peux créer tes propres versions (pourquoi pas ton propre tri, ton propre algo de machin truc) dans le namespace sans trafiquer l'existant.

Ca fait effectivement moins de code à compiler, parce que les fonctionnalités de commodités sont externes, facultatives et donc on peut choisir de ne pas les inclure du tout. De l'autre côté c'est plus flexible car on peut en ajouter sans trafiquer le code de la classe qu'on veut enrichir.

En gros, au lieu d'avoir pleins de fonctionnalités bourrées dans une grosse classe monolithique qui fait le café, tu as une API d'assez bas niveau qui fournit l'encapsulation et les méthodes de base qui travaillent sur les membres, et tu laisses la liberté à celui qui utilise le code de décider s'il veut se servir de tes fonctions utilitaires ou avoir les siennes, et cela peut être fait sans modifier le "coeur".

Je pense que l'idee est que si l'operation que tu essaye d'ecrire utilise uniquement les interface publique de ta classe, alors ca n'a pas de raison d'etre dans la classe en elle meme. Ca rends la classe plus grosse sans bonne raison.

Ok, merci pour vos réponses, j'ai mieux compris !

Dernière question, si on veut écrire des fonctions non-membres (dans ce cas clearBrowser()), Où faudrait-il le faire ?

1) Prototype dans le .h et implémentation dans le .cpp
2) Même chose que 1), sauf on met un namespace qui englobera la classe + les fonctions non-membres
3) Dans un autre fichier, appelé par exemple xxx.h et xxx.cpp

https://www.destroyallsoftware.com/talks/wat

Bonsoir

Dîtes j'ai une petite question qui me trotte dans la tête depuis quelques jours, et j'ai beau tourner 4a dans tous les sens, je trouve pas de réponse...

On est d'accord que quand quelqu'un nous fait télécharger un script ou exécutable "fait maison", on aime bien disposer des sources, pour être sûr qu'il y a pas embrouille, du moins jeter un coup d'oeil, on l'a tous fait un jour ou l'autre. Du coup les petits devs qui font des utilitaires assez spécifiques distribuent souvent les sources Et le programme exécutable.

Mais... Et là je bloque... Comment peut-on savoir que les sources sont bien celles du programme exécutable ? J'veux dire, rien n'empêche un développeur de mettre en ligne une application censée se comporter d'une certaine manière, fournir les sources qui décrivent effectivement ce qui devrait se passer, mais que l'exécutable ait un autre comportement (ou rien que 2-3 fonction ajoutées).

au final, à moins d'y aller en reverse engineering on peut pas savoir ce qu'il y a vraiment dans l'exécutable...

et bien, si on est très méfiant, on recréée l'exécutable après avoir lu attentivement les sources pour vérifier le résultat attendu, sinon, on lui fait confiance et on lance le programme, conscient qu'un développeur se ferait tr4sher par tout le web s'il osait diffuser un exécutable vérolé sans l'annoncer de manière explicite.

Ok, mais du coup en dehors de l'aspect "confiance" basé sur les autres utilisateurs du logiciels, et à tous ceux qu'on considère comme plus compétents que nous, il y a pas vraiment de solution ?

Tikim, c'est le probleme classique de trusting trust:

http://cm.bell-labs.com/who/ken/trust.html

Si le problème est uniquement d'un point de vue de sécurité. Il y a plusieurs petits trucs : les firewalls, les sandbox, et un tout basic : l'account control.
Sitôt qu'un petit utilitaire demande des élévations de droit ou tente d'ouvrir des sockets sans raison évidente, c'est le moment de se méfier.

Autrement la règle générale c'est de jamais exécuter du code provenant de sources dont tu n'as pas une certaine confiance.

Très intéressant godrik, merci. Et _skip oui perso je me suis posé cette question pour un utilitaire précis dont l'auteur a précisé qu'il n'établissait aucune communication par socket, donc là c'est facile de vérifier. Mais dans le cas où c'est un utilitaire dont le fonctionnement normal est d'ouvrir des sockets, alors l'utilisateur ne voit pas ça comme un problème, et là il peut y avoir abus...

La plupart des "bons" firewall t'indiquent vers quel IP ou domaine se dirigent les connexions. Un firewall ça reste un excellent moyen de se prévenir contre les downloaders et les virus.
Cependant tu peux jamais compter seulement là dessus. De mon côté je n'ai pas d'antivirus sur mes machines, en contrepartie je suis super prudent sur ce que je télécharge.
Il y a une catégorie d'utilitaires qui ont plus de chance d'être des merdes (ou d'en contenir que d'autres), parmi ceux-là il y a ces trucs pour convertir des formats vidéos, les packs de codecs, en bref un peu tout ce que cherche le néophypte qui commence le P2P...

Il est toujours bien de se renseigner rapidement par google pour checker si un logiciel est fiable et vient d'un auteur sérieux et respectable avant de l'installer. Ensuite il faut idéalement obtenir le logiciel sur le site de son éditeur, éviter les sites de téléchargements qui repackent les installeurs avec des barres d'outils et des saloperies.

La prudence utilisateur, y'a que ça...

Et éviter tous les "gestionnaire de téléchargement". Donc avant de télécharger un fichier, vérifier qu'il s'agit bien du fichier voulu, et pas de l'installateur du gestionnaire de DL servant à télécharger ensuite ce fichier. Ouais, y'a des tas de malware là-dedans.

Mais là je parle de logiciels plus communautaires et spécifiques, parce que la confiance vient de l'aspect communautaire. J'ai aucune confiance en un site de téléchargement quelconque, de toute manière.

Ma nouvelle chanson préférée, qui parle d'algorithmes, de problèmes NP complets, de recherche du chemin le plus long, que du bonheur

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

https://docs.google.com/presentation/d/1h49gY3TSiayLMXYmRMaAEMl05FaJ-Z6jDOWOz3EsqqQ/preview?usp=sharing&sle=true#slide=id.p

Petit slide sympa, appuyez sur S pour avoir les commentaires sur les slides.
Des choses assez connues comme restrict ou la boucle descendante, mais des trucs rigolo aussi comme l'utilisation de [] dans tous les sens ^^

Merci, très intéressant , travaillant sur un compilateur et la génération de code machine