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

Langage C++ Discussion :

Tableau et constructeurs sans arguments


Sujet :

Langage C++

  1. #21
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par r0d Voir le message
    Effectivement, la pile et le tas sont des notions propres au compilateur. Peut-être même au C et au C++? En C++ c'est même un peu plus complexe (je ne sais pas en C), car il y a d'autres types de mémoire (je ne m'en souviens plus, mais en tout il y en a 5 ou 6, dont le pile, le tas, la memoire statique, et je ne sais plus les autres).
    Aucune de ces notions n'existent en C++ (i.e. dans la norme). Le C++ parle uniquement de la durée de vie des variables limitée au scope (qui correspondra à la pile) ou géré par le développeur avec new/delete (qui correspond au tas) ou sur la durée du programme.

    Citation Envoyé par r0d Voir le message
    Mais ça se sont des notions au niveau du compilateur.
    Ce sont des notions liées à l'O.S. Le compilateur se contente de traduire les exigences du langage dans l'architecture de l'O.S. cible.
    Maintenant, je ne connais pas d'O.S. qui n'aie pas une pile et un tas...

    Citation Envoyé par wafiwafi Voir le message
    En fait je me trouve devant un dilemme!
    Dans le forum de Java ou langage générale, on me précise qu'une vision conceptuelle en ce qui concerne la gestion de la mémoire(code,pile,tas,...), est fournie à l'utilisateur qui n'a rien à voir avec la façon et encore une fois avec laquelle le compilateur gère la mémoire (voir la discussion que j'ai indiqué dans mon précédent message). Alors qu'ici (C++), on m'affirme le contraire.
    C'est pas tout à fait ça. Le langage C++ ne parle ni de segment code, ni de pile ni de tas. Tout ça c'est du ressort de l'O.S. Le compilateur traduit les instructions du langage C++ vers les mécanismes et l'architecture de l'O.S. cible. Par exemple, quand tu déclares une variable locale, le compilateur pour windows génère les instructions nécessaires pour allouer un espace suffisant et correctement aligné sur la pile et va adresser cet espace lorsque la variable est accédée. Lorsque tu déclares un tableau, la norme indique que les éléments doivent être contigues en mémoire. Cela signifie que &T[i]==T+i==reinterpret_cast<unsigned char*>(T) + i*sizeof(T[0]).
    A charge pour le compilateur de s'assurer que ce contrat sera rempli dans le programme généré. Mais même ceci est abstrait par le mécanisme de mémoire virtuelle. Si le tas est suffisamment grand, le process alloue le bloc mémoire et les adresses sont contigues. A charge de l'infrastructure de faire le mapping nécessaire entre mémoire virtuelle et mémoire physique pour que ça ait l'air de correspondre. Si physiquement et virtuellement cela correspond, et ben, le mapping est juste une translation. Sinon, la MMU(?) en traduisant l'adresse virtuelle ira chercher le bon bloc.

    [EDIT] : j'ai lu la discussion que tu mentionnes.

  2. #22
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Mais reprend simplement les faits:
    1 un processeur est quelque chose de très bête qui ne peut envisager que trois types d'actions sur la mémoire (sachant que tout ce qui est branché sur l'ordinateur est accessible par une adresse mémoire particulière):
    • lire ce qui s'y trouve afin d'utiliser les donnée "par ailleurs"
    • écrire des données
    • copier le contenu qui se trouve à une adresse donnée sur une autre adresse

    2- que ce soit sur la pile, dans le tas, ou où tu veux, tu ne dispose jamais que d'un espace mémoire limité, même si on peut remarquer de la mémoire cache, de la RAM et du swap (pour faire simple)

    3- Même si l'OS (et la machine virtuelle, s'il y en a une) y mettent leur grain de sel quant à la manière dont est gérée la mémoire, un objet apparait entier et à des adresse contigües en mémoire: tu ne vas pas avoir les deux premiers bytes d'un objet composé de 4 à une adresse 10 xxx xxx et les deux derniers à une adresse 15 xxx xxx... Cela n'aurait strictement aucun sens et obligerait l'ordinateur à travailler en quatre étapes au lieu de deux...

    Il est évident que, quand tu demande de réserver une certaine quantité de mémoire, la demande passe par "les mains" l'OS ou ou la machine virtuelle (qui dispose de mémoire... allouée par l'OS).

    Mais, quand tu demande de réserver un bloc important de mémoire et que cela échoue, cela ne veut absolument pas dire qu'il "n'y a plus de mémoire", mais bien qu'il "est impossible de trouver un bloc avec suffisamment d'adresses contigües", peut être parfois parce qu'il n'y a qu'un byte réservé qui traine quelque part...
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #23
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Je vais reprendre ce que dit Melem dans cette discussion et qui me semble la réponse la plus pertinente :
    -> Quand tu alloues un tableau de n octets, tu réserves une zone mémoire virtuelle continue de par exemple 0x1000 à 0x1000 + n.
    -> Physiquement tu as différents blocs, par exemple 2 : 0x1223 à 0x1223 + n/2 et 0x95FA à 0x95FA + n/2. Tant que tu adresses dans ton programme entre 0x1000 et 0x1000 + n/2, la MMU fait la translation vers [0x1223, 0x1223 + n/2]. Quand tu adresses [0x1000+n/2, 0x1000 + n], la MMU fait la translation vers [0x95FA, 0x95FA + n/2]. Quand le processeur demande à lire une donnée à l'adresse 0x1000 + i, la MMU fait la translation d'adresse, récupère la valeur dans la mémoire à l'adresse physique calculée et la retourne au processeur. C'est tout simplement le principe de la mémoire virtuelle.
    -> Ton programme n'a aucun accès aux adresses physiques.
    -> Les adresses physiques peuvent même varier au cours de l'exécution si les pages sont swappées.
    -> Seules les adresses virtuelles sont stables et connues. Le programme (et le compilateur lorsqu'il le génère) ne s'appuie que là-dessus.

  4. #24
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Tu viens de mettre toutes mes idées en ce qui concerne le compilateur à la corbeille; c'est sympa! C'est vrai même si j'en rigole. Et justement c'est bien por la discussion.

    Aucune de ces notions n'existent en C++ (i.e. dans la norme). Le C++ parle uniquement de la durée de vie des variables limitée au scope (qui correspondra à la pile) ou géré par le développeur avec new/delete (qui correspond au tas) ou sur la durée du programme.
    J'ai vu dans un livre récemment un partage de la mémoire en code, data (pile et tas,..) fourni à l'utilisateur et en évoquant le compilateur. L'os ne gère pas ce partage il se contente de mettre un grand switch dessus pour créer les processus et les gérer en pages,...et compagnie (sécurité, swap, ...).

    Ce sont des notions liées à l'O.S. Le compilateur se contente de traduire les exigences du langage dans l'architecture de l'O.S. cible.
    Maintenant, je ne connais pas d'O.S. qui n'aie pas une pile et un tas...
    Pas du tout! L'os fournit les plages mémoire au runtime qui gère.

    C'est pas tout à fait ça. Le langage C++ ne parle ni de segment code, ni de pile ni de tas. Tout ça c'est du ressort de l'O.S. Le compilateur traduit les instructions du langage C++ vers les mécanismes et l'architecture de l'O.S. cible. Par exemple, quand tu déclares une variable locale, le compilateur pour windows génère les instructions nécessaires pour allouer un espace suffisant et correctement aligné sur la pile et va adresser cet espace lorsque la variable est accédée. Lorsque tu déclares un tableau, la norme indique que les éléments doivent être contigues en mémoire. Cela signifie que &T[i]==T+i==reinterpret_cast<unsigned char*>(T) + i*sizeof(T[0]).
    A charge pour le compilateur de s'assurer que ce contrat sera rempli dans le programme généré. Mais même ceci est abstrait par le mécanisme de mémoire virtuelle. Si le tas est suffisamment grand, le process alloue le bloc mémoire et les adresses sont contigues. A charge de l'infrastructure de faire le mapping nécessaire entre mémoire virtuelle et mémoire physique pour que ça ait l'air de correspondre. Si physiquement et virtuellement cela correspond, et ben, le mapping est juste une translation. Sinon, la MMU(?) en traduisant l'adresse virtuelle ira chercher le bon bloc.
    Il faut séparer l'os du compilateur/runtime; il y a là une confusion du rôle de chacun. Je ne dis pas qu'ils ne communiquent pas entre programmes; mais chacun s'occupe de sa raison d'être. Le runtime demande par exemple des emplacements mémoire à l'os; si ces emplacements ne suffisent pas, le runtime redemendera des compléments; l'os ne voilà absolument rien, il se contente de fournir et être au courant de ce qui se passe pour servir de convoyeur vers le processeur (sécurité).
    L'immortalité existe, elle s'appelle connaissance

  5. #25
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Je vais reprendre ce que dit Melem dans cette discussion et qui me semble la réponse la plus pertinente :
    -> Quand tu alloues un tableau de n octets, tu réserves une zone mémoire virtuelle continue de par exemple 0x1000 à 0x1000 + n.
    -> Physiquement tu as différents blocs, par exemple 2 : 0x1223 à 0x1223 + n/2 et 0x95FA à 0x95FA + n/2. Tant que tu adresses dans ton programme entre 0x1000 et 0x1000 + n/2, la MMU fait la translation vers [0x1223, 0x1223 + n/2]. Quand tu adresses [0x1000+n/2, 0x1000 + n], la MMU fait la translation vers [0x95FA, 0x95FA + n/2]. Quand le processeur demande à lire une donnée à l'adresse 0x1000 + i, la MMU fait la translation d'adresse, récupère la valeur dans la mémoire à l'adresse physique calculée et la retourne au processeur. C'est tout simplement le principe de la mémoire virtuelle.
    -> Ton programme n'a aucun accès aux adresses physiques.
    -> Les adresses physiques peuvent même varier au cours de l'exécution si les pages sont swappées.
    -> Seules les adresses virtuelles sont stables et connues. Le programme (et le compilateur lorsqu'il le génère) ne s'appuie que là-dessus.
    Je suis entièrement d'accord avec ce que tu dis, et cela n'entre pas en conflit avec mon dernier message. Tu n'as parlé que de l'os et nul part tu n'as évoqué sa liaison avec les zones (code, data,..). Ce qui me parait bien puisque cela est une affaire en grande partie, encore une fois du compilateur/runtime.
    L'immortalité existe, elle s'appelle connaissance

  6. #26
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Points : 3 344
    Points
    3 344
    Par défaut
    Je ne suis pas sur de comprendre ce que tu entends par "runtime", on dirait que tu parles de la virtual machine qui execute l'application en JAVA. Si c'est bien ça, elle n'existe pas en C ni en C++. Ce que tu appelles "runtime" semble être l'application elle même, aussi ce que tu dis sur l'allocation n'est vrai que si ce comportement a été prévu par les développeurs de l'application.
    Je ne vois pas non plus pourquoi tu lies "compilateur/runtime"? Un compilateur fait son boulot "statiquement".

    On dirait qu'il y a un quiproquo a cause des termes utilisés ici.

  7. #27
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Citation Envoyé par wafiwafi Voir le message

    Pas du tout! L'os fournit les plages mémoire au runtime qui gère.
    T'es entrain de dire que du point de vue de l'os, un processus n'a pas de tas et de pile?


    ps : à mon avis on a un problème de vocabulaire comme la souligné klaim, qu'appelles-tu "runtime"?
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  8. #28
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Je ne suis pas sur de comprendre ce que tu entends par "runtime", on dirait que tu parles de la virtual machine qui execute l'application en JAVA
    Pas du tout, je parle d'un moteur d'exécution (bibliothèque dynamique, programme chargeur, ...et compagnie),de façon générale.

    Si c'est bien ça, elle n'existe pas en C ni en C++. Ce que tu appelles "runtime" semble être l'application elle même, aussi ce que tu dis sur l'allocation n'est vrai que si ce comportement a été prévu par les développeurs de l'application.
    Désolé de dire Non.
    Le développeur s'adapte au compilateur qui à son tour s'adapte à l'os et le matériel.

    je ne vois pas non plus pourquoi tu lies "compilateur/runtime"? Un compilateur fait son boulot "statiquement".
    Oui, mais le moteur d'exécution le fais en dynamique. Il n'ya pas que compilation!!


    T'es entrain de dire que du point de vue de l'os, un processus n'a pas de tas et de pile?
    Bien sûr qu'au sein d'un même processus il y a une organisation en code data (pile,tas,..). Le processus, considéré comme un objet, est géré par l'os. Mais rien n'empêche à ce qu'une certaine organisation soit prévu à l'avance, au sein même d'un processus, par le compilateur en statique et par le moteur d'exécution (si tu préfères) en dynamique. C'est tout le point que je souligne depuis le début (NE PAS MELANGER LES ROLES DE COMPILATEUR MOTEUR ET OS).

    Je peux me tromper sur certains points.
    Merci de votre participation.
    L'immortalité existe, elle s'appelle connaissance

  9. #29
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Oula, tu t'emmêle un peu !

    Un ordinateur, on peut y distinguer facilement 3 couche : Le matériel /Le kernel / L'applicatif. Note que cela est simplifié, mais c'est ce qui nous intéresse.

    Le materiel, c'est les truc un peu nié, ou tu as le processeur capable de faire des opération arithmétique fort simple, et des tas de puce et de porte, qui fait que si tu écris à certain bit d'adresse de la bonne façon, ça fait des truc "extra-ordinaire".

    Le kernel, c'est une couche qui donne des ordres au matériel, pour faire ces choses "extra-ordinaire". Il est surtout chargé de ordonnancement des tâches et de la gestion mémoire. Je distingue ça de l'OS, qui lui, fourni en plus plein d'outils pour utiliser le dit kernel. Mais il est pas faux de dire OS.

    Applicatif, qui est une série d'instruction qui va être fournie au kernel (presqu'à partir du main), pour être intégré à son ordonnanceur.

    [EDIT pour clarification] Tes barrettes de ram, c'est du physique, du matériel. Mais y accéder ne relève même pas du kernel, mais du dit MMU (encore heureux que le kernel n'est pas besoin ne prendre la main à chaque fois ><). Le kernel peut toutefois "trafiquer" le MMU pour faire des truc formidable. C'est aussi lui qui définit la "table" de ton programme. [/EDIT pour clarification]

    Après, toi et ton programme, vous ne pourrait voire que des adresses virtuelles. Si jamais cette adresse virtuelle ne correspond à rien pour le MMU, tu as du page-fault. Le kernel reprend la main est fait ce qu'il faut (charge depuis le swap, t'envoie bouler, etc...).


    Le fait de séparer data-segment et instruction-segment, c'est l'architecture d'Harvard, utilisé seulement dans les micro-controleur. C'est oldschool un peu quand même >< !

    La segmentation mémoire, c'est encore autre chose. La présence du MMU fait que ni toi ni le kernel est capable de garantir la contiguïté de tes données en mémoire physique.

    Après, le mieux c'est quand même de tout allouer d'un coup... Tu as plus de chance que tes données soit contigu ainsi. Bon, après, le fait qu'elle soit pas contigu, c'est pas trop-trop grave. Juste que tu risque d'augmenter tes minor-fault, et tu ne facilite pas la tache d'une potentielle mémoire cache...

    Bon, pour répondre à ta question :
    Ben c'est comme pour la création d'un objet. Si tu ne définit pas un autre opérateur new spécifique avec des arguments, ben tu n'aura que celui fait par défaut. Aussi, en réalité, la syntaxe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     type* p = new [] type(arg)
    Appelle l'opérateur type::new[](size_t,arg)... Qui n'est pas définit par défaut. De mémoire, il y en à trois de défini... Mais je n'en suis pas sur et ne sais plus trop desquelles il s'agit ...

    Au passage, comme le constructeur par défaut, si tu fait un new spécial, tu vas devoir tous les réécrire ><. Peut-être C++0x permettra d'y mettre le mot clef default ?

    PS : Les trois derniers paragraphes porte la mention "Pas sûr". Ce ne sont pas des trucs que je fais tous les jours ><...
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  10. #30
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Mais, je suis d'accord avec toi! Tu as parlé du côté OS, Matériel.. et ces rappels ne rentrent pas en conflit avec ce que je viens de dire.
    En gros, et je ne vais pas me répéter, quand tu compiles un programme, le compilateur prévoit uneorganisation de la mémoire du point de vue statique; certes ce sont des adresses fictives puisqu'à l'exécution, le moteur d'exécution (et en demandant à l'os) fait le nécessaire pour allouer des adresses en dur.
    Cette partie n'a rien à voir avec ce que tu viens d'expliquer!
    Le moteur d'exécution et l'os travaillent ensemble justement pour à la fois garantir une organisation de la mémoire à l'intérieur du processus (plus le moteur d'exécution) et la gestion du processus lui même (OS).

    Il est évident que ce soit le kernel ou le MMU... impose un fonctionnement et bien le processus lui même sera affecté et du coup son organisation interne (du point de vue mémoire) qui sera affecté (pagination, swap et compagnie...).
    Mais je suppose que ces incidents ne sont pas préjudiciables pour l'application.

    Désolé, je ne vois dans tout cela aucune confusion. Il y a peut être des choses à reprendre. Néanmoins, tout cela me parait clair et s'adapte, encore une fois avec ce que tu as dis.

    Le fait de séparer data-segment et instruction-segment, c'est l'architecture d'Harvard, utilisé seulement dans les micro-controleur. C'est oldschool un peu quand même ><
    Tu dis seulement? Une plate forme C++/... l'utilise!!
    Java l'utilise également mais en simple vision à l'utilisateur puisque la JVM reprend et fait ensuite à sa sauce.

    Bien à toi
    L'immortalité existe, elle s'appelle connaissance

  11. #31
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 505
    Points : 2 799
    Points
    2 799
    Par défaut
    Tu confonds langage et format exécutable.

    C++ n'a pas la notion de zone data/zone exec. Par contre, elf (par exemple) l'a.

    Comme ton compilateur fait le lien entre le langage et le format exécutable, il l'a aussi, mais dans sa partie génération de code, pas dans sa partie langage. Idem pour la notion pile/tas, elle ne fait pas partie du langage, même si je ne connais pas de compilateur c++ qui ne l'utilisent pas dans la partie génération de code.

  12. #32
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    ATTENTION, je ne parle pas du tout du langage lui même mais de la partie compilation et exécution. Je pensais être clair en ce point. Peut être que la confusion est introduite quand j'écris C++/...ALORS désolé.
    J'insiste sur le fait que je ne considère que ce qui se passe à la compilation/exécution!! La notion de CODE , DATA n'est pas une affaire de langage ni d'utilisateur. Néanmoins, il est utile de savoir ce qui se passe après quand ton programme s'envole pour être exécuté.
    L'immortalité existe, elle s'appelle connaissance

  13. #33
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Citation Envoyé par wafiwafi Voir le message
    Tu dis seulement? Une plate forme C++/... l'utilise!!
    Java l'utilise également mais en simple vision à l'utilisateur puisque la JVM reprend et fait ensuite à sa sauce.

    Bien à toi
    Je vois pas comment un logicielle utiliserait un principe d'architecture matérielle >< !

    Je suis pas sur du coup que tu parle d'Harvard... Par séparer, tu veux dire pas dans un segment contigu d'adresse virtuelle ?

    Je suppose que par "runtime" tu considère les routines d'entrées et de sortie de la table processus ? En réalité, dans un OS moderne, elle communique dynamiquement avec l'OS. C'est lui qui est chargé de tous, afin d'éviter de trop facile faille de sécurité. Donc j'ai quand même un peu de mal avec la vision que tu exposes. Dans tous les cas, l'application est asservie, et le "moteur d'exécution" ne travaille du début à la fin qu'avec des adresses virtuelles, et en mode user...

    Mais euh, sinon, l'explication ou je suis pas sûr, c'est ce que tu voulais savoir non ?

    [EDIT] Harvard c'est super "fort" comme principe. Actuellement, les machines utilisent plus du Harvard-like (séparation data-cache/instruction-cache, bus différent, etc...), mais pas du vrai harvard.
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  14. #34
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Je vois pas comment un logicielle utiliserait un principe d'architecture matérielle >< !
    Le compilateur est réalisé en tenant compte à la fois de l'os et du matériel, non?

    J
    e suis pas sur du coup que tu parle d'Harvard... Par séparer, tu veux dire pas dans un segment contigu d'adresse virtuelle ?
    Ce n'est pas moi qui a dis ça. J'ai juste répondu au message d'avant.

    En réalité, dans un OS moderne, elle communique dynamiquement avec l'OS. C'est lui qui est chargé de tous, afin d'éviter de trop facile faille de sécurité
    Le point essentiel est que le moteur d'exécution a un mot à dire en ce qui concerne la gestion des segments CODE, DATA,.. et met un gros switch sur le fichier compilé. Rien n'empêche l'OS, et je l'ai déjà dis, à mettre encore un autre gros switch je dirais, pour assurer l'aspect sécurité, et je l'ai déjà évoque également.

    Dans tous les cas, l'application est asservie, et le "moteur d'exécution" ne travaille du début à la fin qu'avec des adresses virtuelles, et en mode user...
    Entièrement d'accord! je ne dis pas le contraire; question de sécurité!! C'est normale, l'os gère et protège son processus. Néanmoins, il est au courant et il contrôle les accès (des ordres du moteur d'exécution) lors de l'exécution.

    Je ne comprends pas pourquoi veux tu que ça soit que l'os??
    Pourrais tu me dire ce qui choque?
    Merci
    L'immortalité existe, elle s'appelle connaissance

  15. #35
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Oui, reste que c'est indépendant du langage >< ! [EDIT] <= A propos d'Harvard.

    L'application n'as en aucun cas sont mot à dire pour ces différentes allocations...

    En gros, le truc, c'est que le runtime, c'est déjà ton application. Celle-ci à nécessairement besoin de s'initialiser, mais tu peux très bien le faire toi-même, instruction par instruction... (Je te préviens, c'est long, et c'est faisable qu'en assembleur).

    Avant que le programme de prenne la main, il y a en général du code qui est exécuté, demandé par une autre application (framework en générale). En gros, un processus va demandé l'exécution d'un autre. L'OS va lire l'entête et faire ce qu'il faut. Ensuite commence un échange entre le programme et l'OS.

    En faite, ce qui me choque le plus, c'est l'expression "moteur d'exécution". Soit on est dans l'OS, soit dans l'exécutable. Il n'y a rien entre les deux >< !
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  16. #36
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Oui, on est bien d'accord.

    En faite, ce qui me choque le plus, c'est l'expression "moteur d'exécution". Soit on est dans l'OS, soit dans l'exécutable. Il n'y a rien entre les deux >< !
    Je me suis peut être mal exprimé, et évidement qu'il n'y a rien entre les deux.
    Je voulais être précis dans la mesure où le moteur d'exécution est l'élément qui communique avec l'os lors de l'exécution. J'aurais, peut être, du raisonner tout simplement en disant la phase d'exécution( le moteur d'exécution fait partie de la phase d'execution). Il n.'y a pas que l'exécutable; il y a également la prise en charge de l'exécutable.
    C'est peut être une erreur de ma part; je ne sais pas.
    Bien à toi.
    L'immortalité existe, elle s'appelle connaissance

  17. #37
    Membre confirmé Avatar de Lavock
    Profil pro
    Inscrit en
    Octobre 2009
    Messages
    560
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2009
    Messages : 560
    Points : 633
    Points
    633
    Par défaut
    Citation Envoyé par Lavock Voir le message
    Bon, pour répondre à ta question :
    Ben c'est comme pour la création d'un objet. Si tu ne définit pas un autre opérateur new spécifique avec des arguments, ben tu n'aura que celui fait par défaut. Aussi, en réalité, la syntaxe :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     type* p = new [] type(arg)
    Appelle l'opérateur type::new[](size_t,arg)... Qui n'est pas définit par défaut. De mémoire, il y en à trois de défini... Mais je n'en suis pas sur et ne sais plus trop desquelles il s'agit ...

    Au passage, comme le constructeur par défaut, si tu fait un new spécial, tu vas devoir tous les réécrire ><. Peut-être C++0x permettra d'y mettre le mot clef default ?

    PS : Les trois derniers paragraphes porte la mention "Pas sûr". Ce ne sont pas des trucs que je fais tous les jours ><...
    Mais c'est quand même ça à la base le sujet >< ! Le mieux, ça serait qu'un membre plus expérimenté te confirme ça (ou que tu tâtonnes dans cette direction).

    [EDIT PS HS] "Bien à toi", c'est une expression bourguignonne ? Ça a quel sens ?
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  18. #38
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    Oui, c'est vrai. On s'est laisser aller vers une autre discussion. Néanmoins, je ne considère pas cela grave, bien au contraire.
    Mais bon, je vais mettre la tag résolu!
    L'immortalité existe, elle s'appelle connaissance

  19. #39
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    "Bien à toi", c'est une expression bourguignonne ? Ça a quel sens ?
    Non non pas vraiment. Veux tu qu'on ouvre un sujet de discussion? Je ne pense pas que tu y tiennes.
    Bien à toi
    L'immortalité existe, elle s'appelle connaissance

  20. #40
    Membre averti
    Avatar de wafiwafi
    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    500
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 500
    Points : 328
    Points
    328
    Par défaut
    C'est une expression normande! je vis à cette région.
    L'immortalité existe, elle s'appelle connaissance

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 3 PremièrePremière 123 DernièreDernière

Discussions similaires

  1. applet et constructeur sans argument
    Par new_wave dans le forum Applets
    Réponses: 2
    Dernier message: 09/05/2012, 09h58
  2. Pas de compilation sans constructeur sans argument!
    Par bertry dans le forum Débuter
    Réponses: 3
    Dernier message: 28/12/2011, 12h33
  3. Réponses: 19
    Dernier message: 13/12/2010, 21h24
  4. Signature d'une fonction sans argument
    Par cj227854 dans le forum C++
    Réponses: 5
    Dernier message: 20/10/2005, 18h01
  5. Réponses: 5
    Dernier message: 04/11/2004, 16h36

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