Le topic de la programmation, string, chaînes, cuir et compagnie

[rOut]

Ca dépend si t'es en row-major ou en column-major

En tout cas là c'est un tableau de 2 tableaux de 3 ints.
Le premier [] s'applique sur le tableau externe (celui de 2 éléments).

En tout cas personnellement pour ce genre de cas de figure j'ai créé une petite classe toute bête qui s'accède via l'opérateur () et qui s'occupe aussi des éventuels redimensionnements.

Pour le coup c'est là que c'est inversé. Dans ta définition la dimension interne (3) apparaît en premier, puis la dimension externe (2), alors que lors de l'accès c'est comme pour les tableaux [][], la dimension interne vient en dernier.

[vectra]

Pitite question avec std::array. Il contrôle les indices à chaque accès?
Pour du traitement d'images, ca rajoute pas un surcoût tous ces tests?

[Tomaka17]

C'est le même principe que std::vector.
Si tu fais "tableau.at(indice)" ça vérifie et ça te balance une exception si c'est en dehors.
Si tu fais "tableau[indice]" ça vérifie pas, mais il y a vraisemblablement un assert qui traîne.

[Møgluglu]

Par exemple si tu veux une matrice de 2 lignes par 3 colonnes, tu vas faire : int matrix[2][3] = {{1,2,3}, {4,5,6}};

Le type de matrix sera int (*)[3], c'est à dire un pointeur vers des groupes de 3 entiers consécutifs.
matrix[n] équivaut à *(matrix + n) qui équivaut donc à déréférencer ce type, c'est donc de type "3 entiers consécutifs", ou autrement dit int[3].
Ce qui correspond à une ligne de la matrice.

Pour avoir accès à l'élément situé dans la colonne y de la ligne x, tu fais donc pour obtenir la ligne x : matrix[x]
Puis pour obtenir l'élément dans la colonne y de cette ligne : matrix[x][y]
La ligne est toujours en premier, puis la colonne.

Mais... Vil anglo-saxon ! Fortraniste ! C'est le contraire, on écrit toujours matrix[y][x] pour accéder au x-ième élément (colonne) de la ligne y.
Oui, je sais que ça revient au même, mais on a été conditionnés pour mettre l'axe des x horizontalement et l'axe des y verticalement, et appeler "colonnes" les trucs verticaux et "lignes" les trucs horizontaux. Sinon j'aimerais pas être celui qui va devoir relire le code…

Dans tous les cas, on s'en branle puisque personne n'a défini de quelle manière les entiers devaient être considérés. Tu peux très bien dire que int matrix[3][2] = {{1,4},{2,5},{3,6}};
Est une matrice de 2 lignes et 3 colonnes, mais stockée en column-major order. Et ensuite, faire matrix[y][x] pour accéder à l'élément de la x-ème ligne, y-ème colonne.

Oui mais ça c'est l'ordre conventionnel column-major. On a bien déclaré int matrix[Y][X] et on y accède par matrix[y][x], je vois toujours pas ce qu'il y a d'inversé là-dedans. Pour les std::array, d'accord.

[rOut]

Mais... Vil anglo-saxon ! Fortraniste ! C'est le contraire, on écrit toujours matrix[y][x] pour accéder au x-ième élément (colonne) de la ligne y.
Oui, je sais que ça revient au même, mais on a été conditionnés pour mettre l'axe des x horizontalement et l'axe des y verticalement, et appeler "colonnes" les trucs verticaux et "lignes" les trucs horizontaux. Sinon j'aimerais pas être celui qui va devoir relire le code…



Oui mais ça c'est l'ordre conventionnel column-major. On a bien déclaré int matrix[Y][X] et on y accède par matrix[y][x], je vois toujours pas ce qu'il y a d'inversé là-dedans. Pour les std::array, d'accord.

Bin non, je disais justement que ça ne l'était pas.

---------- Post added at 11h04 ---------- Previous post was at 11h01 ----------

C'est toi qui est à l'envers sinon... en mathématiques les coordonnées d'un vecteur commencent bien à x, puis y, puis z... Quand tu fais matrix[x][y] pour moi ça correspond à matrix[x,y]

[Tomaka17]

Quand tu fais "matrix[x][y]" ou "matrix(x,y)", ça veut dire la ligne x et la colonne y ? Ou bien l'élément d'offset x et d'ordonnée y ?
Parce que quand tu écris en maths "M(4,1)", ça correspond au nombre en bas à gauche, ce qui n'est pas du tout la même chose qu'un vecteur (4,1).

---------- Post added at 11h21 ---------- Previous post was at 11h08 ----------

La morale de l'histoire c'est : ne pas faire correspondre accès au tableau et coordonnées dans la matrice, sinon on s'en sort pas.

On créé un objet "Matrix" qu'on peut utiliser soit comme "Matrix<RowMajor>" soit "Matrix<ColMajor>".
En fonction de ce paramètre template on accède différemment aux données (qui sont un simple tableau 1D), et pour les paramètres de l'opérateur() on garde forcément le système utilisé par les maths.
Comme ça, aucune confusion possible.

[Møgluglu]

C'est toi qui est à l'envers sinon... en mathématiques les coordonnées d'un vecteur commencent bien à x, puis y, puis z... Quand tu fais matrix[x][y] pour moi ça correspond à matrix[x,y]

Non c'est toi.
Et puis d'abord j'écris jamais matrix[x][y], toujours matrix[y][x], et je fais des boucles for(y) for(x). (Ou for(i) for(j) matrix[i][j] à la limite.)
Parce que quand je veux ajouter une dimension, c'est généralement une dimension externe. Et si je veux appeler une sous-fonction sur un vecteur de la matrice, j'indexerai le vecteur par x dans la sous-fonction, et si les noms d'indices sont les mêmes que dans la matrice c'est mieux.
Ça correspond bien à matrix(x, y) en Fortran.

Tomaka: assez d'accord, le layout en mémoire de la matrice est à choisir dans la phase d'optimisation en fonction de l'ordre des accès, donc on abstrait tout ça pour pouvoir changer au dernier moment.

(Après, ça devient vite pénible avec des proxies partout quand tu veux récupérer une colonne d'une matrice en column-major ou vice-versa.)

[rOut]

Et puis d'abord j'écris jamais matrix[x][y], toujours matrix[y][x], et je fais des boucles for(y) for(x). (Ou for(i) for(j) matrix[i][j] à la limite.)

T'es pas cohérent, y > x mais i < j.

[vectra]

C'est le même principe que std::vector.
Si tu fais "tableau.at(indice)" ça vérifie et ça te balance une exception si c'est en dehors.
Si tu fais "tableau[indice]" ça vérifie pas, mais il y a vraisemblablement un assert qui traîne.

Tant qu'on parle du assert, j'ai pris la méprisable habitude de faire tous mes tests de 'consistency' avec assert. Je compile jamais avec -D NDEBUG, mais c'est pas une raison.
J'en déduis que assert n'est pas adapté aux tests de cohérence (typiquement, pour une fonction de découpe d'image, vérifier que la fenêtre ne sorte pas de l'image).

Devrais-je réécrire vectra_assert à partir de ce genre de code, ou bien existe-t-il déjà quelque chose d'un peu normalisé?

# define ASSERT(condition, message) \
    do { \
        if (! (condition)) { \
            std::cerr << "Assertion `" #condition "` failed in " << __FILE__ \
                      << " line " << __LINE__ << ": " << message << std::endl; \
            std::exit(EXIT_FAILURE); \
        } \
    } while (false)

[rOut]

Balance une exception.

[Tomaka17]

Ca ?

if (!condition)
    throw std::logic_error("Ach! Große malheur");

EDIT : grillé, ça m'apprendra à laisser l'onglet ouvert 15mn sans refresh

[vectra]

Oui, en effet!

[newbie06]

Les exceptions... Le truc qui pollue la stack et les caches même quand on l'utilise pas. Mort aux exceptions !

[rOut]

C'est faux.

[Møgluglu]

Les exceptions, c'est la merde à gérer sur tout un tas d'architectures (out-of-order, SIMD…) Donc ça nous permet d'écrire des papiers. Vivent les exceptions !

[rOut]

Non mais en quoi c'est différent d'un return ?

---------- Post added at 15h51 ---------- Previous post was at 15h24 ----------

Un peu de bon sens au sujet des exceptions : http://www.boost.org/community/error_handling.html

[Tomaka17]

À noter que depuis le C++11, on peut écrire des trucs comme ça :

void logException(std::exception_ptr exception) {
	try {
		std::rethrow_exception(exception);

	} catch(const std::system_error& e) {
		writeToLog("[exception] Detected std::system_error with error code: " + e.code().message());
		writeToLog("[exception] Message: " + std::string(e.what()));

	} catch(const std::exception& e) {
		writeToLog("[exception] Detected std::exception of type " + std::string(typeid(e).name()));
		writeToLog("[exception] Message: " + std::string(e.what()));

	} catch(...) {
		writeToLog("[exception] Detected exception of unknown type");
	}
}


// exemple d'utilisation :
try {
    foo();
} catch(...) {
    logException(std::current_exception());
    throw;
}

Personnellement je mets un "try { } catch(...) { logException(std::current_exception()); throw; }" dans le main() et à chaque fois que je créé un thread.
Ca peut aussi servir par exemple dans le thread qui gère les messages clavier-souris. Si le message déclenche un callback et que ce callback déclenche une exception, j'ai pas envie que mon programme se std::terminate à cause d'une unhandled exception dans un thread.

[Møgluglu]

Une fonction avec plusieurs return, c'est mal aussi, hein.
Les exceptions logicielles, c'est effectivement un peu pareil. Sauf qu'avec des return tu es sûr que quoi qu'il se passe à l'intérieur de la fonction, tu vas finir par retourner un jour à l'instruction suivant l'appel. Ce qui est assez pratique pour compiler les fonctions indépendamment.

Si je dis pas de connerie, avec des exceptions on se retrouve avec des sauts entre fonctions différentes, et il n'est plus possible de tout analyser avec juste le control-flow graph de chaque fonction.

[ducon]

Au cas où, chez les matheux, dans les matrices, a_ij désigne l’élément de la i-ième ligne et de la j-ième colonne.

[rOut]

Une fonction avec plusieurs return, c'est mal aussi, hein.
Les exceptions logicielles, c'est effectivement un peu pareil. Sauf qu'avec des return tu es sûr que quoi qu'il se passe à l'intérieur de la fonction, tu vas finir par retourner un jour à l'instruction suivant l'appel. Ce qui est assez pratique pour compiler les fonctions indépendamment.

Si je dis pas de connerie, avec des exceptions on se retrouve avec des sauts entre fonctions différentes, et il n'est plus possible de tout analyser avec juste le control-flow graph de chaque fonction.

if((status = foo(coucou)) == STATUS_OK) {
  if((status = bar(coucou)) == STATUS_OK) {
    if((status = boo(coucou)) == STATUS_OK) {
      if((status = baa(coucou)) == STATUS_OK) {
        if((status = coin(coucou)) == STATUS_OK) {
          coucou += 1;
          status = STATUS_OK;
        }
      }
    }
  }
}

return status;

Nice.

---------- Post added at 16h33 ---------- Previous post was at 16h29 ----------

Pour les exceptions, le compilateur sait pertinemment ou se trouve le chemin des exceptions (indiqué explicitement par les throw et les try / catch clauses) et ou se trouve le code "normal".

[newbie06]

if((status = foo(coucou)) == STATUS_OK) {
  if((status = bar(coucou)) == STATUS_OK) {
    if((status = boo(coucou)) == STATUS_OK) {
      if((status = baa(coucou)) == STATUS_OK) {
        if((status = coin(coucou)) == STATUS_OK) {
          coucou += 1;
          status = STATUS_OK;
        }
      }
    }
  }
}

return status;

Nice.

J'espère juste que tu as fait exprès de l'écrire comme ça parce que c'est de la mauvaise foi hein ?

---------- Post added at 16h37 ---------- Previous post was at 16h36 ----------

Pour les exceptions, le compilateur sait pertinemment ou se trouve le chemin des exceptions (indiqué explicitement par les throw et les try / catch clauses) et ou se trouve le code "normal".

Non, il ne le sait pas à cause de la modularité.

[rOut]

C'est à dire ?

[newbie06]

Ton catch peut être n'importe où y compris dans du code déjà compilé. Donc il te faut un mécanisme pour remonter jusqu'au bon endroit et c'est pas simple.

Pour le reste, je te laisse chercher sur Google quelles sont les techniques utilisées pour la compilation des exceptions en C++, ou en général. C'est la merde. gcc -fno-exception c'est le bien

http://www.tantalon.com/pete/cppopt/design.htm

Exceptions are a great way to deal with unexpected errors. But they're expensive. Scott Meyers notes that throwing an exception is about "three orders of magnitude slower" than a normal return. Programs using exceptions are about "5-10% larger and 5-10% slower."

[Møgluglu]

Ton catch peut être n'importe où y compris dans du code déjà compilé. Donc il te faut un mécanisme pour remonter jusqu'au bon endroit et c'est pas simple.

Et ça c'est dans le cas facile où on compile bêtement un code C++ séquentiel en un code machine séquentiel sans trop optimiser.
Maintenant, si tu veux paralléliser ou vectoriser ou offloader sur un accélérateur…

[Tomaka17]

Déjà c'est faux qu'un programme compilé en 2012 avec exceptions activées est plus lent en soi (évidemment si me choppez un article qui date de la guerre, c'est vrai qu'au début c'était plus lent). Plus gros en taille oui, plus lent non. Ensuite c'est juste débile de dire que throw une exception c'est lent.

Les exceptions ce sont des erreurs, c'est pour indiquer des "exceptions" au déroulement normal du programme comme leur nom l'indique. Si vous faites un throw chaque seconde c'est qu'il y a un problème dans votre code. Même si vous faites un throw toutes les 30 secondes c'est qu'il y a un problème dans votre code.

[TiNitro]

Euh, les coin-coins, je rentre du boulot je prends le sujet en cours de route mais 2 points qui viennent à l'esprit là:

1. std::array est semble-t-il en voix d'obsolescence, je voulais utiliser dernièrement et j'étais tombé sur un article annonçant ça... Quelqu’un en sait plus ?
2. Il y a une raison d'allouer un tableau de tableaux: le cas de très grosses matrices, en particulier en architecture 32 bits ou on peut avoir un fail sur l'allocation
3. comment vous vous prenez la tête sur vos histoires de lignes et de colonnes... si t'as envie d'appeler ta 1èere dimension linge ou colonne, tu fais comme tu le sens. Si t'as envie d'appeler ta variable index sur la 1èere dimension x ou y, ben c'est comme tu veux
4. D'accord avec rOut sur les exceptions. Ça permet juste d'écrire du code lisible en réduisant le nombre de lignes de détection d'erreur et en évitant de les mettre en plein milieux. Et d'accord avec Tomaka, je doute que les conséquences soient à ce point dramatique sur les performances; ajoutons que le mot-clé noexcept permet d'indiquer au compilateur qu'il n'y a pas d'exceptions à gérer sur une méthode et donc à optimiser.

[Tomaka17]

Faut me sortir l'article qui annonce ça. C'est tout le contraire même, ça vient d'être ajouté au C++11 et c'est exactement comme les tableaux natifs du langage mais en mieux.
Peut être que l'article conseillait std::vector plutôt que std::array, ce qui est un bon conseil la plupart du temps.

[alecool]

std::array est semble-t-il en voix d'obsolescence, je voulais utiliser dernièrement et j'étais tombé sur un article annonçant ça... Quelqu’un en sait plus ?

Tu confonds avec valarray non? J'avais lu le même genre de critique.

[newbie06]

Déjà c'est faux qu'un programme compilé en 2012 avec exceptions activées est plus lent en soi (évidemment si me choppez un article qui date de la guerre, c'est vrai qu'au début c'était plus lent). Plus gros en taille oui, plus lent non. Ensuite c'est juste débile de dire que throw une exception c'est lent.

Les exceptions ce sont des erreurs, c'est pour indiquer des "exceptions" au déroulement normal du programme comme leur nom l'indique. Si vous faites un throw chaque seconde c'est qu'il y a un problème dans votre code. Même si vous faites un throw toutes les 30 secondes c'est qu'il y a un problème dans votre code.

On t'a expliqué que ça impactait le code *généré*, ça n'a rien à voir avec la fréquence à laquelle tu balances tes exceptions. S'il peut y avoir des exceptions, le code est impacté qu'il y en ait ou pas, point barre, qu'on soit en 2012 ou en 1985 n'y change RIEN. Maintenant tu peux nier l'évidence.

Je t'invite à taper c++ exceptions slow sur Google et lire un peu. Tu trouveras même des exemples de code désassemblé.

[rOut]

Justement, les exemples de code désassemblé montrent que le code des exceptions est bien mis à l'écart, et que le code "normal" est beaucoup plus propre et plus léger qu'un code avec des checks d'error code de partout. Le code des exceptions n'est pas executé tant qu'il n'y a pas d'exceptions.

Après le seul endroit ou je veux bien être d'accord c'est que lors d'une exception il faut dépiler la stack et trouver le bon catch, ce qui peut prendre un petit peu plus de temps qu'un simple return... mais dans un cas d'erreur, ça ne me semble pas être très grave, puisque c'est justement une erreur qui vient de se produire.