yo ,
void* dst c'est un pointeur générique dans lequel va être mis l'entier correspondant à la chaîne que tu donnes (src).
A part ça :
inet_pton( AF_INET, &adresseIPentier, &adresseIPentier);

Non ça devrait être :
inet_pton( AF_INET, adresseIPChaine, &adresseIPentier);
En regardant les arguments de inet_pton.

printf("%h",adresseIPentier);
Ca devrait être un "%d"

Aussi tu déclares adresseIPentier en long, ce qui peut faire 64 ou 32 bits selon la machine et le système, si tu veux avoir un entier de 32 bits tu dois utiliser un (unsigned ?) int
Edit : grillé

A part ça ton code corrigé fonctionne sur debian x64 :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <arpa/inet.h>

int main()
{
    char adresseIPChaine[16];
 	unsigned int adresseIPentier;

    printf("entrez une adresse ip en décimale pointé \n");
    scanf("%s",adresseIPChaine);


 	inet_pton( AF_INET,  adresseIPChaine, &adresseIPentier);

    printf("%d\n",adresseIPentier);

    return 0;
}

Bonsoir,
Déjà un immense merci pour vos réponse
@ godrik : Je sais que j'ai des erreurs (le compilateur me l'indique) que je ne comprend pas ,ainsi que la fonctions
@kernel
Merci pour tes explications
Oui quel idiot j'ai oublié le unsigned
Je ne connais pas debian x64 (fait t'il la même chose que code block? il n'a pas de différence ?)
De plus j'aimerai savoir si je n'est pas de librairie autre a ajouté ? Car je suis chez moi sous windows et dans me recherche j'ai vue que selon l'os les librairie diffères ?
Merci d'avance

Je me demandais ce que vous pensez de ceci :

http://www.developpez.com/actu/79949/La-programmation-fonctionnelle-est-elle-le-futur-Selon-un-adepte-tous-les-langages-modernes-vont-bientot-se-baser-sur-ses-principes/

Ce n'est pas la première fois que j'entends dire que c'est le futur, mais on entends jamais parler quand même que de la poo...

Pour ça il faudrait que les entreprises suivent mais certains langages sont très prometteurs : Scala , Ocaml , Clojure... maintenant c'est comme un cercle vicieux ,les boites ne peuvent pas ou ne veulent pas remettre en cause l'existant par conséquent de nombreux langages sont considérés comme des lubies pour chercheur .

Scala, de par le fait qu'il se trouve dans le monde du Java, est un poil mentionné et utilisé.
Pour le reste... la logique entrepreneuriale est simple : j'ai un logiciel réalisé dans un langage X. Sa maintenance (corrective et évolutive) me coûte tant. Le logiciel fonctionne bien et les utilisateurs y sont habitués. Que m'apporterait de le réécrire from scratch ? Combien de mois ou d'année cela prendrait-il ? Pourrai-je trouver facilement des personnes pour la maintenance ?

Le compromis assez facile à proposer est donc de continuer avec l'existant, mais de réaliser les nouveautés dans un autre langage, en vérifiant bien que l'interfaçage est simple et réellement fonctionnel.
Ensuite, en prenant des métriques de qualité, il suffit de prouver que le nouveau développement est plus stable, plus simple, plus "ce qu'il faut" pour convaincre l'entreprise.
Oui, ça prend une année ou deux ;)

Perso, je ne connais pas le paradigme fonctionnel, et pour être parfaitement honnête, OCaml ne m'a vraiment pas laissé un bon souvenir, plutôt l'inverse. Vu que c'était en tant que second langage et durant mes études, je passe outre, mais je ne peux m'empêcher d'avoir un à-priori.

En parlant de programmation purement fonctionnelle, que pensez-vous de ce paradigme ? J'ai eu l'occasion d'avoir un cours sur Scala (qui n'est pas purement fonctionnelle mais les principes fonctionnelles sont là) au dernier semestre (par un des créateurs de Scala) et je reste assez perplexe quant aux performances et à la maintenance.

Donc c'est encore et toujours l'argent qui stop le progrès... compréhensible vu le système dans lequel nous nous trouvons, mais je ne peux pas m'empêcher de penser que c'est dommage.

Simple question qui n'a rien avoir :

En C++, utilisez-vous toujours "protected" ou bien faites vous parfois la nuance en utilisant private ?

Utiliser tout le temps protected me semble plus facile, mais peut être y a t-il un inconvénient.

Merci !

Ps : comme inconvénient je pense à la sécurité. J'imagine qu'il y a des cas où on a pas besoin de modifier les attribut d'une classe mère, et donc dans ce cas je pense qu'il vaut mieux les déclarer private

Bah...
Dis-toi simplement que tu as une boîte à faire tourner, que ta famille dépend de toi, ainsi que la famille de tes salariés. Tu es dans une situation stable. Es-tu prête à prendre le risque pour toute ces personnes ?
En somme, l'argent n'est pas le problème réel, c'est plus la prise de risque ainsi que l'utilité.

Si tout fonctionne et que fonctionnellement (pour les utilisateurs), il n'y a aucune différence, il est plus difficile de faire accepter des changements, mais ce n'est pas impossible. Ca va dépendre des entreprises, et il y a plusieurs cordes sur lesquelles jouer. Il faut pouvoir les identifier pour les adresser.

@VampireGirl J'utilise private à peu près uniquement dans le cas où j'ai des accesseurs/mutateurs qui contiennent de la logique et que je ne veux pas laisser un accès direct à certaines propriétés (typiquement quand une modification directe pourrait laisser l'objet dans un état incohérent).

Le 09 janvier 2015 à 13:12:25 Bunyan a écrit :
Bah...
Dis-toi simplement que tu as une boîte à faire tourner, que ta famille dépend de toi, ainsi que la famille de tes salariés. Tu es dans une situation stable. Es-tu prête à prendre le risque pour toute ces personnes ?
En somme, l'argent n'est pas le problème réel, c'est plus la prise de risque ainsi que l'utilité.

Si tout fonctionne et que fonctionnellement (pour les utilisateurs), il n'y a aucune différence, il est plus difficile de faire accepter des changements, mais ce n'est pas impossible. Ca va dépendre des entreprises, et il y a plusieurs cordes sur lesquelles jouer. Il faut pouvoir les identifier pour les adresser.

Oui je comprends bien.

Le 09 janvier 2015 à 18:11:53 vava740 a écrit :
@VampireGirl J'utilise private à peu près uniquement dans le cas où j'ai des accesseurs/mutateurs qui contiennent de la logique et que je ne veux pas laisser un accès direct à certaines propriétés (typiquement quand une modification directe pourrait laisser l'objet dans un état incohérent).

Ok merci !

Je viens de commencer Qt sinon. Je trouve que c'est super clair et très bien organisé, je n'ai pas du tout de mal à me retrouver. A terme, je souhaiterais créer un logiciel de création de pixel art.

Ouais, Qt est un super bon framework je l'utilise aussi, en plus on intègre facilement opengl ou sfml

Le 09 janvier 2015 à 10:58:58 VampireGirl a écrit :
En C++, utilisez-vous toujours "protected" ou bien faites vous parfois la nuance en utilisant private ?

Utiliser tout le temps protected me semble plus facile, mais peut être y a t-il un inconvénient.

Merci !

ça dépend des cas, si ta classe est pas censé être hérité, private est le choix le plus logique, en dehors le cas de protected est pas non prohibé.
La seule chose que personnellement, je me retiens, c'est de mettre les variables membres d'une classe en protected et/ou public, partant dans le principe que la variable n'appartient pas à la classe hérité, du coup, le mec peut probablement faire de la merde avec ta classe et donc, il faut mieux passer par des getter/setters.

Sinon, le principal inconvénient, c'est principalement la lisibilité et la compréhension du code, une fonction/variable membre protected signifie que la classe va être dérivé.

btw, encore une chose qui n'a rien à voir, mais vous avez des références de bouquin pour apprendre à écrire un compilateur ainsi qu'un interpréteur ? (je sais que les deux n'ont rien à voir, d'où la question)

Le 10 janvier 2015 à 19:41:16 kernel[] a écrit :
Ouais, Qt est un super bon framework je l'utilise aussi, en plus on intègre facilement opengl ou sfml

J'adore la documentation aussi, franchement on s'y retrouve facilement.

Le 11 janvier 2015 à 00:43:38 Ace_Attorney a écrit :

Le 09 janvier 2015 à 10:58:58 VampireGirl a écrit :
En C++, utilisez-vous toujours "protected" ou bien faites vous parfois la nuance en utilisant private ?

Utiliser tout le temps protected me semble plus facile, mais peut être y a t-il un inconvénient.

Merci !

ça dépend des cas, si ta classe est pas censé être hérité, private est le choix le plus logique, en dehors le cas de protected est pas non prohibé.
La seule chose que personnellement, je me retiens, c'est de mettre les variables membres d'une classe en protected et/ou public, partant dans le principe que la variable n'appartient pas à la classe hérité, du coup, le mec peut probablement faire de la merde avec ta classe et donc, il faut mieux passer par des getter/setters.

Sinon, le principal inconvénient, c'est principalement la lisibilité et la compréhension du code, une fonction/variable membre protected signifie que la classe va être dérivé.

btw, encore une chose qui n'a rien à voir, mais vous avez des références de bouquin pour apprendre à écrire un compilateur ainsi qu'un interpréteur ? (je sais que les deux n'ont rien à voir, d'où la question)

Ok merci

Le 11 janvier 2015 à 00:43:38 Ace_Attorney a écrit :
btw, encore une chose qui n'a rien à voir, mais vous avez des références de bouquin pour apprendre à écrire un compilateur ainsi qu'un interpréteur ? (je sais que les deux n'ont rien à voir, d'où la question)

La bible dans ce domaine, c'est le Dragon Book. Ça couvre « que la compilation » par contre, mais ça te servira aussi énormément pour un interpréteur, dans la mesure ou tu auras toujours besoin d'(au moins) un lexer et d'un parseur.

Tu as aussi « Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages » qui aborde l'interprétation, en plus de la compilation.

Si ça te dérange pas de lire des centaines de pages sur un écran, ou que tu veux voir plus précisément ce que contiennent ces deux ouvrages, je les ai en PDF (mp).

Salut all,
j'écris un émulateur pour chip 8 en C, et j'ai pas fini d'implémenter tous mes opcodes mais je peux déjà lancer certains ROM et voir des graphiques s'afficher (écran d'affichage de Space Invaders par exemple).
Seulement j'ai un problème de SEGFAULT, y a certaines instructions qui génèrent une segfault et je voudrais connaître des bons moyens de les traquer.

Aussi vu que j'y suis, la stack de la chip8 fait 16 adresses et je me pose la question suivante, qu'est-ce que le cpu est censé faire si on rentre dans un "CALL $0xblabla" et que je push une adresse de retour sur la pile mais que je dépasse la taille ?

SEGFAULT, c'est sûrement un problème de pointeur non alloué ou bien désalloué auquel tu essayes d'accéder. Ton debugger ne t'en informe pas ?

Ace_attorney > en plus des références citées par vava (attention, le Dragon Book c'est plutôt indigeste), tu as d'autres titres sympathiques pour acquérir les bases. "Parsing Techniques : a practical guide" est souvent utilisé en support de cours ; le célébrissime Structure and Interpretation of Computer Programs (SICP du MIT) est un très beau morceau, qui s'attaque aux généralités sur les langages en s'appuyant sur le Scheme ; Types and Programming Language est aussi une bonne référence sur la mise en place de systèmes de types et l'étude de leur fonctionnement.
Tout ça c'est très théorique. En plus pratique, tu as "Writing Compilers and Interpreters : a software engineering approach" qui construit un interpréteur Pascal (il me semble), en Java (l'édition précédente le fait en C++).
Si t'es intéressé par le parsing en langages types C, t'as deux bouquins de référence (relativement moyens, la documentation sur Internet est déjà bien fournie) d'O'Reilly sur Lex & Yacc et Flex & Bison.
Enfin, en plus léger, tu as le pack "Create your own freaking awesome programming language" avec vidéo et code source. C'est moyennement réputé, mais paraît que Coffeescript a été développé grâce à ça donc ça vaut peut-être le coup.
Enfin, les cours de Stanford sur la construction de compilateurs (CS143) ainsi que tous les exercices et devoirs sont disponibles gratuitement sur leur site. Les cours ("lectures") sont plutôt accessibles, et avec les exercices t'as de quoi vérifier ton avancement. À la fin de ce cours, tu auras créé un compilateur bytecode basique sur un langage créé pour l'occasion.

Après c'est plus éloigné des compilateurs/interpréteurs puisque ça touche presque exclusivement aux DSLs internes (mais un peu aussi aux DSLs externes), mais j'ai adoré le livre "DSLs in Action" de Gosh chez Manning. C'est un bouquin excellent sur les bonnes pratiques à avoir lors du design de langages dédiés et de leur interprétation, écrit dans un style extra et couvrant des exemples en 6 langages, avec pas mal de "discussions" sur les décisions prises.

@Ace_Attorney

http://www.buildyourownlisp.com/

Salut
Faudrait refaire la charte du forum parce qu'elle est devenu un peu catastrophique avec l'arrivé de Respawn
https://www.jeuxvideo.com/forums/1-47-26869-1-0-1-0-0.htm