2015-10-30 2 views
0

I ont un objet fonctionnel que j'utilise comme corps pour multifunction_node:Problèmes avec objet imbriqué dans l'objet fonctionnel du TBB :: :: flux graphique

class module 
{ 
private: 
    bool valid; 

    QString description; 

    bool hasDetectionBranch; 
    tDataDescription bufData; 

    void* dllObject; //<-- This is a pointer to an object constructed with help of the external dll 

    qint64 TimeOut; 

public: 

    module(const QString& _ExtLibName); 
    virtual ~module(); 

    void operator() (pTransmitData _transmitData, multi_node::output_ports_type &op); 
}; 

« dllObject » est créée au moment de la construction de l'objet 'module':

module::module(const QString& _ExtLibName) : 
    valid(true), hasDetectionBranch(false) 
{ 
    GetObjectDescription = (tGetObjectDescription)QLibrary::resolve(_ExtLibName, "GetObjectDescription"); 
    CreateObject = (tCreateObject)QLibrary::resolve(_ExtLibName, "CreateObject"); 
    DestroyObject = (tDestroyObject)QLibrary::resolve(_ExtLibName, "DestroyObject"); 

    if (!CreateObject || !DestroyObject || !GetObjectDescription) 
     valid = false; 
    else 
    { 
     description = QString(GetObjectDescription()); 
     dllObject = CreateObject(); 
    } 
} 

Et ceci est quand 'dllObject' est détruite:

module::~module() 
{ 
    if (valid) 
    { 
     DestroyObject(dllObject); 
    } 
} 

J'ai construit un petit graphique :

void MainWindow::goBabyClicked(void) 
{ 
    module mod(QString("my.dll")); //<-- Here is OK and mod.dllObject is correct 
    if (!mod.isValid()) 
    { 
     qDebug() << "mod is invalid!\n"; 
     return; 
    } 

    first fir(input); 
    folder fol(QString("C:/out"), 10000); 

    graph g; 

    source_node<pTransmitData> src(g, fir, false); 

    multi_node mnode(g, tbb::flow::serial, mod); //<-- WTF? ~module() is executed! 

    function_node<pTransmitData> f(g, tbb::flow::serial, fol); 

    make_edge(src, mnode); 
    make_edge(mnode, f); 

    src.activate(); 

    g.wait_for_all(); 
} 

J'ai donc 2 questions: 1) Pourquoi ~ module() est exécutée et comment empêcher cela? 2) Comment conserver correctement le pointeur de l'objet imbriqué?

MISE À JOUR Ajout du code factice pour empêcher la destruction dllObject à la première fois comme:

bool b = false; 
module::~module() 
{ 
    if (valid && b) 
    { 
     DestroyObject(dllObject); 
    } 
    if (!b) 
     b = true; 
    valid = false; 
} 

Maintenant, il fonctionne comme prévu, mais semble laid:/

+0

Qu'est-ce 'multi_node'? Je ne suis pas familier avec TBB Flow Graph mais j'ai essayé de le chercher. La classe avec le nom le plus proche que j'ai trouvé était ['multifunction_node'] (https://www.threadingbuildingblocks.org/docs/help/index.htm) ... –

Répondre

1

Max,

Je suppose que vous avoir un typedef de multi_node qui est similaire à celui de l'exemple du manuel de référence.

Le constructeur de la multifunction_node a la signature suivante:

multifunction_node(graph &g, size_t concurrency, Body body); 

L'objet de corps est copié lors de la transmission des paramètres et également au cours de la construction du noeud, donc il y a deux copies de mod créées au cours de la construction (en fait trois, comme une copie initiale du corps est également stockée pour ré-initialiser le corps lors de l'appel reset() avec rf_reset_bodies). Les appels de destructeur que vous voyez sont probablement ceux utilisés pour détruire les copies.

L'objet body doit également avoir un constructeur de copie défini ou être capable d'accepter le constructeur default-copy pour faire des copies du corps. Je pense que le QString a un constructeur de copie défini, mais je ne sais pas sur les champs comme tDataDescription. (Je pensais que nous avions couvert les exigences de base pour les objets Body dans le Manuel de référence, mais je suis toujours à la recherche de la section.) Dans tous les cas, la classe Body doit être CopyConstructible, car elle est copiée plusieurs fois.

Cordialement, Chris

+0

Mike a trouvé la référence; C'est dans le Guide de référence, sous le diagramme de flux, la page sur multifunction_node qui a les exigences pour le corps. Il est répété pour continue_node, function_node et source_node, les nœuds qui utilisent le corps. – cahuson