fearan a écrit 7160 commentaires

Je vais peut être dire une connerie, ne connaissant pas le type de bar
mais les versions suivantes ne corrigeraient pas le problème ?

// dans le cas d'un tableau
foo(*(bar + i+ 1 ), *(bar+i+2), *(bar+i+3));
bar+=3;

// ou 

typeMuche &p1=bar[++i];
typeMuche &p2=bar[++i];
typeMuche &p3=bar[++i];
foo(p1,p2,p3);

En C, comme en C++ (et comme en java), j'ai appris que les ++ et—ne s'utilisent que lorsque l'élément incrémenté n'est référencé qu'une seule fois dans la ligne, sinon le comportement est indéfini pour la majorité des gens relisant le code :)

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

gné?

Tu déclare toutes tes classe avec le mot clé struct? Parce que si tu défini ta classe avec le mot clé class, c'est pas publique.

Tu confonds peut être avec le java où ne rien mettre c'est protected, et où il faut répéter avant chaque déclaration.

En c++ tu fais juste

public :
   void jaimeLesChatons();

protected: 
   void mettreLeCouvert();

private:
   void cuisinerChaton();
   void jeterLesOs();

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

en même temps si le virus te supprime tes données ça va se savoir et le nombre de rançons payés va être plus faible; par contre ce qu'il pourrait faire c'est un truc aléatoire (genre 1% de chances de tout supprimer)

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Il n'empêche qu'être fan de MS, n'implique pas que la société l'utilise comme levier.

Je suis fan de linux, je me bas pour l'utiliser en milieu pro (car c'est un OS prêt pour le travail), c'est pas pour autant que je suis en cheville avec Canoncial, par contre pour la suze…

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Je dois dire que je me suis bien marré en lisant l'article, ça m'a rappelé le temps où je jouait avec les boost::bind*. Il faut bien avouer que le gars à un certain niveau en C++, mais je m'en veux d'avoir tout lu, maintenant je suis incapable de savoir si je pourrai trouver la solution moi même; bon ce qui est certain c'est que j'aurai aussi pas mal testé différents trucs.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

• c'est court
• ça évite de rajouter un mot clé (lambda)
• sur un clavier qwerty c'est un geste :)
• aucune chance de mal interpréter le truc dans le contexte en question (point de vu parser)

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

petite question aux habitués du python : itère t'on sur la totalité de la liste, ou s'arrête t'on dès qu'on choppe un True?

même question avec

if any([i < 0 for i in foo])

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

pour le liste=range(50)
il faudra utiliser std::generate (http://www.cplusplus.com/reference/algorithm/generate/) qui permet de faire plus compliqué ou iota

#include <vector>
#include <numeric>

std::vector<int> v(50) ; 
std::iota (v.begin(), v.end(), 0);

A noter que ça marche avec un int, mais avec tout objet ayant aussi redéfini T &operator++() :D

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

ah pardon, j'avais oublié que certains codaient sur un OS pas prêt pour le travail ;)
(oui bon j'ai 8H d'avance ;))

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

la question n'est pas d'apprendre spécifiquement une recette par langage, mais un réflexe de que faire avec la ressource une fois qu'elle est consommée, en Java (donc jvm) InputStream, tu es sensé faire un close après avoir lu le flux.
Pareil en VB (donc Excel) : http://msdn.microsoft.com/en-us/library/system.io.filestream.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1.

Et si algorithmiquement, c'est un point sans intérêt, lorsque l'on passe à la programmation cela fait parti de l'apprentissage du langage, que ce soit C, C++, Python, perl, Java, VB…

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

arggh je me rends compte que la lambda est pas passé, je reprends donc

if ( std::any_of(foo.begin(), foo.end(), [](int i){return i<0;}) )

Le crochet a été interprété comme un lien wiki vide…

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Le problème n'est pas le choix de la structure ou d'algo, mais la non libération de la ressources (par exemple le supprimer du Set/List en java), c'est une problématique avec toutes les ressources, tout comme on apprends à faire un close après un open, c'est exactement le même mécanisme. J'ai pris cet exemple parce que j'y ai été confronté récemment, mais le problème est présent a tous les niveau (par exemple pas de close d'une connexion ftp, ou d'un fichier)

Si j'ai bien suivi, le but n'est pas d'apprendre à bidouiller, mais a programmer. La contrainte de devoir gérer manuellement les ressources permet de structurer, éviter d'avoir une représentation du dieu des pastafariens en guise de doc d'architecture.

Bref un fois que t'a passé le passage obligatoire pseudo code sur feuille (ou tu peux dire trier le tableau trucmuch dans l'ordre croissant), tu peux ensuite passer à l'implémentation avec un langage quelconque et si tu utilises une ressources (un fichier par exemple), il faut la libérer après usage. C'est un réflexe qui se prends dès la première utilisation de ressource et qu'il faut pas attendre d'avoir un gros projet pour se la poser, c'est trop tard, les mauvaises habitudes ont la vie dure.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Mais comment peut-on croire qu'un langage qui impose d'assimiler la POO pour eécrire le moindre truc, qui supporte le multi-héritage

#include <iostream>

int main(int argc, char *argv[])
{
  std::cout << "Hello World" <<std::endl;
}

Où vois tu qu'il est nécessaire d'assimiler la POO?
De même le mutli héritage, n'est absolument pas nécessaire pour coder en C++, c'est simplement disponible le jour où tu en aura besoin. Bref, critiquer le C++ sur des concepts très avancés (qui en plus sont logique une fois qu'on connait un minimum le langage), inutile à l'apprentissage de base. S'il était nécessaire de maitriser tous les aspect d'un langage de programmation pour l'utiliser, ou qu'il était nécessaire de tout apprendre d'un coup, je suis au regret de t'informer qu'a part le go, oOok, et l'assembleur et quelques rares exceptions (dont le python ne fait pas partie) aucun langage ne correspond à la requête.

Ecrire une liste et la manipuler en une ligne.

if ( std::any_of(foo.begin(), foo.end(), {return i<0;}) )
ou globalement tout ce que tu peux trouver ici :
http://www.cplusplus.com/reference/algorithm/
avec notamment :
http://www.cplusplus.com/reference/algorithm/for_each/

Votre algorithme transparait immédiatement avec l'indentation. Plus besoin de "finsi", plus besoin de déclarer les types …

Mais qu'est ce qui t'empêche d'indenter ton pascal?

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Le printf debugging c'est un style de debuggage que ce soit a coup d'echo, std::cout, System.out.println, print… Souvent considéré comme néfaste, car il change le code exécuté, rendant les erreurs aléatoires différente de l'exécution traditionnelle (ce qui généralement est une invocation à valgrind)

Dans les autres méthode utilisés tu as le TAF (Try And Fail) qui consiste à tester différents paramétrage / ordonnancement / Majuscule/minuscule, qui est très pratique lorsque tu découvres des classes graphique peu ou mal documentées.

Enfin plusieurs minutes a linker ? Je ne sais pas sur quelle brouette tu bosses, mais sur un code déjà compilé 1 fois, avec tous les .o le link sur un petit projet d'1,3 million de ligne est inférieur à la minute.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

J'ai appris le C++ en IUT, et je n'ai pas vu les catastrophes que tu décris, j'ajouterai que pour les projet universitaire, il y a valgrind qui est plus que suffisant pour pointer les boulettes (ça marche aussi en milieu pro, mais faut pas être pressé ;) )

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Il y a surtout 750 façon de gérer sa mémoire en C++

Ah? je suis curieux de voir l'énumération ;), et surtout dans quel cas tu te retrouves avec un mélange des genre lors de cours.

Pour avoir fait pas mal de C++, et continuer à en faire tous les jours ouvrés, je n'ai pas vu de mélange des genre que tu évoques. Si tu parles des différentes façons d'implémenter l'operator new, j'ose espérer que le gars qui se permet de le faire sait ce qu'il fait, si c'est le mélange de shared_ptr (et leur contrepartie weak_ptr), auto_ptr, uniq_ptr, pointeur, référence, tu arrives toujours aux mêmes questions, et ce quel que soit le langage :
* A qui appartient l'objet? (fait il bien le delete ?)
* d'où vient il ? si c'est d'un autre objet/bibliothèque (via make, creat…), y'a t'il un transfert de propriété ?

Ça fait 9 ans que je fais du C++ en milieu professionnel, je n'ai jamais eu de problème la dessus, et maintenant qu'on a les uniq_ptr et shared_ptr dans la stl, c'est encore plus simple.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Non la bonne conception est la base de toutes programmations, c'est un réflexe qu'il faut prendre dès le début. Ce n'est pas un problème d'optimisation, mais un problème général. Typiquement tu vas avoir un Set de session (ou une Liste) qui va stocker la collection de sessions, et en crée une à chaque nouvelle ouverture de sessions.

Tu vois le problème? quelque soit les optimisations, tu finiras toujours par avoir un java heap space. Qui code en java et connait les java.lang.ref.WeakReference ? J'ai trop vu de personne penser que le ramasse miette était un outils formidable capable de deviner quand un objet ne sera plus référencé.

Ce n'est pas une optimisation, je ne parles pas de grappillage d'un octet par ci par la, mais d'avoir une notion de qui possède quoi, quand créer quoi, quand détruire, attendre avant de le faire revient à dire jamais, les mauvaises habitudes restent.

si on parle d'apprendre les bases de la programmation, oui l'appentissage de comment écrire du code pour que la JVM puisse se débrouiller correctement avec en fonction du type d'appli que tu vas écrire est une premature optimisation

Non on parle de réflexes de programmation, de question à se poser avant même de coder, et ce quel que soit le langage, j'ai pris java heap space comme exemple, par ce que c'est ce a quoi j'ai été confronté plusieurs fois, mais j'ai eu la blague de plus de mémoire dispo sous python, de memory leak en C, C++… Il ne s'agit pas de politique spécifique de code (si pour toi faut attendre de plus avoir de mémoire pour se poser la question de l'appartenance des variables, j'espère ne jamais tomber sur ton code, ça doit ressembler un un plat de spaghetti)

L'énorme avantage du C++, c'est que tu peux prédire lorsqu'un destructeur sera appelé, et tu peux suivre la séquence à l'aide de printf debugging.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Je répondais au fait que tu disais qu'il était essentiel d'apprendre le cycle de vie d'un objet, ce qui n'est pas au programme au tout début.

d'un objet non, d'une donnée oui. Tu vois la visibilité des variables, le passage en paramètre, la limitation des scope (for( int i = 0…)
i n'est plus visible/vivant après le for (sauf si le compilo ne respecte pas la norme). Si tu déclare dans le main

auto revenu=42;

il n'est pas visible de la fonction Tartempion, a moins de le passer en paramètre. Même si c'est des type primitifs, la question se pose quand même. J'ai dit objet j'aurai du dire variable.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

ça tombe bien, en c++ tu n'es nullement obligé de faire de l'objet pour faire un truc de base. Avec ce petit avantage par rapport au C : le type std::string; tu peux avoir des tableaux de taille variable (std::vector), des tableaux associatifs std::mapstd::string,int, des collections std::set…

La sortie se fait assez simplement std::cout << "Hallow World " << 42 << std::endl;
la lecture se fait tout aussi simplement int plop; std::cin >> plop;

Enfin bref comme je l'ai dit il est inutile d'apprendre tout le C++ d'un bloc (de toute façon personne humainement normalement constitué ne maitrise le C++) , il vaut mieux y aller progressivement, en fonction de ce qui est nécessaire d'apprendre.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Je déconseillerais le C à quiconque ne souhaite pas devenir un "gros" programmeur,

Au contraire, je l'imposerai a quiconque souhaitant devenir un gros programmeur, pas forcément pour l'utiliser en entreprise, mais j'en ai mare de voire des gens coder comme si la ram était infinie, ça marche bien sur les 2 jours de test, c'est validé en recette, puis dès qu'il y a un usage intensif, y a du java heap space ou autre erreur disant qu'il y a plus de mémoire (ou l'appli qui se fige en attendant que le ramasse miette récupère un peu de place).

Le C (avec malloc et free), demande juste un peu de rigueur :

• tu écris un malloc() => tu écris le qui va avec free(), et si tu ne le fais pas tu commente pour dire que l'ownership passe à telle fonction
• tu récupères un pointeur ? as tu l'ownership dessus (=> free)
• tu utilises un tableau combien de cases as tu besoins
• tu fais une boucle quels sont les conditions / cas de sorties
• …

Bref la plus grande partie des écueils du C, soulèvent généralement une question qu'il est pertinente de se poser, et qu'il faut généralement se poser avant de prendre le clavier. Je croise bien trop souvent du code où ça a été écrit sans la partie réflexion avant, et où il y a verrue sur verrue pour adapter le code aux nouvelles demandes, alors qu'une écriture pensée, propre à l'origine n'aurait eu besoin que d'extensions.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

ramasse miette ;

C'est justement l'une des features que je ne recommande pas pour commencer. Obliger aux apprenants à se poser la question de la visibilité et la durée de vie d'un objet est, de mon point de vue, essentiel, sinon ils ne prendrons jamais les bons réflexes.

Pour ça le c++ (notamment le dernier avec le shared_ptr inclus de base) me parait un bon choix; tu as accès au structures classiques, les destructeurs (pour tracer la destruction par exemple). Suffit de commencer par une petite partie du C++ (pas de pointeur de fonction, pas d'écriture de template, les new que dans des scoped_ptr ou shared_ptr, et il est possible d'enrichir peu a peu la connaissance du langage (const par exemple).

Bref avec un seul langage il est possible de voire beaucoup d'aspects de la programmation, par contre il faudrait lui adjoindre une bibliothèque graphique simple.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

je m'attends à ce que les données que je confie soient traitées conformément aux pratiques de sécurité habituelles.

Ben pourquoi tu râle? Le niveau de sécurité de linuxFr est trop élevé? Je commence à comprendre, on est parti sur un quiproquo depuis le départ.

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Désolé, mais de mon point de vue LinuxFR rempli plus que largement ses obligations de sécurité.

Pour reprendre ton exemple de la crèche, t'es plutôt le gars qui râle réclamant des mesures de sécurité supplémentaire aux exigences légales (genre 1 adulte pour 2 enfants) et qui refuse de payer pour.

La loi réclame que le site ait un niveau de sécurité relatif a la criticité des données traitées. Les mots de passes sont hashés et salés. Tu veux quoi? Qu'est ce qu'il y a de si critique pour que tu réclames plus? C'est tes 37 commentaires ou tes deux journaux qui pourraient êtres dénaturés ? Ton adresse mail qui partirait dans la nature?

Bref la loi n'impose pas de faire une forteresse numérique dès qu'on crée un site web (heureusement)

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Tu es prêt à payer un admin sys pour linuxfr, c'est gentil ;)

Non, la procédure normale en sécurité est d'arrêter la machine vérolée, et d'assurer la continuité de service à partir d'un état que l'on sait sain

C'est gentils mais reprendre le site d'il y a 1 ou 2 ans c'est autre chose que repartir 1 ou 2 semaines, sans oublier que certains vont avoir oublié les mots de passes de l'époque. La problématique des mots de passes a été suffisamment abordée ici pour que ceux qui se soucient de sécurité aient un mot de passe unique.

Il faut aussi différencier ce que l'on considère comme critique (par exemple le site d'une banque ou de paiement qui voie passer des n° de CB) de ce qui l'est pas. Et désolé mais je ne considère par linuxfr comme critique, et de ce fait je préfère une solution qui a le moins d'impact sur son usage.

Bref ton niveau d'exigence dépasse de très loin ce que j'estime nécessaire pour un site bénévole n'ayant rien de critique (y'a même plus les messages privés).

Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Je suis le seul à trouver complètement hallucinant la légèreté avec laquelle la sécurité des données des utilisateurs du site est prise en compte ?

Pas vraiment, en fait pour des raisons historiques, mon compte linuxfr est sur un compte mail différent de ma boite principal actuelle et date de l'époque où j'avais un groupes de logins et des mots de passes différents pour tous les sites; j'étais parano, et je n'étais inscrit que sur quelques sites.

Historiquement mon mot de passe sur linuxfr est faible (trop court, pas assez varié), mais aussi unique, et n'a pas du changer depuis sa création; si quelqu'un le trouve, tout ce qu'il aura c'est accès à mon compte linuxfr, qui lui même n'est rattaché à aucune identité; tout ce que peu faire un pirate c'est nuire à mon karma.

Ce qui serait vraiment hallucinant c'est quelqu'un qui veut faire attention à sa sécurité sur linuxfr utilise le même mot de passe ailleurs :D

Il ne faut pas décorner les boeufs avant d'avoir semé le vent