Le topic de la programmation: Et envoyez des sioux!

[newbie06]

Breaking news!

La bible, que dis-je, le Knuth du lancer de rayon, Physically-based rendering, est maintenant disponible sur vos écrans :
http://www.pbr-book.org/
Mieux, le bouquin est entièrement reformaté avec des liens hypertexte, du code dépliable et des images zoomable. Et les auteurs ont promis de le tenir à jour.

Ha chouette ! Pratique pour chercher rapidement.

La présentation est claire et lisible. Mais pour lire je continue de préférer le bon vieux papier.

[brundleti]

Pour bien commencer le weekend, 2 (vieux) xkcd
( trouves
(sur https://twobithistory.org/2018/10/14/lisp.html
(via la wekly news de lwn.net )
)
) :

https://xkcd.com/224/ et https://xkcd.com/297/

Les gens me regardaient bizarrement dans le bus en me voyant rigoler (et encore ils ne savaient pas pourquoi )

[FB74]

[rOut]

Sinon pour ceux qui aiment s'amuser, y'a Exapunks, le dernier Zachtronics qui sort demain : https://store.steampowered.com/app/716490/EXAPUNKS/

Il est déjà en early acces, et je l'ai trouvé très sympa, un peu dans le style TIS-100 niveau paradigme de programmation, mais un peu moins aride et avec quelques puzzles compétitifs qui viennent reposer un peu la tête.

Ça ressemble aussi un peu à 7 Billion Humans niveau parallélisme (que je conseille, ainsi que son prédécesseur Human Resource Machine).

[Mayalabielle]

Sinon pour ceux qui aiment s'amuser, y'a Exapunks, le dernier Zachtronics qui sort demain : https://store.steampowered.com/app/716490/EXAPUNKS/

Il est déjà en early acces, et je l'ai trouvé très sympa, un peu dans le style TIS-100 niveau paradigme de programmation, mais un peu moins aride et avec quelques puzzles compétitifs qui viennent reposer un peu la tête.

Ça ressemble aussi un peu à 7 Billion Humans niveau parallélisme (que je conseille, ainsi que son prédécesseur Human Resource Machine).

Cool je j'ai vu passer sur Steam et je voulais avoir un avis. Merci je vais l'ajouter dans ma liste et attendre une petite promo

[Raplonu]

Salut !

Je suis en train de regarder du coté de la "vectorisation" en C++.

Sur le blog nvidia, on a un article qui explique comment augmenter la bande passante en utilisant des types vectorisés.

Ça donne ça :

reinterpret_cast<int4*>(d_out)[i] = reinterpret_cast<int4*>(d_in)[i];

Avec int4, une simple structure qui possède 4 entiers.

Sauf que d’après la doc sur reinterpret_cast, cette opération ne respecte pas les conditions de type aliasing (lien) et donc semble être dans le domaine de l'UB.

1) On est bien en présence d'un UB ?

2) Si oui, c'est acceptable ?

3) Si oui, on la trace où la ligne entre l'UB acceptable et le non acceptable ?

Ps : J'ai utilisé pendant longtemps ce genre d'astuces (avec des unions aussi), j'ai jamais eu de problème, je suppose que c'est plus une question de philosophie que de potentiel apocalypse.

[Tramb]

Soyons clair : tu fais rien en C++ sans UB
La ligne c'est nécessaire ou non nécessaire.

Perso je recommande d'encapsuler ça dans une fonction qui fait ce cast sale.

[rOut]

Ben le CUDA c'est déjà plus tellement du C++.

Si tu fais du C++ et que tu veux respecter le type aliasing, les possibilités sont:
- appeler std::memcpy pour changer le type, et compter sur le compilo pour l'ellision de l'appel,
- laisser la version non vectorisée, et compter sur le compilo pour l'autovectorisation,
- tout passer en type vectoriel pour ne pas avoir à faire de cast,
- utiliser des intrinsics

Et pour une copie comme là, std::memcpy est sans doute déjà vectorisé, je trouve l'exemple assez naze...

[Raplonu]

Soyons clair : tu fais rien en C++ sans UB
La ligne c'est nécessaire ou non nécessaire.

Autant j'essaye de respecter au mieux le standard, autant là, je vois mal comment faire sans... Donc va pour l'UB

Perso je recommande d'encapsuler ça dans une fonction qui fait ce cast sale.

C'est plus que nécessaire effectivement !

Si tu fais du C++ et que tu veux respecter le type aliasing, les possibilités sont:
- appeler std::memcpy pour changer le type, et compter sur le compilo pour l'ellision de l'appel,
- laisser la version non vectorisée, et compter sur le compilo pour l'autovectorisation,
- tout passer en type vectoriel pour ne pas avoir à faire de cast,
- utiliser des intrinsics

J'ai d'autres cas d'utilisation qu'un simple memcopy, cuda propose effectivement des intrinsics vectoriels assez intéressant.

Et pour une copie comme là, std::memcpy est sans doute déjà vectorisé, je trouve l'exemple assez naze...

C'est coté GPU que l'exemple est pertinent : code

On passe de

ld.global.u32
st.global.u32

à

ld.global.v2.u64
st.global.v2.u64

Tu rajoutes à ça un peu de __restrict__ et ça commence à devenir bourrin

[Møgluglu]

Ben le CUDA c'est déjà plus tellement du C++.

Si si, au moins depuis Volta et CUDA 9, c'est vraiment du C++17 pur jus y compris pour les trucs auxquels personne ne comprend rien comme le multithreading et le modèle de consistance mémoire.

Si tu fais du C++ et que tu veux respecter le type aliasing, les possibilités sont:
- appeler std::memcpy pour changer le type, et compter sur le compilo pour l'ellision de l'appel,
- laisser la version non vectorisée, et compter sur le compilo pour l'autovectorisation,
- tout passer en type vectoriel pour ne pas avoir à faire de cast,
- utiliser des intrinsics

Et pour une copie comme là, std::memcpy est sans doute déjà vectorisé, je trouve l'exemple assez naze...

Je vote généralement pour l'option 3, ne serait-ce que pour intégrer la contrainte d'alignement dans le type. En pratique, l'exception sur accès non aligné est le comportement "undefined" le plus probable. Même si on utilise memcpy ou l'idiome qui va bien pour changer le type du pointeur, ça ne dit pas qu'on obtient un pointeur valide, il y a même 3 chances sur 4 pour qu'il ne le soit pas.

(Cool, godbolt gère le code CUDA maintenant ! On peut lui faire afficher le vrai code assembleur, le SASS ?)

[Raplonu]

On peut lui faire afficher le vrai code assembleur, le SASS ?

https://github.com/mattgodbolt/compi...rer/issues/946

[Tramb]

Je vote généralement pour l'option 3, ne serait-ce que pour intégrer la contrainte d'alignement dans le type. En pratique, l'exception sur accès non aligné est le comportement "undefined" le plus probable. Même si on utilise memcpy ou l'idiome qui va bien pour changer le type du pointeur, ça ne dit pas qu'on obtient un pointeur valide, il y a même 3 chances sur 4 pour qu'il ne le soit pas.

3/4 sur la stack, 1/2 à la sortie de malloc, je dirais
Good odds, ça se tente. Il faut vivre dangereusement.

[FB74]

Bundle Java:
https://www.humblebundle.com/books/java-by-packt-books

[William Vaurien]

Merci pour le lien vers le Bundle !
Je suis resté coincé à Java8 et maintenant que les releases Java vont "vites" je me sens un peu largué, même s'il n'y a pas tant de changements fondamentalement visibles à part les modules de java9.
Je commence à devenir comme mes collègues accros au C89: ne plus trop suivre les évolutions.

En même temps ça devient tendu de trouver la bonne route d'autoformation, entre suivre les évolution du langage, les autres langages (Kotlin, Scala, Groovy pour rester sur la JVM), les évolution des frameworks connus (Spring, Spring Boot, JEE, ...), les frameworks qui ont l'air cool et que je ne connais pas trop avec des façons différentes de voir les choses (Akka, Vertex, ...). Tous les autres que je ne connais pas. Reste encore les technos pour faire du web (angular et consorts, qui demande de se former sur plein d'autres outils pour avoir une chaine de build), et si on est curieux, suivre aussi les évolutions transverses (protocoles, sécurités,...).

Cette indigestion ! Je ne sais plus trop quelle voie prendre !

[Tramb]

Choisis des choses qui te donnent des connaissances durables et pérennes.
Scala pour voir du typage statique de bonne qualité, ou Clojure pour apprendre un Lisp. Les frameworks, c'est vraiment si t'as trop de temps libre.

[FB74]

Un nouveau bundle de livres de programmation:
https://www.humblebundle.com/books/dev-ops-oreilly

C'est particulier.

[TwinBis]

C'est le topic de la programmation ici Monsieur.
Les ops peuvent aller faire leurs saletés ailleurs !

[Nattefrost]

Mais non voyons monsieur, l'Ops c'est bien, mangez-en.

[Paradox]

Mais non voyons monsieur, l'Ops c'est bien, mangez-en.

Enfin, le dev-ops, en gros, c'est juste le developpeur qui a le mot de passe root du serveur de prod', hein.

[vectra]

Coincoin les coucous,

Je perds la boule sur un truc tout con en C++

Soit une classe mère bien triviale:

class myPoint
{
 protected:
  int x, y, z;
  bool tag;
  void set_defaults() {tag = false;}
  
 public:
  myPoint(int a, int b, int c):x(a), y(b), z(c)
  {set_defaults();}
  
  
  void display()
  { cout << x << y << z << tag;}
};

Le seul luxe, c'est une méthode set_defaults qui est invoquée par le constructeur pour factoriser l'initialisation de tous les flags dont j'ai besoin dans la classe réelle.

Quand on passe à l'héritage, ça ne marche plus:

class rePoint: public myPoint
{
 protected:

  // tentative de redéfinition
  void set_defaults() 
   { 
     myPoint::set_defaults();
     myPoint::tag = true; // ce pourquoi j'ai redéfini la méthode dans la classe fille 
     assert(false);  // histoire de matérialiser que la méthode présente n'est jamais appellée 
   }
  
 public:
  rePoint(int a, int b, int c):myPoint(a, b, c){}
  
};

En gros, lors de la délégation de constructeur, c'est le set_defaults() de la mère qui est appelé par le constructeur de la mère. Je constate que je n'ai pas réussi à forcer le constructeur de la mère à utiliser la méthode redéfinie chez la fille.
Voyez-vous un moyen propre de corriger cela sans réécrire tous les constructeurs de la classe fille pour qu'ils appellent la set_defaults() redéfinie ?
Pourriez-vous mettre le doigt sur le concept que j'ai manqué / l'assomption fausse que j'ai faite?

[Raplonu]

Ajoute virtual à ta méthode set_defaults

Tu ne peux pas modifier ou redéfinir une méthode depuis l'extérieur d'une classe (ici depuis la classe hérité). Mettre ta méthode virtuelle va permettre à la classe fille de modifier set_defaults.

Je serai toi, j'encapsulerai les flags et je rajouterai un constructeur protected à la classe mère qui prend ça en paramètre :

struct myflags
{
  bool tag;
}

myflags flagsdefault()
{
  return myflags{true};
}


myflags flagscustom()
{
  return myflags{false};
}

class myPoint
{
 protected:
  int x, y, z;
  myflags tag;
  
  myPoint(int a, int b, int c, myflags tag):x(a), y(b), z(c), tag(tag)
  {}

 public:
  myPoint(int a, int b, int c):myPointx(a, b, c, flagsdefault()) {}
  
  void display()
  { cout << x << y << z << tag;}
};

class rePoint: public myPoint
{
 protected:
  
 public:
  rePoint(int a, int b, int c):myPoint(a, b, c, flagscustom()){}
  
};

[Nattefrost]

Enfin, le dev-ops, en gros, c'est juste le developpeur qui a le mot de passe root du serveur de prod', hein.

En très très gros alors, si c'est comme ça dans ta boîte le gars doit bien se faire chier

[vectra]

Pour moi, virtual était uniquement lié au polymorphisme dans les cas que je connaissais (vecteurs d'éléments de la classe mère). Je m'étais dit que déterminer quelle version de set_defaults() devait être appellée à partir du constructeur de la classe mère ressemblait à du polymorphisme, alors j'ai tenté le coup.
Ca ne fonctionne pas hélas! Il y a peut-être des règles spéciales liées au constructeur?


Sinon, c'est quoi le périmètre du devops exactement?
Un Atlassian, du Jenkins, et ne pas merger sans que les tests d'intégration et unitaires aient réussi?

[Nattefrost]

Ecrire des scripts pour monitorer/provisionner des serveurs/DBs. Grossièrement tout ce qui est utile à automatiser sur une infra.
C'est varié et ça dépend beaucoup de la boîte je pense, mon cas est peut-être particulier parce qu'on est pas nombreux (une douzaine à la technique dev/devops ensemble) et qu'on fait à la fois du cloud et du sur-site chez les clients.

Je vais en oublier mais récemment j'ai écrit du test d'intégration, j'ai bossé sur la mise en place de haute dispo sur postgresql et rabbitmq, je maintiens l'installeur de la solution sur-site (des milliers de lignes de bash ) et enfin j'ai aussi un peu de contact client, il m'arrive de faire des interventions de diagnostic à distance (postgresql et rabbit).

[Cwningen]

Pour moi, virtual était uniquement lié au polymorphisme dans les cas que je connaissais (vecteurs d'éléments de la classe mère). Je m'étais dit que déterminer quelle version de set_defaults() devait être appellée à partir du constructeur de la classe mère ressemblait à du polymorphisme, alors j'ai tenté le coup.
Ca ne fonctionne pas hélas! Il y a peut-être des règles spéciales liées au constructeur?

Quand tu exécutes le constructeur du parent, la partie de la classe dérivée n'est pas encore initialisé (ça inclut la vtable), tu ne peux donc pas appeler des méthodes de la classe dérivée.

Pour la bonne solution, je ne suis pas trop sûr. Un CRTP, peut-être ?

[vectra]

Ah ben c'est parfait, ça explique bien le problème rencontré

[Cwningen]

Maintenant que j'y réfléchi, le CRTP a le même problème pour les constructeurs, puisqu'on cast this avant que l'objet ne soit initialisé. Ça marchera (edit: ou pas, c'est UB ) mais c'est dangereux.

[vectra]

Dans la pratique, la modification de comportement dont j'avais besoin était vraiment minime, et j'ai pu la réaliser très proprement d'une manière complètement différente (et hors du scope du code fourni).
Je voulais surtout comprendre ce que j'avais raté. Merci à vous pour votre temps

Par contre, ça m'a permis de découvrir que c++11 permet "d'hériter" de tous les constructeurs définis dans la classe mère avec:

using myPoint::myPoint;

C++14 et 17 sont en train de devenir mainstream, faudrait que je m'y mette sérieusement aussi

[Raplonu]

Quand tu exécutes le constructeur du parent, la partie de la classe dérivée n'est pas encore initialisé (ça inclut la vtable), tu ne peux donc pas appeler des méthodes de la classe dérivée.

Pour la bonne solution, je ne suis pas trop sûr. Un CRTP, peut-être ?

Ha zut. Je connaissais pas... Mais mon code reste valide (l'honneur est sauf, ouf) !

C++14 et 17 sont en train de devenir mainstream, faudrait que je m'y mette sérieusement aussi

Oui ! Très gros gain expressivité pour peu qu'on ne tombe pas dans les très nombreux "pitfall"

[Paradox]

En très très gros alors, si c'est comme ça dans ta boîte le gars doit bien se faire chier

Meme si tu as l'air d'etre un devops et te fait pas chier, tu devrais prendre le temps de lire ca : https://lionfacelemonface.wordpress....do-it-anymore/