Toute question d'un PROFI à un SUPER PROFI - 1. - page 28

Nouveau commentaire
  
    // 2.2.6. Метод меняет размер отведённой памяти для файлового отображения. Метод в случае успешного завершения возращает TRUE или FALSE в случае ошибки.
    bool Resize(const DWORD64 dw64BytesMapping) // Количество резервируемой памяти для файлового отбражения.
     {
      DWORD         dwErrorCode = 0; // Последняя ошибка.
      tstringstream ssExclusion;     // Строка с сообщением об ошибке.
      dw64Bytes = dw64BytesMapping;
      ::SetLastError(0); // Сбрасываем последнюю ошибку.
      // Контроллируем на наличие дескриптора файла и имени файлового отображения.
      if (hFile == NULL && sName == _T(""))
       {
        if (DEBUGGING || DEBUGGING_EXCLUSION)
         {
          ssExclusion << std::endl << _T("Ошибка в методе \"Utils::MappingSTL::Resize()\".")
                      << std::endl << _T("Отсутствуют дескриптор пользовательского")
                      << std::endl << _T("файла и имя файлового отображения.") << std::endl;
          if (DEBUGGING) tcout << ssExclusion.str();
          if (DEBUGGING_EXCLUSION) throw(ssExclusion.str());
         }
        return(false);
       }
      // Создаем или открываем уже существующее отображение файла по дескриптору пользовательского файла.
      vhMapping.push_back(::CreateFileMapping(hFile, NULL, PAGE_READWRITE, Utils::FILESIZE64(dw64Bytes).dwSizeHigh, Utils::FILESIZE64(dw64Bytes).dwSizeLow, sName.c_str()));
      // Если получен не верный указатель на файловое отображение.
      if (vhMapping.back() == NULL)
       {
        if (DEBUGGING || DEBUGGING_EXCLUSION)
         {
          dwErrorCode = ::GetLastError(); // Получаем последнюю ошибку.
          ssExclusion << std::endl << _T("Ошибка в методе \"Utils::MappingSTL::Resize()\".")
                      << std::endl << _T("Размер памяти файлового отображения \"") << sName << _T("\" не изменён.")
                      << std::endl << LAST_ERROR_PARAMETER(dwErrorCode) << std::endl;
          if (DEBUGGING) tcout << ssExclusion.str();
          if (DEBUGGING_EXCLUSION) throw(ssExclusion.str());
         }
        return(false);
       }
      return(true);
     }
Il s'agit d'une méthode de la classe de cartographie.
 
Zhunko:
C'est une méthode d'une classe de cartographie.

Et alors ?

Le sujet du redimensionnement des cartes n'est pas abordé.

 
C'est ce que je fais.
 
Zhunko:
C'est ce que je fais.

C'est-à-dire que lorsque vous ouvrez une cartographie avec le même nom et une taille différente, elle change de taille ?

Vous n'avez pas à répondre, ce n'est pas dans le code de toute façon. Ce que vous y faites n'a pas grand-chose à voir avec la question :) alors bonne chance.

 

Bien sûr que oui. J'ai une bibliothèque sur cette classe qui fonctionne. Les tests sont bons. La première variante de cette bibliothèque se trouve dans la tirelire.

La dernière version de la bibliothèque elle-même change de taille en fonction des besoins.

 
TheXpert:

Donc, lorsque vous ouvrez une cartographie avec le même nom et une taille différente, elle change de taille ?

Vous n'avez pas à répondre, ce n'est pas ce qui est dans le code de toute façon. Ce que vous y faites n'a pas grand-chose à voir avec la question :) alors bonne chance.

Andrew, j'ai revérifié de deux façons.

Eh bien, oui. Lorsque vous appelez CreateFileMapping avec le même nom mais avec une taille plus importante, la mémoire est étendue.
L'essentiel est que le premier handle de CreateFileMapping ne soit pas fermé (pour éviter de perdre le contenu précédent).


Mais ! Dans le second cas, j'ai testé une hypothèse plus intéressante.

Un CreateFileMapping est créé avec une taille initiale (par exemple 2 octets) et 4 octets y sont écrits. Et il s'étend automatiquement !

Il n'est donc pas nécessaire de créer une deuxième poignée CreateFileMapping avec une taille plus grande.

Je pense que la question est close.
 
sergeev:

Mais ! Le deuxième cas a testé l'hypothèse de manière plus intéressante.

CreateFileMapping est créé avec une taille initiale (par exemple, 2 octets) et 4 octets y sont écrits. Et il s'étend automatiquement !

Il n'est donc pas nécessaire de créer une deuxième poignée CreateFileMapping de taille supérieure.

Je pense que la question est close.
C'est dans la description. C'est pratique, mais ça ne fait qu'augmenter en taille. Consomme des ressources. Vous devez créer votre propre gestionnaire de mémoire.
 
Zhunko:
C'est dans la description.

Dans la description de quoi ? C'est ce dont j'ai besoin pour faire travailler ma mémoire.
 
sergeev:

Dans la description de quoi ? J'ai besoin qu'il soit libéré.

MSDN :-))

Je veux dire que si la consommation de mémoire augmente, vous devez prévoir sa libération.

 
lors de la fermeture d'un handle, la mémoire (qui a été allouée au-delà de celle spécifiée dans CreateFileMapping) n'est-elle pas récupérée ?
1...212223242526272829303132333435...45
Nouveau commentaire