Eine Möglichkeit, die Warnung C4251 bei Verwendung von STL-Klassen in der DLL-Schnittstelle zu beseitigen

Question

Es ist keine gute Übung, STL-Klassen in der DLL-Schnittstelle zu verwenden, wie Common practice in dealing with warning c4251: class … needs to have dll-interface erklärt. Ein Beispiel dafür ist gegeben:

#include <iostream> 
#include <string> 
#include <vector> 


class __declspec(dllexport) HelloWorld 
{ 
public: 
    HelloWorld() 
    { 
     abc.resize(5); 
     for(int i=0; i<5; i++) 
      abc[i] = i*10; 

     str="hello the world"; 
    } 
    ~HelloWorld() 
    { 

    } 

    std::vector<int> abc; 
    std::string str; 

}; 

Wenn diese Datei zu kompilieren, können die folgenden Warnhinweise zu beachten:

warning C4251: 'HelloWorld::str' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'HelloWorld'  
warning C4251: 'HelloWorld::abc' : class 'std::vector<_Ty>' needs to have dll-interface to be used by clients of class 'HelloWorld' 

Dann ist die Frage, wie wir die gleiche Funktionalität Vektor und String ohne STL-Klasse implementieren kann. Eine Implementierung ich denken konnte, ist wie folgt:

class __declspec(dllexport) HelloWorld2 
{ 
public: 
    HelloWorld2() 
    { 
     abc_len = 5; 
     p_abc = new int [abc_len]; 
     for(int i=0; i<abc_len; i++) 
      p_abc[i] = i*10; 

     std::string temp_str("hello_the_world"); 
     str_len = temp_str.size(); 
     p_str = new char[str_len+1]; 
     strcpy(p_str,temp_str.c_str()); 
    } 
    ~HelloWorld2() 
    { 
     delete []p_abc; 
     delete []p_str; 
    } 

    int *p_abc; 
    int abc_len; 
    char *p_str; 
    int str_len; 



}; 

Wie Sie sehen können, in der neuen Implementierung wir int * p_abc verwenden Vektor abc und char * z_str zu ersetzen String str zu ersetzen. Die Frage, die ich habe, ist, ob es andere elegante Implementierungsansätze gibt, die dasselbe tun können. Vielen Dank!

Answer 1

Ich glaube, Sie mindestens drei mögliche Optionen haben, dieses Problem zu lösen:

• Sie könnten noch STL/Template-Klassen für Ihre Felder halten und sie auch als Parametertypen verwenden, solange Sie halte alle Felder privat (was sowieso eine gute Praxis ist). Here ist eine Diskussion darüber. Um die Warnungen zu entfernen, können Sie einfach #pragma Anweisungen verwenden.

• Sie könnten kleine Wrapper-Klassen mit privaten STL-Feldern erstellen und Felder Ihrer Wrapper-Klassen-Typen stattdessen der Öffentlichkeit zugänglich machen, aber dies würde höchstwahrscheinlich nur die Warnungen an andere Stellen verschieben.

• Sie können das PIMPL Idiom verwenden, um Ihre STL-Felder in einer privaten Implementierungsklasse zu verbergen, die nicht einmal aus Ihrer Bibliothek exportiert wird oder außerhalb davon sichtbar ist.

• Oder Sie könnten eigentlich alle erforderlichen Template-Klasse Spezialisierungen exportieren, wie sie in der C4251 Warnung vorgeschlagen, in einer Weise, die here beschrieben. Kurz gesagt würden Sie folgende Codezeilen vor Ihrer HelloWorld Klasse einzufügen haben:

  ... 
  #include <vector> 
  
  template class __declspec(dllexport) std::allocator<int>; 
  template class __declspec(dllexport) std::vector<int>; 
  template class __declspec(dllexport) std::string; 
  
  class __declspec(dllexport) HelloWorld 
  ... 
  

  By the way, scheint die Reihenfolge dieser Ausfuhren wichtig: die Vektor-Klasse-Vorlage die allocator Klassenvorlage intern verwendet, so dass die Zuweisungsinstanziierung muss vor der Vektor Instanziierung exportiert werden.

• Die direkte Nutzung von intrinsics ist wahrscheinlich die schlechteste Option, aber wenn Sie Ihre Felder

  int *p_abc; 
  int abc_len; 
  

  in so etwas wie class MyFancyDataArray und die Felder kapseln

  char *p_str; 
  int str_len; 
  

  in so etwas wie class MyFancyString, dann diese wäre eine anständige Lösung (ähnlich der im zweiten Punkt beschriebenen). Aber es ist wahrscheinlich nicht die beste Angewohnheit, das Rad zu oft neu zu erfinden.

Answer 2

Verwenden Sie einfach Pointer To Implementation (pImpl) idiom.

Answer 3

OR tun, um die einfachste Sache zu tun, bewegen Sie die __declspec die nur Mitglieder Sie exportieren Pflege:

class HelloWorld 
{ 
public: 
    __declspec(dllexport) HelloWorld() 
    { 
     abc.resize(5); 
     for(int i=0; i<5; i++) 
      abc[i] = i*10; 

     str="hello the world"; 
    } 
    __declspec(dllexport) ~HelloWorld() 
    { 
    } 
    std::vector<int> abc; 
    std::string str; 
}; 

Answer 4

Ich bin nicht sicher, welches Problem Sie hier lösen wollen. Es gibt zwei verschiedene Probleme: Cross-Compiler-Binärkompatibilität und Vermeidung von Link-Fehlern "undefined Symbol". Die C4251-Warnung, die Sie zitiert haben, spricht über das zweite Problem. Was ist wirklich ein Nicht-Problem, vor allem mit SCL-Klassen wie std::string und std::vector. Da sie in der CRT implementiert werden, solange beide Seiten Ihrer Anwendung die gleiche CRT verwenden, wird alles "nur funktionieren". Die Lösung ist in diesem Fall, nur die Warnung zu deaktivieren.

Cross-Compiler-Binärkompatibilität OTOH, was in der anderen Stackoverflow-Frage besprochen wird, ist ein ganz anderes Biest. Damit das funktioniert, müssen Sie im Grunde alle Ihre öffentlichen Header-Dateien frei von jeglicher Erwähnung irgendeiner SCL-Klasse halten. Das heißt, Sie müssen entweder alles PIMPL oder abstrakte Klassen überall verwenden (oder eine Mischung daraus).