Informatique

J'ai toujours fais manuellement perso :/ Rajouter le répertoire include, rajouter le répertoire de la lib, ajouter les lib.
Sinon tu as un fichier .vcxproj dans le répertoire du projet qui contient ces informations si ton but c'est d'automatiser le processus. J'ai jamais trouvé de moyen de passer outre cette galère sur windows avec visual (quand on est habitué ça se fait bien)

Bonsoir, voilà mon troisième pseudo

Le 02 décembre 2017 à 22:17:07 TERMlNAT0R a écrit :
Bonsoir, voilà mon troisième pseudo

Il s'est passé quoi cette fois ?

Rien du tout

(ah oui, ça casse le mythe, je sais)

Salut, j'espère que vous vous portez bien, j'ai une petite question : si j'ai un bac stmg et aucune notion en programmation, sur quoi devrai-je me diriger dans mes études supérieures pour faire un métier qui tourne autour des JV? Aurai-je besoin d'une remise à niveau ?

Le 03 décembre 2017 à 11:37:50 HommeSincere a écrit :
Salut, j'espère que vous vous portez bien, j'ai une petite question : si j'ai un bac stmg et aucune notion en programmation, sur quoi devrai-je me diriger dans mes études supérieures pour faire un métier qui tourne autour des JV? Aurai-je besoin d'une remise à niveau ?

Tu peux tenter une licence d'info ou les écoles de Niels genre 42... mais si tu veux développer des JV, il faudra te mettre à la prog (il y a d'autres branches dans le JV pour des métiers plus artistiques)
Le JV est déjà surchargé pour les personnes qualifiées donc surtout prévoit des plans B

Le 02 décembre 2017 à 19:01:54 Godrik a écrit :
J'ai une question sur l'utilisation de visual studio. Je l'ai poste sur le forum de programmatino, mais j'imagine qu'il doit y avoir des gens qui savent par ici. Donc, pub pour mon topic :

https://www.jeuxvideo.com/forums/42-47-54278276-1-0-1-0-package-une-bibliotheque-pour-vs-c-2017.htm#post_892752820

J'ai repondu direct sur le forum programmation

En parlant de 42, ca y est, il y a une réputation de lieu ou les mecs harcelent sexuellement les filles

http://www.lepoint.fr/societe/des-cas-de-harcelement-sexuel-a-l-ecole-42-de-xavier-niel-17-11-2017-2173117_23.php

(ca reste du "journalisme", donc de l'info manipulée a prendre avec des pincettes, ca doit concerner qu'une minorité)

Le 03 décembre 2017 à 16:26:31 Lapintade a écrit :
En parlant de 42, ca y est, il y a une réputation de lieu ou les mecs harcelent sexuellement les filles

http://www.lepoint.fr/societe/des-cas-de-harcelement-sexuel-a-l-ecole-42-de-xavier-niel-17-11-2017-2173117_23.php

(ca reste du "journalisme", donc de l'info manipulée a prendre avec des pincettes, ca doit concerner qu'une minorité)

Oui j'avais vu ça. Pour moi tu peux trouver ce genre de cas dans littéralement toutes les facs, toutes les prépas, tous les DUT et toutes les écoles du monde. Et ce genre de comportement est déjà très répandu au lycée (voir même pire).
Pour trouver des personnes victimes de harcèlement, c'est pas les candidats qui manquent. Suffit de cibler une population A dans un milieu B précis et tu peux faire dire ce que tu veux: "Les A qui sont en B sont victimes de harcèlement" (ce qui sous entends toujours qu'ils le sont plus que la moyenne).
Je me demande si ce biais cognitif a un nom.

A l'ecole, il a des élèves qui ont toujours été "harcelés". Dès qu'ils sont une minorité ca échappe pas (les gros, ceux qui ont des lunettes, ceux qui sont nuls en sport, les étrangers, les roux, ceux qui ont un cheveux sur la langue).
Le pire c'est qu'on l'a tous fait, ou au moins pensé. (En école supérieur, je trouvais "rigolo" qu'un de mes camarade de promo était narcoleptique, alors que c'est une maladie très handicapante.).

bon pis fait dire aussi, elles cherchent un peu les nanas a aller dans une école comme 42.

Quand des gens me disent de sauvegarder des "get" pour optimiser un programme
ET C'EST DU JAVA BORDEL ! DU JAVA ! OPTIMISER DU JAVA ! Pourquoi pas optimiser du python tant qu'on y est
C'est eux qui devraient aller à 42, mais ils vont sortir bac+5 hein
Bon dites moi honnêtement si je me trompe, je veux savoir, si sauvegarder un "get" c'est vraiment une bonne pratique de programmation en Java. Est-ce qu'on en est là ? Au point où il vaut mieux un

class A { B b; C c; void init(){b=c.getB()} ; void foo(){ b.foo(); } }

à un

class A { C c; void foo { c.getB().foo(); } }

C'est pas des choses qui seront optimisées avec 99% de chance en compilation OU qui valent pas le coup d'être optimisée (on parle d'un programme avec des milliers de lignes de codes et une interface graphique) ?

Je sais que sur Android il y a effectivement une latence sur les get de PRIVATE et qu'on préfère A.foo que A.getFoo(), du moins j'avais lu ça il y a quelques temps. Il me semble que java 8 à améliorer des choses en terme de performance
Moi je reste convaincu que donner plus de libertés sur la mémoire serait une bonne chose, du moins sur les cycles de garbage collector

Pour avoir des libertés il y a C#. Mais en terme d'optimisation si A.foo est mieux que A.getFoo() de façon perceptible, le langage a un grave problème. Et même, si on en est à optimiser une application à ce point, c'est très très grave je trouve, on se trompe de langage si on en est à réfléchir les choses à ce niveau.
Je veux bien croire que c'est plus lent (je sais que selon les compilateurs de C++ ils peuvent optimiser ça seul ou s'aider d'un "inline" ou je sais plus quoi), mais ça ne sera jamais perceptible et ça ne sera jamais le bottleneck des perf d'une app sinon c'est grave

On devices without a JIT, caching field accesses is about 20% faster than repeatedly accessing the field. With a JIT, field access costs about the same as local access, so this isn't a worthwhile optimization unless you feel it makes your code easier to read. (This is true of final, static, and static final fields too.)

https://developer.android.com/training/articles/perf-tips.html

Je vais pas te cacher que je sais pas exactement ce que ça veut dire (si t'as compris et que tu peux m'expliquer je suis preneur) mais un truc qui pompe pas mal les perfs avec java c'est la création d'objet, bon je sais pas trop la gueule de ta méthode get mais effectivement si elle créé un nouvel objet à chaque appel vaut mieux stocker l'objet quelque part plutôt que de le jeter après ne l'avoir utilisé qu'une seule fois. Ils en parlent tout au début du lien que j'ai donné.

EDIT: Mais sinon oui tout ça c'est des micro-optimisations, ça peut être utile sur des machines assez faibles comme les téléphones (et encore faut que ce soit sur du code exécuté assez souvent quand même) mais sur un PC ça doit pas être perceptible j'imagine.

Le JIT ça permet de compiler à la volée du code me semble t il
Ca signifierai que sans le JIT, c'est plus rapide de A.foo que A.getFoo() ?

Après c'est intéressant le lien, il y a plein de micro optimisations sympa
Même si le coup du one plus rapide que zero, ça me perturbe un peu :
public void zero() { int sum = 0; for (int i = 0; i < mArray.length; ++i) { sum += mArray[i].mSplat; } } public void one() { int sum = 0; Foo[] localArray = mArray; int len = localArray.length; for (int i = 0; i < len; ++i) { sum += localArray[i].mSplat; } }

PS : Désolé, le <code></code> fonctionne pas

Shana Faut mettre un saut de ligne avant le premier <code>

loki Un getter ne crée pas d'objet en théorie, il récupère juste la valeur d'un objet déjà créé pour l'exposer publiquement.

Mais je me suis renseigné et non ça n'a aucun impact. On aurait pas inventé la programmation orientée objet si on en était à ce niveau d'optimisation. Il y a une différence entre travailler sur un moteur de fusée en 1975 et une application avec GUI aujourd'hui.
Vous me parlez d'Android et je comprends bien les contraintes qu'il y a à travailler sur des téléphones (il y a 5~10ans), mais l'application dont je parle est sur PC.

Ce que dit ce que tu as cité loki, c'est que JIT optimise le code. En gros, sans JIT ton "getter" rend les choses 20% plus lentes PAR RAPPORT au cout INSIGNIFIANT d'un get. Ce qui comme j'ai dis est surement fondamental quand tu travailles sur des moteurs de fusée (en java, la blague), mais sur une application graphique un simple clique sur un bouton crée 500 appels donc c'est pas UN appel qui, comme j'ai dis, sera critique.

Pour ton code je sais pas trop Shana, c'est prouvé que c'est plus rapide ?
En Java peut-être vu que c'est n'importe quoi, mais en C++ je pense pas.. Il y a pas d'appel à des fonctions donc je vois pas pourquoi l'un serait plus rapide que l'autre sur la somme.
Apparemment c'est parce qu'il y a un coût à aller voir dans les variables d'une classes... je comprends tellement pas comment fonctionne java

Je sais ce que c'est JIT, ma question c'était plutôt qu'est ce que c'est qu'un "caching field" et la différence entre "field access" et "local access" en fait. Et de ce que j'ai compris local access c'est genre les variables propre à une fonction, et field access ça serait plutôt des variables membre d'une classe. Donc si j'ai bien compris le paragraphe parle juste entre accéder de manière répété à une variable membre d'un objet dans une fonction, et qu'il vaudrait mieux la stocker en tant que variable local de cette fonction, donc au final c'est pas comparable à ton problème de base whiteapplex parce que toi tu stock ton objet dans une variable membre d'une classe, et dans une variable local d'une fonction.

EDIT: Et donc ça expliquerait pourquoi one() est plus rapide que zero(), parce que c'est plus rapide d'accéder à des variables local de fonctions qu'à des variables membre de classes.

EDIT 2: Et donc ce que j'ai cité ça parle pas du tout de fonctions getters ni rien, juste pour préciser.

Le 04 décembre 2017 à 16:48:48 whiteapplex a écrit :
Pour ton code je sais pas trop Shana, c'est prouvé que c'est plus rapide ?
En Java peut-être vu que c'est n'importe quoi, mais en C++ je pense pas.. Il y a pas d'appel à des fonctions donc je vois pas pourquoi l'un serait plus rapide que l'autre sur la somme.
Apparemment c'est parce qu'il y a un coût à aller voir dans les variables d'une classes... je comprends tellement pas comment fonctionne java

Par rapport au lien de Loki, mais c'est Android specific me semble

Le 04 décembre 2017 à 16:55:57 lokilok a écrit :
Je sais ce que c'est JIT, ma question c'était plutôt qu'est ce que c'est qu'un "caching field" et la différence entre "field access" et "local access" en fait. Et de ce que j'ai compris local access c'est genre les variables propre à une fonction, et field access ça serait plutôt des variables membre d'une classe. Donc si j'ai bien compris le paragraphe parle juste entre accéder de manière répété à une variable membre d'un objet dans une fonction, et qu'il vaudrait mieux la stocker en tant que variable local de cette fonction, donc au final c'est pas comparable à ton problème de base whiteapplex parce que toi tu stock ton objet dans une variable membre d'une classe, et dans une variable local d'une fonction.

EDIT: Et donc ça expliquerait pourquoi one() est plus rapide que zero(), parce que c'est plus rapide d'accéder à des variables local de fonctions qu'à des variables membre de classes.

EDIT 2: Et donc ce que j'ai cité ça parle pas du tout de fonctions getters ni rien, juste pour préciser.

Ah ouaip', effectivement

Autre question par rapport à ça (presque), est ce que c'est spécifique à java sur android, ou alors tous les langages portés sur android ont ces "soucis" de perfs ?
Car les nombres flottants je pense que c'est pas spécifique uniquement à java sur Android, mais pour toutes les micros optimisations types variables locales etc, je me demande si le C# / C++ porté sur Android a ces mêmes lacunes

Bah ça dépend juste de comment c'est exécuté, là c'est lié à la JVM donc si ton programme est exécuté autrement ça sera différent.

Après cette histoire de variable local tout ça c'est plus d'actualité, JIT a été ajouté dans Android 2.2 visiblement et d'après les stats de Google 100% des appareils Android sont sous 4.0 minimum, donc bon même si c'est 100% arrondi à 0.05% près je crois on peut oublier cette époque. Et puis même comme l'a dit whiteapplex c'est des micro-optimisations inutiles maintenant, j'imagine que ça a été écrit il y a plus de 5 ans donc maintenant les téléphones même s'ils restent peu puissant par rapport aux PC ont plus besoin de ce genre d'optimisations j'imagine.