Le topic de la programmation: Et envoyez des sioux!

La suite du topic.

Comme ducon ne voulait pas être le papa du thread, J'en ai hérité.
Tremblez, pauvres fous qui programmez en langages interprétés ou faiblement typés :o


Sinon, le lien vers le premier topic de la programmation (nevar forget):
http://forum.canardpc.com/threads/56...r-et-compagnie


Quelques stickies intéressants sur Git:

• Flight rules for git, un manuel au cas par cas pour vous dépatouiller.

Quelques liens thématiques par questions (ouvert à suggestions / compléments).

• Trouver un bouquin de chevet en C++: ici
  Pour aller plus loin: ici
  
• Discussion sur des libsGUI modernes en C++: ici
  
• Parser des arguments de programme en C:
  
  1. C: getopt_long
  2. C++: boost program_options
• Les noirauds qui whinent sur la vectorisation: ici
• ... et qui partent sur de la programmation FPGA en langage fonctionnel: là
• où l'on découvre les joies du Pair Programming: là
• où l'on comprend que l'AVX512, c'est pas tant la fête sur skylake: là
• où l'on parle de synchros de threads là
  

old titles:

• Le topic de la programmation V2, string, chaînes, cuir et compagnie
• Le topic de la programmation en assembleur ou en shader (sinon c'est trop facile)
• Le topic de la programmation vraiment très générale (monde de merde)
• Le topic de la programmation et des programmateurs de machines à laver
• Le topic de la programmation: de l'Arduino au FPGA, jusqu'où s'arrêteront-ils?
• Le topic de la programmation: le Java c'est moins bien que l'assembleur x86 (dixit un prog java)
• Le topic de la programmation: et si on commençait plutôt par OCaml, Prolog et Lisp?
• Le topic de la programmation: et si on brûlait Charmide pour délit de lèse-x86?
• Le topic de la programmation: Guido, si tu nous lis: Merde
• Le topic de la programmation: Voici et Gala se mèlent de la programmation
• Le topic de la programmation: spectre et meltdown, et si on revenait au 68000?
• Le topic de la programmation et des IDE: Emacs, VI, et les casual-friendly
• Le topic de la programmation: canards contre Coq, certains plus égaux que d'autres
• Le topic de la programmation: stop le dev, la recherche ça paie mieux
• Le topic de la programmation: BSOD sur GitHub après erreur de Windows Update
• Le topic de la programmation: la guerre des IDE comme marronier estival
• Le topic de la programmation: Oui-Oui au pays des IDEs
• Le topic de la programmation: Windev, ze french disease
• Le topic de la programmation: LISP, c'est le bien (et OCaml est un brave type aussi)
• Le topic de la programmation: ou comment troller avec des tableaux
• Le topic de la programmation: Commodore Amiga. Même qu'y avait emacs de fourni.
• Le topic de la programmation: et des Gits à risque
• Le topic de la programmation: libBrain.so.0.0 not found
• Le topic de la programmation: templatez for dummiez
• Le topic de la programmation: not safe for javascript kiddies
• Le topic de la programmation MMA Arena: Atlassian VS Gitlab
• Le topic de la programmation: leave Windows alone!
• Le topic de la programmation: AMOS, Blitz & GFA Basic >> Python
• Le topic de la programmation: retour au Journal du Hard
• Le topic de la programmation: tchoupi découvre Visual
• Le topic de la programmation: enlarge your micro-service
• Le topic de la programmation: codée exit(1) avec ChatGPT

candidates: Le topic de la programmation V2: safe space pour langages interprêtés



Autres topics d'intérêt:
Le topic de l'IA:ici
Plus de détails sur les récentes failles hardware:ici

Bah le thread est là, c'est le principal non ? C'est quoi l'intérêt d'être l'OP ?

Citation:

---

Envoyé par Patate

Bah le thread est là, c'est le principal non ? C'est quoi l'intérêt d'être l'OP ?

---

Ben t'as plus de pouvoir.

Pour changer le titre ^_^

Et faire venir les gens avec un beau premier message.

Je prends! :o

Citation:

---

Envoyé par vectra

Je prends! :o

---

Tu sens la pression là...

Flag. :ninja:

Bon, j'inaugure...

J'ai encore un vieux Core i5 2500K que je n'arrive pas à OC proprement (je n'aime pas ça à la base), avec de la DDR3 1600. Je voudrais le mettre à jour pour un CPU plus récent en gardant en tête les performances pour de la programmation 'type HPC' telle que j'ai pu vous rabattre les oreilles avec à longueur de topic. Soit, OpenMP, bande-passante mémoire, streaming SSE, et programmation scientifique en général.

D'après vous, je peux attendre de belles évolutions de performances avec le Skylake/Kaby Lake? Y aurait-il des modèles abordables sur le marché pour ne pas sacrifier le PEL tout en étant ébloui par l'upgrade?

Réponse courte : non.

Intel a bien segmenté ses gammes.
Soit tu es riche, et tu attends la sortie de Skylake-X pour prendre une config à base de Core i9 voire de Xeon metal et tu auras AVX-512 et 4 canaux mémoire.
Soit tu es un prolo, et tu prends le max de cœurs et de GHz que tu peux avoir pour ton budget, et actuellement c'est plutôt chez AMD que ça se passe.

Mais l'intérêt d'utiliser plein de coeurs si on est limité en BP mémoire?
Ils ont 4 canaux chez AMD?

Si ça peut intéresser du monde, Humble Book Bundle, Data Science:
https://www.humblebundle.com/books/data-science-books

:)

Petite question de cpp. Dans mon projet, je voudrais présenter la déclaration de mes items comme ça pour plus de simplicité dans un fichier constants :

Code:

---

static const std::string ITEM_WEAPON[][7] = {
    {"1", "Dague", "Une dague !", "t", "red", "5", "10"},
    {"2", "Epée", "Une épée !", "t", "red", "7", "15"} 
};

---

Ca peut fonctionner comme ça, mais est-ce qu'il est possible de faire la même chose mais avec différent type quitte à passer pas une struc :

Code:

---

static const std::string ITEM_WEAPON[][7] = {
    {1, "Dague", "Une dague !", "t", TCODColor::red, 5, 10},
    {2, "Epée", "Une épée !", "t", TCODColor::red, 7, 15} 
};

---

En gros, est-ce qu'on peut initialiser un objet de la sorte ?

Oui https://godbolt.org/g/ptLjBf

J'allais faire la même :o
Par contre, un petit size_t pour l'uid (possiblement beaucoup, strictement positif) peut-être?

Tout simplement ! Merci :p

- - - Mise à jour - - -

Citation:

---

Envoyé par vectra

J'allais faire la même :o
Par contre, un petit size_t pour l'uid (possiblement beaucoup, strictement positif) peut-être?

---

Oui possible c'est vrai. Mais est ce que ce genre d'optimisation est valable à ce niveau (petit jeu)

Le typage, c'est pas de l'optimisation. C'est a minima de la sémantique, et a maxima ça permet de ne pas se taper l'overflow, même si je me doute qu'il n'arrivera pas avec un projet étudiant.
En tous cas, côté examinateur, je dirais que ce sont des points vite perdus sur la partie la plus scolaire.

Ok ! Toujours pas testé mais un string au lieu du char* c'est plus cpp non ?

Ben si tu ne comptes pas modifier la chaine de caractères, ce qui semble être le cas, c'est inutile de mettre ça dans une std::string. Le char const* va t'économiser une allocation dynamique.

Bon, après tu as peut être envie d'avoir .size() et compagnie...

Ah yes ! Disons que j'ai pas du tout cette vision de l'optimisation quand je programme. Du moins mes projets n'en demandent pas spécialement. Mais j'essai tout de même de viser un cpp plus moderne.

A mon avis c'est pas encore de l'optimisation, mais plutôt de faire les choses les plus simplement possible. De plus comme disait vectra, ça peut avoir une valeur sémantique :

- std::string, pour les chaines variables
- char const* const, pour les chaines constantes, qui ne changeront jamais de valeur

Je note ! Merci ;)

J'ai commandé le bouquin de Meyers je sens que je vais être largué !
Si vous voulez jeter un œil ou le perdre sur mon projet en cours...

https://github.com/kz-dev/rmush/tree/master/src

D'ailleurs au sujet de size_t c'est au moment de la compilation qu'il definit la taille du type?

Oui, comme tous les types, la taille doit être connu au moment de la compilation. Je ne suis pas sûr de bien comprendre la question.

C'est pas exactement ça. size_t est (grossièrement) défini par les sources qu’utilise ton compilo.
Ce que tu dois retenir est dans la doc :

Citation:

---

typedef /*implementation-defined*/ size_t;
size_t can store the maximum size of a theoretically possible object of any type (including array).

---

Du coup, on en déduit qu'il s'adapte aux OS (32/64 bit).

Citation:

---

Envoyé par Cwningen

Oui, comme tous les types, la taille doit être connu au moment de la compilation. Je ne suis pas sûr de bien comprendre la question.

---

Citation:

---

Envoyé par Raplonu

C'est pas exactement ça. size_t est (grossièrement) défini par les sources qu’utilise ton compilo.
Ce que tu dois retenir est dans la doc :


Du coup, on en déduit qu'il s'adapte aux OS (32/64 bit).

---

Ok merci pour les précisions !

Y'a une formation OpenMP/MPI au CERFACS en Novembre. Je me tâte :unsure:

Sinon, si des gens s'y connaissent en AWS pour des applications distribuées en C++, je prends toute info...

Viens on est bien. :cigare:
Par contre c'est vraiment parallélisme 101, le public habituel c'est les thésards en CFD qui veulent un peu comprendre comment marche le parallélisme des codes qu'ils vont utiliser.

Je suis tout triste, à l'université tous les projets que l'on doit rendre doivent compiler sur g++4.4 :(
Adieux smart pointers ...

Ah, les smart pointers :rolleyes:

Les vrais n'utilisent pas ce mécanisme de faible :cigare:

Sinon je me suis commandé deux bouquins qui ont l'air vraiment bien. Un sur le développement C/Asm pour ARM (récent et introuvable en France, du coup go UK), un autre sur le reverse engineering et entres autres la couche kernel de Windows. :bave: