IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Utilisation de sbrk


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    227
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 227
    Par défaut Utilisation de sbrk
    Bonjour,
    Je m'intéresse à la mémoire et je souhaite en apprendre davantage.

    Je souhaiterais donc refaire un mini-malloc.
    j'ai vu que, pour demander de la mémoire dans la zone heap, il fallait utiliser la fonction sbrk.
    Ce que je comprends, c'est comment je peux demander d'allouer une zone qui fais x fois la taille d'un int par exemple ?

    Les exemples ne sont pas clairs. Pouvez-vous m'aider ?
    Merci d'avance.

  2. #2
    Expert éminent

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 202
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 202
    Par défaut
    en lisant la doc de la fonction, par exemple man sbrk.

    Cela dit, pourquoi vouloir refaire malloc?
    Que comptes-tu apprendre ainsi?

    Tu apprendras mieux en lisant le code de malloc, plutot qu'en tentant à l'aveugle de la reconstruire.

    Il existe ce qu'on appelle "le modèle de mémoire du C", qui est décrit précisément dans la norme.
    Les détails techniques de comment ce modèle mémoire est réalisé par un système d'exploitation précise sur une architecture précise n'est qu'un cas particulier de mise en œuvre.

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    227
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 227
    Par défaut
    Tout d'abord, C'est un exercice que j'ai a réaliser pour mes études.
    Je dois recodé un mini malloc et les seuls fonctions que j'ai d'autorisé au niveau de la mémoire sont sbrk et sbk c'est donc pour sa que je m’intéresse qu'a ces deux la.

  4. #4
    Expert éminent

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 202
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 202
    Par défaut
    Bien, le cadre étant maintenant posé, on peut passer à la suite:

    D'après man brk, cette fonction est volontairement exclue de la norme POSIX. C'est intéressant.
    Elle permet de modifier la limite supérieure du segment de données, à condition de respecter la pile et le segment de texte.

    J'imagine que tu sais ce que sont les segments de mémoire. Et de là, ce que signifie une segmentation fault.

    De plus, sbrk est une fonction C non système augmentant la taille du segment de données d'une valeur fixe. J'imagine qu'elle appele brk en interne.

    C'est un point de départ, mais ca n'est pas encore une fonction de malloc.
    malloc retourne un pointeur. Il te faut donc un moyen de choisir une adresse.

    De quelle manière la choisirais-tu?

    PS: J'imagine que, puisque tu l'as acceptée en t'inscrivant, tu as lu notre charte, notamment son article IV-N.

  5. #5
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    Octobre 2015
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2015
    Messages : 53
    Par défaut
    Salut,
    ayant moi meme recodé malloc il y a quelques années dans le cadre de mes etudes je te conseille
    de te renseigner sur les algo suivants :
    - first fit (le plus simple mais le moins performant)
    - Best fit
    - Buddy

    Contrairement a Ternel j'avais trouvé l'exercice tres interessant a l'epoque, j'avais appris beaucoup de chose.

    Bon courage

  6. #6
    Expert éminent

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 202
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 202
    Par défaut
    Pour avoir fais l'exercice aussi, si je l'avais trouvé intéressant à l'époque, j'en retire surtout deux enseignements avec l'expérience:
    • Attention aux fausses connaissances qu'on en tire
    • Comprendre, c'est apprendre, mais refaire, c'est risquer.

    Dans la réalité du développement, il ne faut surtout pas refaire ce qui fonctionne très bien.
    malloc n'entre pas du tout dans les "fonctions bancales qui font ce qu'il faut, mais c'est un coup de chance".

    Je suis parfaitement d'accord avec toi, et j'encourage vivement la compréhension du mécanisme.
    Mais lire et comprendre la norme du langage sur la mémoire est encore plus important.

    On est bien là à la frontière entre ce que le langage garantit (l'existence d'une pile et d'un tas, et d'un espace d'adressage des fonctions, ou des chaines de caractères), et ce dont le système dispose vraiment: de la RAM.

  7. #7
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    227
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 227
    Par défaut
    Bonjour;
    Merci pour vos réponses.
    J'ai bien lu l'article IV-N. (et la charte entière au passage)

    Je ne viens pas pour qu'on me fasse mon exercice.
    J'ai bien avancé et compris le fonctionnement de sbrk.

    Par contre je ne vois pas comment stocké les adresses utilisées pour ensuite les libérer . je ne peux pas faire de liste chainée etc. vu que je ne peux pas mall oc à l'intérieur de mall oc.
    J'ai donc pensé à faire un tableau de structure qui contiendrait les adresses (adresse de départ, adresse de fin allouée) pour chaque appel à mon mall oc lite.
    Cette solution ne paraît pas optimiser et je suis obligé de définir un nombre maximum d'adresse demandable.

  8. #8
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    Octobre 2015
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2015
    Messages : 53
    Par défaut
    Citation Envoyé par vodkline Voir le message
    Par contre je ne vois pas comment stocké les adresses utilisées pour ensuite les libérer . je ne peux pas faire de liste chainée etc. vu que je ne peux pas mall oc à l'intérieur de malloc.
    Tu peux quand meme te debrouiller pour faire des listes chainée sans malloc, c'est d'ailleur la base des algo first fit et best fit

  9. #9
    Membre confirmé
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    227
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 227
    Par défaut
    je pensais partir sur ce type d'algo
    http://sandbox.mc.edu/~bennet/cs404/outl/buddy.html

  10. #10
    Membre très actif
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    Mai 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Mai 2010
    Messages : 548
    Par défaut
    Bonsoir,

    Citation Envoyé par vodkline Voir le message
    Bonjour,
    Je m'intéresse à la mémoire et je souhaite en apprendre davantage.

    Je souhaiterais donc refaire un mini-malloc.
    j'ai vu que, pour demander de la mémoire dans la zone heap, il fallait utiliser la fonction sbrk.
    Ce que je comprends, c'est comment je peux demander d'allouer une zone qui fais x fois la taille d'un int par exemple ?

    Les exemples ne sont pas clairs. Pouvez-vous m'aider ?
    Merci d'avance.

    Il se fait tard et je vais essayer d’apporter quelques explications avant de répondre à la question posée. Dans les faits, il vous est possible d’allouer plus de mémoire que votre mémoire RAM en dispose; cela peut paraître farfelu, mais en réalité c’est exactement ce que font les systèmes d’exploitation GNU/Linux ou Unix tous deux utilisent une mascarade pour vous donner une illusion de mémoire infinie pour chaque processus. Cette mascarade en question s’appelle « mémoire virtuelle » (on dit processus l’environnement dans lequel le programme s’exécute et cet environnement est composé de 3 segments qui sont : un segment de données utilisateurs, un segment de données système et un segment d’instruction. Un programme quant à lui n’est rien d’autre qu'une collection d’instruction et de données conservées dans un fichier ordinaire sur votre disque dur dont, dans son noeud d’index, il est marqué comme étant un fichier exécutable et le contenu de ce fichier ordinaire marqué exécutable est organisé selon des règles de votre système d’exploitation).
    Il faut donc comprendre que les processus des systèmes d’exploitation GNU/Linux et Unix disposent d’un espace d’adressage qui est un ensemble d’adresses linéaires d’une région mémoire qu’un processus peut utiliser. Cette adresse est définie par une adresse initiale et une taille dite longueur et quand vous faites un "fork", accéder à un fichier en mémoire, un appel à la fonction d’allocation mémoire "malloc", etc. le processus obtient une nouvelle région mémoire. Sur des architectures 32 bits, l’espace d’adressage est de 4 giga (soit 2^32), mais le système d’exploitation se réserve un gigaoctet. Au final, un processus aura un adressage maximum de 3 giga octets à sa disposition. Tout cet espace est découpé en segments qui ont des fonctions bien particulières à savoir;
    • Un segment appelé « text » qui contient le code exécutable mais aussi les fonctions des bibliothèques partagées et ce segment s’entend jusqu’à l’adresse dans la variable "_etext"*
    • Un segment appelé "data" qui est le segment des données initialisé au chargement d’un processus. Ce segment s’étend de l’adresse contenue dans la variable "_etext" jusqu’à celle contenue dans "_edata".
    • Un segment de données non initialisé et des données allouées dynamiquement qui s’étendent de l’adresse contenue dans "_edata" à celle contenue dans "_end". Ce segment est appelé bss


    "_etext, _edata et _end" sont des variables qui contiennent des adresses correspondantes (dans l’ordre): à la première adresse valide qui se situe au-dessus de "text". des données non initialisées, et enfin des sections non initialisées. À l’autre bout de l’espace d’adressage se trouvent d’autres données comme : les variables d’environnements appellées "env" ; la pile du processus dite communément pile des variables automatiques et appelées "stack". Le tas communément variable dynamique appelé "heap".

    Quand vous allouez de la mémoire, le système ne vous réserve pas de la mémoire dans la RAM, mais vous attribuez des adresses mémoire virtuelle. Plus exactement, quand vous faites appel à la fonction d’allocation mémoire malloc (et bien entendu qui) fait appel à la fonction "brk" qui a son tour positionne la fin du segment de données. En clair, il procède au positionnement de la variable "_end" (première adresse de la section non initialisée .bss) provoquant ainsi la modification de la taille du segment "bss" . Et l’utilisation de "sbrk" ne fait qu’incrémenter l’espace de données en octet. Donc si vous invoquez "sbrk" en l’incrémentant d’une valeur entière ou le contraire vous ne faites qu’augmenter ou diminuer la taille du segment "bss" bien entendu il ne faut pas non plus comprendre que malloc fait appel systématiquement à "sbrk" c’est totalement faux. malloc ,fait appel à "sbrk" occasionnellement, car elle gère à elle seule des blocs mémoire déjà à disposition. De plus, le fait d’augmenter la taille du segment ne signifie en rien que le système exploitation va allouer de la mémoire bien au contraire, c’est quand vous allez écrire des données sur cette zone mémoire ou bloc de mémoire que le système d’exploitation va réellement vous donner de la mémoire dite réelle plus exactement, il déclenche une sorte de erreur d’accès qui donne par la suite une page mémoire réelle. Cette petite mascarade vous permet alors de réserver beaucoup plus de mémoire que le système peut en fournir sans que l’allocation mémoire avec malloc échoue on appelle cela une sur-allocation mémoire « overcommit-mémory » qui suppose qu’une application sollicite toujours plus de mémoire qu’il en a besoin et de ce fait le système accepte toutes allocations mémoire à la condition que la mémoire virtuelle du processus en question ne soit pas saturée ou qui n’excède pas la taille de la mémoire physique disponible.

    Et si votre malloc échoue, c’est juste parce que vous avez essayé de dépasser la limite RLIMIT_DATA, ou que la zone mémoire sollicitée déborde sur une autre mémoire ou peut être parce que vous avez demander en une seule fois une taille de mémoire qui dépasse la capacité de la mémoire virtuelle totale. Les échecs allocation peuvent très bien déclencher un "out of memory killer" (OOM-Killer) qui est une routine de sécurité déclenchée lorsque toute la mémoire du système GNU/Linux ou Unix est saturé. Il a pour seule et unique mission de faire des investigations dans le but de trouver le processus qui est à l’origine de la saturation mémoire et de le tuer (cela à un côté bénéfique c’est une sorte de sécurité qui permet d’éviter ce qui peut être ou est une attaque par déni de service. Cependant, dans des systèmes critiques ça peut devenir très très vite un problème majeur donc désactiver OOM-Killer c’est savoir ce que l’on fait).

    Comme je l'ai mentionné plus haut, quand vous allouez de la mémoire, le système ne vous réserve pas de la mémoire dans la RAM, mais vous attribuez des adresses mémoire virtuelle. Pour avoir un aperçu de façon concrète nous allons allouer 50000 blocs de 1Go chacune et ensuite nous allons tenter d’accéder à cette mémoire pour voir si on peut y écrire quelque chose et voir OOM-Killer faire son travail et dans un second cas nous allons désactiver l'OOM-Killer pour voir le comportement du système quand un processus sature la mémoire.

    Avant toute chose : je ne suis pas responsable de tout dommage direct ou indirect tel qu'il soit. Tester le code de préférence sous une VM ou machine isolée configurée pour les test de ce genre.
    Pour desactiver OMM-Killer il faut écrire dans le fichier overcommit-memory la valeur 2. Ce fichier se trouve généralement dans /proc/sys/vm/overcommit-acounting

    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
     
    /*
     ============================================================================
     Name        : source.c
     Date        : 19/02/2017
     Author      : SAMBIA39
     Version     : 0.1
     Copyright   : Copyright © 2017 SAMBIA39 All rights reserved.
     Description : Ansi-style
     ============================================================================
     */
     
    #define BLOCMEM 50000               /*  nombre de bloc memoire  */
    #define GIGAOCT 1024*1024*1024      /*  1Go par bloc mémoire    */
     
    #include <stdio.h>
    #include <stdlib.h>
    #include <limits.h>
    #include <stddef.h>
    #include <string.h>
     
     
    int main( void ){
     
        extern int errno;               /*  Errno                       */
        char *pMem[BLOCMEM];            /*  Bloc mémoires               */
        unsigned long i = 0;            /*  Variable d'incrémentation   */
     
        /*
         *  Allocation des 50.000 blocs
         *  mémoire de 1Go pas en une seul fois
         */
        errno = 0;
        for( i = 0; i < BLOCMEM; i++ ){
            if( NULL == ( pMem[i] = malloc(GIGAOCT)) ){
                fprintf( stdout, "(%d)\t%s\n\t:%s\n",
                        errno, "Erreur alloc mem", strerror(errno) );
                return (EXIT_FAILURE);
            }
        }
        fprintf( stdout, "Fin d'Allocation de %d\n", BLOCMEM );
     
     
        /*
         *  Tentative d'écriture mémoire
         */
        for( i = 0; i < BLOCMEM; i++ ){
            memset( pMem[i], 0, GIGAOCT );
            fprintf( stdout, "(%ld)[%p]\t:%s\t%ld Go utiliser\n", i,(void*)pMem[i],
                    (NULL == pMem[i]) ? "NULL":"Initialisé à 0 et", (i+1) );
        }
     
        /*
         *  Free bloc mémoire jamais atteint
         *  OOM-Kiler actifs
         */
        for( i = 0; i < BLOCMEM; i++ ){
            free( pMem[i] );
            pMem[i] = NULL;
        }
     
        return (EXIT_SUCCESS);
    }

    Resultat du test:
    • malloc n’a jamais renvoyé NULL
    • malloc renvoie des pointeurs sur l’espace virtuel

    et lors de la tentative d’initialisation OOM-killeur tue memset avec un signal SIGKILL

    Pour répondre à la question posée, il vous est théoriquement possible d’allouer X en taille mémoire à condition que cette mémoire n’excède pas la taille de la mémoire virtuelle totale ou réelle. Toutefois, vous serez limité à un moment donné à la tentative d’écriture sur cette X mémoire ou bloc de Y mémoire de X.

    Deuxième point : Réécrire malloc permet de comprendre certaines choses et les mécanismes de la mémoire, mais il faut savoir que malloc est beaucoup plus complexe que ça : exemple, malloc sur les systèmes BSD voire autres utilise la projection mémoire mmap pour obtenir de gros bloc mémoire indépendant et le mécanisme de mmap n’a absolument rien à voir avec sbrk. Tout de même, rien ne vous empêche de réécrire malloc ou concevoir un système de gestion mémoire minimaliste totalement indépendant de la mémoire libre. A vous de faire ce dont vous avez envie.

    à bientôt.

  11. #11
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    La chose que je ne comprends pas avec brk/sbrk qui agrandissent le tas et les "implémentations perso de malloc()", c'est comment on évite ensuite les conflits avec le vrai malloc() (comment on empêche malloc() de retourner une adresse dans le tas que notre "code perso" a déjà "alloué" à ses appelants)...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  12. #12
    Expert éminent

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 202
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 202
    Par défaut
    En ne s'en servant pas.
    Ce genre de situation intervient quand on écrit une libc (ou juste un avatar), pour un pseudo OS de découverte.
    Un peu comme un Minix.

  13. #13
    Membre très actif
    Avatar de sambia39
    Homme Profil pro
    No Comment
    Inscrit en
    Mai 2010
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : No Comment
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Mai 2010
    Messages : 548
    Par défaut
    Bonjour,

    Citation Envoyé par Médinoc Voir le message
    La chose que je ne comprends pas avec brk/sbrk qui agrandissent le tas et les "implémentations perso de malloc()", c'est comment on évite ensuite les conflits avec le vrai malloc() (comment on empêche malloc() de retourner une adresse dans le tas que notre "code perso" a déjà "alloué" à ses appelants)...
    Personnellement je pense qu’il n’y a pas de conflits parce que "malloc" dispose déjà d’une zone mémoire à sa disposition qu'elle gère. Deuxièmes points "malloc" fait appel occasionnellement à "sbrk" de plus, toutes les adresses que "malloc" vous fournit ne sont pas des adresses de mémoire réel, mais virtuel, car le système ne réserve pas de la mémoire dans la RAM, mais attribue des adresses mémoire virtuelle. Sans oublié que "malloc" échouera systématiquement quand vous essayez de dépasser "RLIMIT_DATA", où que la zone mémoire sollicitée déborde sur une autre mémoire où parce que vous avez demandé en une seule fois une taille de mémoire qui dépasse la capacité de la mémoire virtuelle totale et d'ailleurs « out of memory killer" OOM-Killer est là pour vous faire un rappel a l’ordre. De mêmes "sbrk" échouera si taille de mémoire sollicitée déborde.

    Citation Envoyé par ternel Voir le message
    En ne s'en servant pas.
    Ce genre de situation intervient quand on écrit une libc (ou juste un avatar), pour un pseudo OS de découverte.
    Un peu comme un Minix.
    Non, pas comme Minix . Chez Minix ce genre de chose ne peut avoir lieu; je m’explique. Minix possède également un mécanisme de mémoire virtuelle. La mémoire virtuelle d’un processus Minix est découpée en trois parties de segments (segment contenant le code exécutable appeler text, un segment contenant les données de taille fixe appeler stack et le segment contenant les données de taille dynamique appelée data). "malloc" sur Minix va dans un premier temps utiliser une zone mémoire suffisamment grande déjà disponible quelle dispose, mais quand cette mémoire n’est pas disponible malloc fait appel « brk/sbrk » qui va alors sollicité de la mémoire dans le tas. Tout compte fait, s’il n’y a pas assez de mémoire alors "sbrk" échouera tout comme la fonction "malloc". Finalement, mêmes sur Minix il peut y avoir une telle chose Tanenbaum a tout de même pensé à la chose. Ceci dit, sur des systèmes d'exploitation exotique ou conçue dans les garages il peut y avoir une telle chose, tout de même, un concepteur de système d’exploitation du dimanche pense à une bonne gestion de la mémoire donc c’est très très rare.

    à bientôt

  14. #14
    Membre chevronné
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    1 854
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 1 854
    Par défaut
    Bonjour,

    Sujet très intéressant

    Ce que je ne comprends pas c'est que si malloc retourne un nombre qui représente une adresse virtuelle qui est totalement décorrélée de la mémoire physique, coment cette ligne peut fonctionner ?
    => Si pmem est un pointeur sur une adresse virtuelle qui ne correspond à rien, comment le langage C fait pour la retrouver l'adresse physique ?

Discussions similaires

  1. utiliser les tag [MFC] [Win32] [.NET] [C++/CLI]
    Par hiko-seijuro dans le forum Visual C++
    Réponses: 8
    Dernier message: 08/06/2005, 15h57
  2. Réponses: 4
    Dernier message: 05/06/2002, 14h35
  3. utilisation du meta type ANY
    Par Anonymous dans le forum CORBA
    Réponses: 1
    Dernier message: 15/04/2002, 12h36
  4. [BCB5] Utilisation des Ressources (.res)
    Par Vince78 dans le forum C++Builder
    Réponses: 2
    Dernier message: 04/04/2002, 16h01
  5. Réponses: 2
    Dernier message: 20/03/2002, 23h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo