C++

Bonjour à vous, 
J'utilise le Langage C++, dans le cadre de mon option de "Codage Numérique : Du Nombre au Pixels". Nous utilisons, un programme qui a été créer par notre professeur qui permet de convertir un premier programme en une image en liant les 2. Cela n'est pas le soucis, mais, nous devons réaliser ce motif.

Le corps du programme ayant déjà été mis en place, je n'ai pas eu de soucis pour cela. Mais, le problème que j'éprouve arrive lorsque je souhaite créer les carreau. Il faut savoir que nous utilisons des tableau bi-dimensionnel de Pixels pour créer nos motifs ou images.

/*
 * TestRayures.cpp
 *
 *  Created on: 1 août 2020
 *      Author: Dom
 */

#include <iostream>
#include <string>
#include "OutilsCreationImage.h"

using namespace std;

int main()
{
cout <<"création d'une image représentant un damier" << endl;

string chemin = "images_creees"; // chemin relatif : c'est-à-dire à partir du répertoire courant

string nomFichierImage  = chemin + "\\" + "TestDamier_LosangeVFinal.bmp";

const uint32_t LONGUEUR = 400;
const uint32_t LARGEUR = 320;

uint32_t m = LARGEUR-1;
uint32_t n = LONGUEUR-1;

const uint32_t couleur1 = 0x00FFFFFF; 			// cyan opaque
const uint32_t couleur2 = 0xFFFF00FF; 			// jaune opaque

const unsigned couleurs[] = {couleur1,couleur2};

uint32_t matricePixels[LARGEUR][LONGUEUR];

int largeurRayure = 40;
int longueurRayure = 40;

uint32_t i,j;

for ( i = 0 ; i <= m ; ++i)		// remplissage de la matrice de pixels
for ( j = 0 ; j <= n ; ++j )
	{
    int L = (j+i)/longueurRayure;
	int l = (i-j)/largeurRayure;
    
    int c = (L + l)%2;
    matricePixels[i][j] = couleurs[c];
	}

OutilsCreationImage::creeImage( nomFichierImage,  matricePixels, LARGEUR);		// sauve l'image sur le fichier nomFichierImage

cout << "image créée" << endl;
return 0;
}

Je n'arrive pas malgré mes efforts à comprendre d'ou viennent mes problèmes...

Voici l'image obtenu après lancement du programme actuelle...

-
Edité par JulienLORSCHEIDER1 27 octobre 2021 à 12:39:25

hello,

c'est une histoire de calcul tout simplement. Regardes attentivement ta double boucle, et essaie de recalculer tes valeurs (i, j, L, l) "à la main" pour un ou 2 tours et tu verras une erreur ^^.

Il y en a d'autres, comme mélanger l'utilisation de int, qui est signé, et uint32_t qui ne l'est pas. Comme ton programme n'a a priori aucune valeur négative à traiter tu devrais te contenter d'utiliser des unsigned.

Après, le using namespace std n'est pas non plus topissime, voire dangereux pour ton avenir de développeur... Essaie de t'habituer à ne pas l'utiliser, même si c'est un peu plus chiant d'écrire le std:: devant chaque objet de la SL

-
Edité par nours59 27 octobre 2021 à 16:46:19

Je comprend ce que tu me dis, c'est simplement dans le cas d'un projets en cours de Licence 1re année, c'est pourquoi je n'ai pas utiliser la std:: devant chaque objet de la SL, quant au uint32_t, c'est liée au fait que les couleurs sont codée en base hexadécimale, ca implique que l'on utilise les unsigned Long, je que transforme étant sur MacOs en uint32_t. Quant à la première indication, je vais essayer merci pour l'indice et le conseil

Salut,

JulienLORSCHEIDER1 a écrit:

c'est simplement dans le cas d'un projets en cours de Licence 1re année, c'est pourquoi je n'ai pas utiliser la std:: devant chaque objet de la SL

Et, concrètement, ca change ou ca justifie quoi?

Si les fonctionnalités de la SL ont été mises dans un espace de noms, c'est pour de bonnes raisons...

Si tu prend l'habitude de "foutre ces raisons en l'air" sous prétexte que tu n'es encore qu'en formation, tu auras énormément de mal à t'en défaire par la suite.

Et ce serait vraiment dommage que tu es visiblement conscient du problème.

Donc, apprend tout de suite à faire les choses correctement pour prendre directement les bonnes habitudes, cela te facilitera la vie par la suite

Si on sait d’où viennent les objets, on peut faire un using namespace ça ne pose pas de problème, c’est juste que si un mec extérieur lit le code il ne sait pas forcément si les objets viennent de la stl ou pas

Hello !

J'ai testé ton code, adapté pour Windows, j'y ai apporté une toute petite modif qui fait que ça fonctionne :

 

Je précise c'est du C avec API Windows (pas la peine de polémiquer) La partie concernée avec le sujet est dans la fonction Action : 

#include <windows.h>

#define IDM_QUIT 1

#define BWIDTH 400
#define BHEIGHT 320

HINSTANCE hinst;
HBITMAP hbmp;
DWORD* pPixel = NULL;

LRESULT CALLBACK MainWndProc(HWND, UINT, WPARAM, LPARAM);

void action(void)
{
    const DWORD LONGUEUR = BHEIGHT;
    const DWORD LARGEUR = BWIDTH;

    const DWORD couleur1 = 0x004FFFFF;
    const DWORD couleur2 = 0x00FFFF4F;

    const unsigned couleurs[] = {couleur1, couleur2};

    int largeurRayure = 40;
    int longueurRayure = 40;

    DWORD i,j;

    for ( i = 0 ; i < LARGEUR ; ++i)
        for ( j = 0 ; j < LONGUEUR ; ++j)
        {
            int L = (i+j)/longueurRayure;
            int l = (LARGEUR+i-j)/largeurRayure;

            int c = (L + l)%2;
            pPixel[j*LARGEUR + i] = couleurs[c];
        }
}

int WINAPI WinMain(HINSTANCE hinstance, HINSTANCE hPrevInstance,
                   LPSTR lpCmdLine, int nCmdShow)
{
    HWND hwnd;
    MSG msg;
    WNDCLASS wc;
    HMENU hMenu, hSousMenu;

    hinst = hinstance;

    wc.style = 0 ;
    wc.lpfnWndProc = MainWndProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;
    wc.hInstance = hinstance;
    wc.hIcon = NULL;
    wc.hCursor = LoadCursor(NULL, IDC_ARROW);
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
    wc.lpszMenuName =  NULL;
    wc.lpszClassName = "MaWinClass";

    RegisterClass(&wc);

    hSousMenu = CreateMenu();
    AppendMenu(hSousMenu, MF_STRING, IDM_QUIT, "Quitter");
    hMenu  = CreateMenu();
    AppendMenu(hMenu,MF_POPUP,(UINT)hSousMenu,"Fichier");

    hwnd = CreateWindow("MaWinClass", "Titre", WS_OVERLAPPEDWINDOW,
                        CW_USEDEFAULT, CW_USEDEFAULT, 460, 500,
                        NULL, hMenu, hinstance, NULL);

    ShowWindow(hwnd, nCmdShow);

    while (GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return msg.wParam;
}

/******************************************************************************/


LRESULT CALLBACK MainWndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
    case WM_CREATE:
    {
        RECT rc;
        GetClientRect(hwnd, &rc);

        BITMAPINFO* pInfo = calloc(1, sizeof(BITMAPINFOHEADER) + 16);
        pInfo->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
        pInfo->bmiHeader.biWidth = BWIDTH;
        pInfo->bmiHeader.biHeight = BHEIGHT;
        pInfo->bmiHeader.biPlanes = 1;
        pInfo->bmiHeader.biBitCount = 32;

        hbmp = CreateDIBSection(NULL, pInfo, DIB_RGB_COLORS, (VOID**)&pPixel, NULL, 0);

        free(pInfo);
        action();
        return 0;
    }

    case WM_PAINT:
    {
        PAINTSTRUCT ps;
        HDC hdc = BeginPaint(hwnd, &ps);
        HDC hdcDB = CreateCompatibleDC(hdc);

        HGDIOBJ m_old = SelectObject(hdcDB, hbmp);

        BitBlt(hdc, 20, 20, BWIDTH, BHEIGHT, hdcDB, 0, 0, SRCCOPY);

        SelectObject (hdcDB, m_old);
        DeleteDC(hdcDB);

        EndPaint(hwnd, &ps);

        return 0;
    }

    case WM_CLOSE :
        DestroyWindow(hwnd);
        return 0;

    case WM_COMMAND :
        if(LOWORD(wParam) == IDM_QUIT)
            PostMessage(hwnd, WM_CLOSE,0,0);
        return 0;

    case WM_DESTROY :
        PostQuitMessage(0);
        return 0;

    default :
        return DefWindowProc(hwnd, uMsg, wParam, lParam);
    }
}

Je l'ai mis en entier au cas ou il y en a qui veule tester.

Edit : modif hauteur pour coller avec les dimension du PO.

-
Edité par rouIoude 28 octobre 2021 à 11:26:36

@JadeSalina, quand t'es sur un projet à plusieurs millions de lignes, qui a été modifié par des "stagiaires", qui est le résultat de la fusion de plusieurs projets qui utilisaient chacun des librairies différentes pour faire des choses identiques, oui mettre "stl::" devant les très rare appel à la STL (car on wrappe quasiment toujours ces API pour qu'elles correspondent aux contraintes internes (thread-safe, déroutage vers des concentrateurs Cloud, etc...).

Donc PUTAIN !!!, LAISSEZ CREVEZ CE TRUC QUI A ETE INVENTE POUR LES FEIGNASSES QUI VOULAIENT PAS TOUCHER A LEUR CODE A LA NORMALISATION DU C++ EN 1998, 23 ans de retard, 23 putain de fucking d'années, BORDEL !!!

Merci JadeSalina, tu as invoqué Dark-Bacelar 

On peut parfaitement faire des using namespace de partout et même se retrouver avec des classes qui ont le même nom et quand même pouvoir utiliser l'une ou l'autre sans ambiguité (en mettant le préfixe là où ça lève l'ambiguité). D'ailleurs on peut aussi avoir des variables locales qui ont le même nom que des classes sans problème

#include <iostream>

struct foo {
  int a;
  foo(int a) : a{a} {} // pas d'ambiguité entre 'a' et 'a'

  void print() const {
	  std::cout << a << std::endl;
  }
};

int main() {
  int foo = 50;
  ::foo f{foo}; // pas d'ambiguité entre foo et foo
  f.print(); // affiche "50"

  return 0;
}

-
Edité par JadeSalina 28 octobre 2021 à 21:01:43

Faut pas non plus en faire une pendule.

Le débutant qui retrouve dans le proverbial projet avec des millions de lignes, il n'est pas tout seul. Il est dans une équipe, et coaché par ses collègues plus experimentés qui l'aident à respecter les conventions maison, et les bonnes pratiques. Peut etre qu'il faudra, en reviewant son code, lui rappeler une ou deux fois ce point si il ne le faisait pas, mais enfin, il y a des problemes plus difficiles à corriger chez les débutants.

Et si dans un projet on se retrouve avec des tonnes de code merdique, ben c'est un problème de compétence de l'encadrement.  Personne n'a verifié au fur et à mesure ?

michelbillaud a écrit:

Personne n'a verifié au fur et à mesure ?

Ouais, déso, c'est moi qui devait le faire, mais j'avais la flemme. Et mon chat était malade. Et en plus, ce n'est pas très grave qu'on utilise "using namespace std", on utilise aussi des pointeurs nus. Caaaa vaaaaaa.

Mais la plupart du temps la mémoire est gérée par un système externe et personne dans le reste de l'appli ne se préoccupe de savoir d'où elle sort et qui doit la libérer, c'est juste des fonctions qui manipulent de la mémoire simplement, en évitant les bugs de libération etc puisque ce n'est pas à eux de la gérer ! Du coup dans ce cas des pointeurs nus sont les plus adaptés pour représenter ce cas d'utilisation.

J'ai trouvé un autre mec qui fait des gros trucs en simple C, il explique ce qu'apporte le C par rapport à C++ : https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.html

Et d'ailleurs en utilisant des smart pointers et autres conteneurs partout, on a intérêt à être concentré car au lieu d'avoir un crash ou seg fault dans le pire des cas avec des raw pointers, on a un programme qui compile et qui marche quand même correctement ! Mais en fait on ne se rend pas compte que le code est plus lent que ce qu'il devrait, ou alors on se demande pourquoi les textures du niveau 2 sont toujours chargées alors qu'on est au niveau 5 tout ça car on a oublié un std::move quelque part !

Ce que je trouve le mieux c'est d'allouer de la mémoire (possiblement sur la pile) et tout le reste du code manipule uniquement ce que vous appelez des "views", ce qui fait que ces views sont juste de simples struct rapides à se faire passer, sans risquer d'oublier un move, et la mémoire est allouée et déallouée par une seule personne. C'est mieux que de mettre cette contrainte sur les objets eux-même et de se balader avec de gros std::vector et autres std::string. 

Chut...

La discussion est devenue hors sujet. Ouvrez une nouvelle discussion si vous voulez continuer à parler hors sujet.

@JadeSalina, vous appliquez mal les precepts de Schopenhauer. 

Ca se voit que l'article que vous donnez en référence (fort intéressant au demeurant) n'appui pas vos propos et même renforce les nôtres, "Coder en C, c'est pas la même chose que coder en C++" et il le montre brillamment.

>, on a intérêt à être concentré car au lieu d'avoir un crash ou seg fault dans le pire des cas avec des raw pointers

LOL, c'est bien connu qu'un pointeur nu invalide fait automatiquement un segfault quand il est utilisé. C'est le pouvoir du pointeur nu quantique ?

>Mais en fait on ne se rend pas compte que le code est plus lent que ce qu'il devrait

Une affirmation extraordinaire nécessite une preuve plus qu'ordinaire, où qui sont les benchmarks pour confirmer vos propos ?

Mal utilisés, c'est comme le reste.

L'approche que vous proposez n'est pas débile mais pourquoi serait-elle LA solution qui fonctionne tout le temps ? Et c'est la même chose pour les outils offerts par la STL.

C'est comme tout, faut réfléchir.

Cette intervention vient surtout que vous, @JadeSalina, qui prenez souvent la peine d'aider en profondeur les demandeurs dans ce forum, vous répondez souvent avec des solutions qui ont un arrière goût de "C++ old school/ C non assumé". Ce qui n'est pas très gênant dans l'absolu.

Mais là, à conseiller sans discernement l'usage de "using namespace std;", faut pas pousser mémé dans les orties.

Comme le disait le plus grand penseur de notre génération "Le language C++, tu l'aimes ou tu le quittes" (LOL).

Je suis d'accord avec @michelbillaud, mais c'est dans la théorie que ça fonctionne comme cela, et faire les piqûres de rappel dans les forum, ça évite les "formes graves".

@gbdivers, tellement le réel. (et aussi pas le temps, la release était pour hier, et j'en ai rien à foutre, je parts pour une autre mission de merde la semaine prochaine)

23 fucking years !!!

> mais c'est dans la théorie que ça fonctionne comme cela,

Dans la théorie, l'histoire des namespaces est certainement importante pour avoir des beaucx programmes C++ bien écrit, en pratique ça s'arrange facilement, puisqu'en pratique on n'en a rien a foutre du moment que ça compile et que ça tourne. :-)

> et faire les piqûres de rappel dans les forum, ça évite les "formes graves".

y a des priorités, et selon le public, ça va pas être les mêmes

Par exemple, quand je vois ça

for ( i = 0 ; i <= m ; ++i)      // remplissage de la matrice de pixels
for ( j = 0 ; j <= n ; ++j )

je me pose plutôt des questions sur le <=

Bon d'accord, ça vient de

uint32_t m = LARGEUR-1;
uint32_t n = LONGUEUR-1;

mais comme m et n ne changent pas

1. si on tient à les utiliser, pourquoi ne sont-ils pas const ?

2. pourquoi ne pas utiliser directement LARGEUR et LONGUEUR ?

Apprendre à écrire du code qui a l'air simple, sans numéros de claquettes avec des variables en trop, ça me parait prioritaire comme apprentissage. Un cours "Codage Numérique : Du Nombre au Pixels", c'est pas fait pour insister sur les fantaisies particulières de C++, qui sont d'un intérêt limité. C++ c'est juste pour les fainéants qui refusent de se mettre à Rust  en 2021 :-)

PS1  et puisqu'il s'agit de coordonnées, w et h (ou width et height, qui est toujours un bon exercice pour mettre les h au bon endroit) ça serait plus parlant que m et n, et x,y au lieu de i et j.

PS2: et puis ça serait embêtant qu'un programmeur pense qu'il sait bien programmer à partir du moment où il sait que c'est mal d'utiliser des using namespace, des pointeurs et des gotos en C++.

PS3: ce qui serait plus fondamental, c'est de sortir dans une fonction la création de la matrice contenant le damier. Une fonction qui n'a rien à voir avec des histoires de namespaces ou d'entree-sortie, mais qui pose un problème technique du prog graphique en C++ : se débrouiller à passer des tableaux 2D en paramètres.

-
Edité par michelbillaud 29 octobre 2021 à 13:53:26

(Difficile de ne pas être d'accord avec michelbillaud, il y a une focalisation, voire une crispation, sur "using namespace std")

Parce qu'il suffit de faire  grep "using namespace" avec les yeux dans les 10 premières lignes sans s'intéresser au reste ni chercher à comprendre, ce qui leur permet de mettre plus bas que terre l'impudent heretique qui a osé leur presenter un tel code.

Y a des gens, ils ont une vocation de fonctionnaire veillant à la parfaite régularité des documents pour pénétrer en Corée du Nord.

-
Edité par michelbillaud 29 octobre 2021 à 14:07:23

JadeSalina a écrit:

Et d'ailleurs en utilisant des smart pointers et autres conteneurs partout, on a intérêt à être concentré car au lieu d'avoir un crash ou seg fault dans le pire des cas avec des raw pointers,

Ben, justement, smart pointers et containers permettent bien mieux de te concentrer sur ce qui est vraiment important (la fonctionnalité que tu veux développer) au lieu de devoir te concentrer sur des détails sommes toutes "triviaux" (mais si autant qu'on pourrait le croire) comme la gestion dynamique de la mémoire ou l'implémentation du conteneur "qui va bien"...

JadeSalina a écrit:

Mais en fait on ne se rend pas compte que le code est plus lent que ce qu'il devrait

Ah bon? Dans quel film?

Je ne sais pas si tu connais un temps soit peu l'assembleur, mais, a priori, s'il devait vraiment y avoir une telle différence en termes de performances, ==>ce code<== devrait sans doute présenter de nombreuses différence, tu ne crois pas?

Mais alors, comment va-t-on expliquer que l'assembleur généré dans les différentes situation (passage de paramètre par référence ou par pointeur, d'une structure créée sur la pile ou en ayant recours à l'allocation dynamique, géré sous la forme de raw ou de smart pointer) puisse être à ce point identique lors des appels aux fonctions byRef et byPtr ?(équivalence renforcée dés que tu envisages d'utiliser l'option -O2).

Maintenant, il est vrai que, si tu préfères utiliser std::shared_ptr pour éviter de te casser la tête, et que tu ignore totalement std::weak_ptr, tu risques effectivement d'éprouver des pertes de performances à cause du "comptage de références". 

Désolé, ma bonne dame, mais c'est fini le temps des bisounours.  Bienvenue dans le monde réel, où ce que l'on gagne d'un coté a forcément un cout d'un autre :-$

JadeSalina a écrit:

ou alors on se demande pourquoi les textures du niveau 2 sont toujours chargées alors qu'on est au niveau 5 tout ça car on a oublié un std::move quelque part !

Mais, ca, ma bonne dame, si un ouvrier ou un employé (le développeur, en l'occurrence) n'est pas capable d'utiliser correctement les outils que l'on met à sa disposition, dites moi ce que vous voudriez que nous fassions de plus pour lui?

JadeSalina a écrit:

Ce que je trouve le mieux c'est d'allouer de la mémoire (possiblement sur la pile)

Et pourquoi forcément sur la pile? Sais tu seulement que la taille de la pile n'est pas extensible à l'infini, et qu'elle est déjà largement utilisée rien que pour "garder une trace" de l'endroit où le processeur doit reprendre l'exécution d'une fonction après l'appel à une autre (ainsi que des données locales créées sur la pile)?

Pourquoi ne pas envisager un memory pool si tu en a vraiment besoin? Et, à part en embarqué -- domaine qui est traditionnellement "plutôt limité en mémoire -- qu'as tu exactement contre l'utilisation sur le tas, sur laquelle ton memory pool sera d'ailleurs sans doute basé (mais en réservant immédiatement une quantité de mémoire "importante")?

JadeSalina a écrit:

 et la mémoire est allouée et déallouée par une seule personne.

Bien, tu viens de découvrir le principe même du RAII... A ceci près qu'il ne se cantonne pas uniquement à la gestion de la mémoire, mais qu'il englobe également la gestion de toutes les ressources possibles et imaginable

JadeSalina a écrit:

 C'est mieux que de mettre cette contrainte sur les objets eux-même et de se balader avec de gros std::vector et autres std::string. 

Heu... De quelles contraintes parles-tu exactement? Car, en dehors des avantages que ces classes présentent (comme la connaissance des bornes dans lesquelles leur utilisation ne posera pas problème), ces classes ne fournissent ni plus ni moins que tout ce que tu devrais mettre toi-même en place si elles n'existaient pas... Alors, même, nous sommes bien d'accord, que tu as des choses largement plus intéressantes à faire de ton temps

Le seul problème réel que je voie avec ces classes se présente lors d'une éventuelle copie de leur contenu, car la copie (et la destruction de la copie lorsqu'elle n'est plus nécessaire) va -- effectivement -- demander "énormément" de temps et de ressources (mémoire, principalement).

C'est bien pour cela que la notion de référence (éventuellement constante, si la donnée ne doit pas être modifiée) existe

Attention, je ne remet absolument pas en cause l'utilisation de vues... J'essaye juste de te faire comprendre qu'une vue n'aura de l'intérêt que si elle présente des opportunités qui ne sont pas présentées ou qui s'avèrent plus difficile de mettre en œuvre au travers de l'original.

Bien sur, tu peux toujours définir une chaine de caractères  littérale qui serait composée de 50 000 caractères et qui représenterait en réalité de 5 000 chaines de 10 caractères.  Tu pourrais même sans doute carrément la faire entrer dans la zone des "données constantes" en t'y prenant correctement. Et donc, l'utilisation de vues prendrait tout son sens pour te permettre de récupérer ces différentes chaines "constituantes".

Il est de même parfaitement clair que ce ne serait pas la seule utilisation "intéressante" que l'on pourrait faire de la notion de vues (disons juste que c'est la première qui me soit venue à l'esprit ).

Il faut juste arriver à comprendre que les vues, les chaines de caractères de type std::string, les collections comme std::vector<Type> ou autre, et même les grands paradigmes que C++ met à ta disposition (et plein d'autres choses) ne sont que des outils destinés à te faciliter la vie et à te permettre de présenter un code de "meilleure qualité" car à la fois "plus fiable", plus facile à (re)lire, plus facile à débugger, plus facile à corriger et plus facile à faire évoluer.

Seulement, comme tous les outils, il faut apprendre à s'en servir correctement et à bon escient.

(Ne relancez pas encore la discussion "le C est mieux" avec Jade...)

Bonjour les Zéros,

J'ai essayé de faire le damier, j'ai pris les deux réponses les plus pertinentes, mais je n'y arrive pas.

Pouvez-vous m'aider ?

koala01 a écrit:

Salut,

JulienLORSCHEIDER1 a écrit:

c'est simplement dans le cas d'un projets en cours de Licence 1re année, c'est pourquoi je n'ai pas utiliser la std:: devant chaque objet de la SL

Et, concrètement, ca change ou ca justifie quoi?

Si les fonctionnalités de la SL ont été mises dans un espace de noms, c'est pour de bonnes raisons...

Si tu prend l'habitude de "foutre ces raisons en l'air" sous prétexte que tu n'es encore qu'en formation, tu auras énormément de mal à t'en défaire par la suite.

Et ce serait vraiment dommage que tu es visiblement conscient du problème.

Donc, apprend tout de suite à faire les choses correctement pour prendre directement les bonnes habitudes, cela te facilitera la vie par la suite

bacelar a écrit:

@JadeSalina, quand t'es sur un projet à plusieurs millions de lignes, qui a été modifié par des "stagiaires", qui est le résultat de la fusion de plusieurs projets qui utilisaient chacun des librairies différentes pour faire des choses identiques, oui mettre "stl::" devant les très rare appel à la STL (car on wrappe quasiment toujours ces API pour qu'elles correspondent aux contraintes internes (thread-safe, déroutage vers des concentrateurs Cloud, etc...).

Donc PUTAIN !!!, LAISSEZ CREVEZ CE TRUC QUI A ETE INVENTE POUR LES FEIGNASSES QUI VOULAIENT PAS TOUCHER A LEUR CODE A LA NORMALISATION DU C++ EN 1998, 23 ans de retard, 23 putain de fucking d'années, BORDEL !!!

Zero.c a écrit:

Bonjour les Zéros,

J'ai essayé de faire le damier, j'ai pris les deux réponses les plus pertinentes, mais je n'y arrive pas.

Pouvez-vous m'aider ?

Réponse habituelle, fais-voir ton code, on essaiera de te dire ce qui va pas, et ce qu'on pourrait faire pour que ça aille mieux.

Y a que ça qui t'aidera vraiment. Pas si on fait le boulot à ta place (gratuitement, quelle horreur).

-
Edité par michelbillaud 30 octobre 2021 à 13:58:43