C’est autorisé les crochets sur un pointeur, ça vient du C.
 
Je crois qu’il existe une différence mineure entre le type pointeur et le type tableau, mais c’est une question d’interview, donc je me souviens plus.

Ca vient d'une convention du C, qui est que le nom d'un tableau est l'adresse du premier élément du tableau.
En C, un tableau, c'est une adresse et une longueur. Quand tu fais une allocation avec malloc (ou new en C++), l'allocateur regarde s'il lui reste un espace qui n'a pas été réservé, de longueur suffisante, et retourne un pointeur portant l'adresse du premier élément qui vient d'être réservé.
Imagine que ta mémoire est un hotel. L'allocateur, c'est le réceptionniste, il sait à tout moment quelles chambres sont réservées. Mr Jubi, vous demandez 12 chambres consécutives ? Alors allez à l'étage 7, et vous avez les chambres 708 et les 12 suivantes (708-719 inclus).
 
Chambre *chambre = new Chambre[12]              // pointeur qui contient l'adresse 708
 
Tu noteras que C++ n'offre aucun mécanisme qui t'empêche d'écrire à l'adresse 720. Cet hotel n'a pas de clefs, tu peux entrer dans n'importe quelle chambre à tout moment, même si elle est déjà occupée (en général ça se passe mal si elle est occupée, mais ça peut marcher si elle ne l'est pas, jusqu'à ce que l'allocateur, ne sachant pas que tu squattes régulièrement la chambre, la réserve pour un autre client). C'est à toi de te souvenir que tu as réservé les chambres 708 à 719.
 
Plus de détails https://www.geeksforgeeks.org/diffe [...] r-array-c/

Bon c'est absolument dégueulasse, mais oui ca marche (il manquait l'allocation de tableau dans le code précédent, ça aurait segfault sur l'accès).
 
C'est un horrible mélange de C (tableau utilisé via un pointer) et de C++ (list<int> ).
 
En C, un pointeur et une liste c'est "pareil", donc ce qui ressemble à un pointeur vers une list<int> ici est en fait utilisé comme tableau de list<int> (C-style), donc list<list<int>> ; cf l'allocateur qui est un allocateur de tableau (new[]).
 
Suffit de remplacer ca par un list<list<int>> et tout devient plus clair (et accessoirement, ça enleve le code du ctor et du dtor)

vector<list<int>>
 
Voire array<list<T>, N> et on met tout ça dans un patron.
 
Et effectivement l'implémentation fournie fuite, il manque un destructeur.

J’ai du mal à voir le pourquoi une liste aussi. On push_back et on itère, vector fait ça très bien non?

Merci pour l'explication!
[quotemsg=2352749,931200,25001]
Il y a un dtor, il segfault du coup je l'ai viré pour que ça s'execute

J’ai du mal à voir le pourquoi une liste aussi. On push_back et on itère, vector fait ça très bien non?

j'imagine que c'est parce que ça s'appelle une adjacency list...mais sinon je suis d'accord avec toi

 
Faut utiliser le dtor de tableau (delete[]) si tu utilises le ctor de tableau (new[]).Mais en vrai, il faut utiliser aucun des 2.  
std::list ou std::vector s'occupera de la mémoire pour toi.

 
Oh le noob !

 
Faut utiliser le dtor de tableau (delete[]) si tu utilises le ctor de tableau (new[]).Mais en vrai, il faut utiliser aucun des 2.  
std::list ou std::vector s'occupera de la mémoire pour toi.

La liste c'est pour permettre d'enlever des noeuds du graphe de façon triviale.

C’est pas implémenté fait er de toute manière faut passer dans toutes les listes pour aller trouver les noeuds & les enlever, tu gagnes vraiment rien.  
 
Un set à la limite j’aurais pu voir l’intérêt mais là on s’en tape, t’as 2 pointeurs d’overhead et une allocation par push pour rien.

C'est une question d'exprimer ce qu'on attend de la structure utilisée : On veut pouvoir ajouter et supprimer des noeuds facilement, on ne veut pas d'accès arbitraire que fournit un set. C'est vraisemblablement pas optimal, mais c'est ce qui exprime le mieux le besoin.

D'ailleurs il n'y a pas que la suppression des arêtes qui est un problème: avec un vector, si on en ajoute on invalide tous les itérateurs qu'on avait déjà, alors qu'une liste garantit la validité de tous les itérateurs qui ne sont pas supprimés.

 
ça tendrait à confirmer que leur code a jamais compilé

Ah si si, delete adjacencyList; compile parfaitement. Ca fuit mais ça compile impec.
 
Bienvenue dans le vieux C++.

edit: ah par vieux C++ tu veux parler de la déclaration de tableaux plutôt qu'utiliser un std::vector, j'imagine.

ce langage d'élites de suicidaires de pervers. Une simple liste chainée peut te tuer de 17 manières différentes.

1) j'écris un objet qui prend un stream dans le constructeur et qui expose une function async readChunk(length) qui retourne toujours un buffer de la bonne taille ou lance une exception. https://github.com/vatesfr/xen-orch [...] -buffer.js  
 
2) je sais pas trop, c'est toujours chiant les connecteurs inconnus, il faut trouver la spec de la carte.
https://en.wikipedia.org/wiki/JST_connector on dirait vaguement un JST SZ
 
edit: trouver le pitch exact serait un bon indicateur, ça peut être 1mm, 1.27mm ou 1.5mm

ce langage d'élites de suicidaires. Une simple liste chainée peut te tuer de 17 manières différentes.

Je viens de vérifier sur http://cpp.sh/, même en C++14, tous warnings activés, ça passe les doigts dans le nez.
D'ailleurs, je ne comprends pas ce que qui empêche le compilateur de détecter ce type d'erreur. Je veux dire il suffit de voir que la variable a été déclarée comme un tableau.  
 
  int *arr = new int[10];  <-- manifestement un tableau
  delete arr;  <-- donc erreur
 
edit: ah par vieux C++ tu veux parler de la déclaration de tableaux plutôt qu'utiliser un std::vector, j'imagine.

ce langage d'élites de suicidaires. Une simple liste chainée peut te tuer de 17 manières différentes.

Le pointeur peut venir de n'importe ou, c'est pas aussi évident.

Pas vraiment en C++ moderne. Et t'évites aussi la billion dollar mistake, soit mieux que la plupart des langages mainstreams.

Sinon, je viens de lire la page wikipedia sur les virus bactériophages.
 
Ce truc qui vient de l'espace.
 
On va tous mourir.

Un set c’est pas un accès arbitraire, et ça me semble exprimer beaucoup mieux les arêtes qu’une liste: pas d’ordre et ajout / suppression en O(1) (ou logn avec un arbre). Une liste ça exprime un contrat dont on se contrefout (une séquence / un rank).

Non. Tous les smart pointers sont « nullables » (y compris std::optional) et les deref’ est UB (pas une NPE propre). Le seul truc pas nullable c’est les références, donc c’est assez limité.

Surtout que si t’es références ne sont pas nullables, elles peuvent être « dangling », et c’est aussi UB.

Et il en faut pas des masses pour faire du ref laundering. Genre une fonction qui prend une ref et la renvoie, tu sors ta ref d’une locale ou d’un pointeur pour appeler et tu renvoies le résultat, t’es dedans, aucun warning de clang ou GCC en activant tout.

C’est plus l’inverse, les phages c’est un super espoir.  
 
Le truc ultra flippant de sa race c’est les prions.

Moi en lisant vos commentaires
 
https://buzzly.fr/uploads/thumb/960/phpfrnEEN.gif

Bof la séquence c'est une limitation du contrat de la liste, c'est pas franchement une feature. Ce qu'apporte la liste c'est surtout l'insertion/suppression en O(1) ce que ne fournit pas le set de base.

unordered_set serait éventuellement approprié mais force à fournir une fonction de hash, donc la limitation de list rend son utilisation plus flexible.

Effectivement, le optional nullable c'est un probleme (le meme qu'en Java).
 
Pour les autres cas que tu cites, justement je trouve que c'est très facilement identifiable dans une MR (typiquement récupérer une ref d'un retour de function, énorme warning), et honnêtement en 2 ans de C++ je pense avoir jamais eu de cas de ref dangling au runtime.

ouais en fait je faisais du clickbait    
Mais ça reste super chelou, ces trucs. En plus il y en a absolument partout apparemment.
 
m'en vais me renseigner sur les prions
 
bon okay

ce langage d'élites de suicidaires. Une simple liste chainée peut te tuer de 17 manières différentes.

C'est vraiment pas sorcier, c'est juste une question de lire les différents conteneurs de la bibliothèque standard: https://en.cppreference.com/w/cpp/container
 
C'est assez instructif parce que cette bibliothèque a été construite bottom-up : partant de différentes structures de données connues et utiles, on a défini des conteneurs qui en avaient les propriétés. Le jeu c'est de lire chaque définition et de trouver quelle structure de données correspond.

Si c’est spécifiquement un besoin sur, mais c’est peu probable, et l’intérêt de payer une DLL pour un truc pas utile est léger.

dites les gens qui bossent chez google, pourquoi dans les descentes de gradient qu'on trouve sur le net le learning rate est joué au dés, alors qu'il existe un calcul pour le trouver précisément:
https://youtu.be/RYKyhUglVZA?t=783

Les itérateurs qui restent valides après insertion/suppression c'est quand-même assez pratique, c'est pas non plus le mouton à 5 pattes hyper rare le cas dont parle Hephaestos ^^