[Boost.Log] try_lock_shared is not member of light_rw_mutex

Version imprimable

Bonjour

Je bosse sur un framework pour lequel je cherche a refactorer les logs pour remplacer la lib existante (maison), par quelque chose qui me permette de faire du multithreading (et éviter d'avoir des entremêlements de logs).
Le framework utilisant déjà boost par ailleurs, j'ai donc travaillé autour de Boost.Log.

J'ai donc une classe dans une DLL déclarée comme suit:

Code:

1
2
3
4
5
6
 
class __declspec(dllexport) BoostLogger: public virtual boost::log::sources::severity_logger_mt < LoggerType >
{
public:
// features
};

Cette classe est donc intégrée au sein d'une DLL utilisée par le framework.
Or lors de la compilation j'ai le message d'erreur suivant:

Code:

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
cots\boost-1.57.0\include\boost-1_57\boost/log/sources/threading_models.hpp(75) : error C2039: 'try_lock_shared' : is not a member of 'boost::log::v2_mt_nt5::aux::light_rw_mutex'
        cots\boost-1.57.0\include\boost-1_57\boost/log/detail/light_rw_mutex.hpp(180) : see declaration of 'boost::log::v2_mt_nt5::aux::light_rw_mutex'
        cots\boost-1.57.0\include\boost-1_57\boost/log/sources/threading_models.hpp(75) : while compiling class template member function 'bool boost::log::v2_mt_nt5::sources::multi_thread_model<MutexT>::try_lock_shared(void) const'
        with
        [
            MutexT=boost::log::v2_mt_nt5::aux::light_rw_mutex
        ]
        cots\boost-1.57.0\include\boost-1_57\boost/log/sources/basic_logger.hpp(81) : see reference to class template instantiation 'boost::log::v2_mt_nt5::sources::multi_thread_model<MutexT>' being compiled
        with
        [
            MutexT=boost::log::v2_mt_nt5::aux::light_rw_mutex
        ]
        cots\boost-1.57.0\include\boost-1_57\boost/log/sources/severity_feature.hpp(147) : see reference to class template instantiation 'boost::log::v2_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>' being compiled
        with
        [
            CharT=char,
            FinalT=boost::log::v2_mt_nt5::sources::severity_logger_mt<MyLogLevel>,
            ThreadingModelT=boost::log::v2_mt_nt5::sources::multi_thread_model<boost::log::v2_mt_nt5::aux::light_rw_mutex>
        ]
        cots\boost-1.57.0\include\boost-1_57\boost/log/sources/basic_logger.hpp(318) : see reference to class template instantiation 'boost::log::v2_mt_nt5::sources::basic_severity_logger<BaseT,LevelT>' being compiled
        with
        [
            BaseT=boost::log::v2_mt_nt5::sources::basic_logger<char,boost::log::v2_mt_nt5::sources::severity_logger_mt<DA::ILogger::Type>,boost::log::v2_mt_nt5::sources::multi_thread_model<boost::log::v2_mt_nt5::aux::light_rw_mutex>>,
            LevelT=MyLogLevel
        ]
        cots\boost-1.57.0\include\boost-1_57\boost/log/sources/severity_logger.hpp(74) : see reference to class template instantiation 'boost::log::v2_mt_nt5::sources::basic_composite_logger<CharT,FinalT,ThreadingModelT,FeaturesT>' being compiled
        with
        [
            CharT=char,
            FinalT=boost::log::v2_mt_nt5::sources::severity_logger_mt<MyLogLevel>,
            ThreadingModelT=boost::log::v2_mt_nt5::sources::multi_thread_model<boost::log::v2_mt_nt5::aux::light_rw_mutex>,
            FeaturesT=boost::log::v2_mt_nt5::sources::features<boost::log::v2_mt_nt5::sources::severity<MyLogLevel>>
        ]
        src\logger\my_boost_logger.h(29) : see reference to class template instantiation 'boost::log::v2_mt_nt5::sources::severity_logger_mt<LevelT>' being compiled
        with
        [
            LevelT=MyLogLevel
        ]

Lorsque j'enlève le __declspec(), la librairie compile normalement, par contre, les autres libs ne lienkent par (normal).

Des idées sur le pkoi d'un comportement différent selon que l'on ait le declspec() ou non ?
Y-a-t-il un define à faire ou autre ?

merci

01/03/2017, 11h34
bacelar

Sauf erreur de ma part tous ces bricolages à base de "__declspec" sont spécifiques à VC++.

Votre question montre que vous ne maitrisez pas du tout ce qu'est une Dll. 8O

"__declspec(dllexport)" c'est pour indiquer au compilateur d'exporter tout le bordel de la classe (ses symboles), que cela soit une Dll ou un exécutable.
Oui, un exécutable peut exporter des trucs, exactement comme une Dll.
(Les exports C++, c'est de la merde, mais bon, c'est vous qui voyez. :aie:)

Si vous voulez utiliser les choses exportés et non les exporter, c'est "__declspec(dllimport)" qu'il faut utiliser.

Citation:

Y-a-t-il un define à faire ou autre ?

Si vous avez utilisé le template de projet de Visual Studio pour créer un projet de Dll, ce #define qui fait la bascule entre "__declspec(dllexport)" et "__declspec(dllimport)" existe déjà.
Il ne faudra donc pas utiliser directement "__declspec(dllexport)" mais un define de la forme "MACHINTRUC_API" à la place (cf. le header généré par VS à la création du projet Dll).
01/03/2017, 16h06
Rupella

Bonjour

Merci d'avoir pris le temps de répondre.
Malheureusement, le point ne concerne pas le fait de savoir ce que sont dllimport ou dllexport.
pour ma part, je pense en savoir suffisamment à ce sujet.
J'ai voulu la faire courte mais, visiblement j'ai trop raccourci les choses.

la classe est normalement déclarée avec une macro dépendante du compilateur (GCC/MSVC) de la façon suivante:

Code:

class LIB_MISC BoostLogger...

La valeur de cette macro dépend du compilo, du fait si on est en train de compiler la librairie en question...
Dans le cas présent, sa valeur est vide, rien, nada.
Ce mécanisme est éprouvé depuis...

Ma question portait plus sur savoir pourquoi diable se met-il à choisir un modele de mutex dont il sait qu'il ne conviendra pas ?

Merci
01/03/2017, 16h35
bacelar

Ok, on utilise donc la MACRO "LIB_MISC".

Il y a donc une customisation via constante de compilation qui s'applique à tous les fichiers, les fichiers d'en-tête de Boost compris.

Montrez-nous les extraits de ces en-tête qui donnerait tort au compilateur.
En particulier la déclaration de "try_lock_shared" dans "boost::log::v2_mt_nt5::aux::light_rw_mutex".

Je pense que ces constantes de compilation ont une influence sur ce type de déclarations.
01/03/2017, 17h05
Bousk

D'après l'erreur tu utilises quelque part un boost::log::v2_mt_nt5::aux::light_rw_mutex en argument template alors qu'il ne possède pas de méthode try_lock_share.
Je doute que l'erreur soit dans Boost même mais probablement dans ton code.

Bonjour

Je reviens sur le sujet, j'ai été assez pris sur d'autres... :(

en fait, la déclaration utilisée dans mon cas est cette de boost/log/sources/severity_logger.hpp:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #ifndef BOOST_LOG_DOXYGEN_PASS #ifdef BOOST_LOG_USE_CHAR ... #if !defined(BOOST_LOG_NO_THREADS) //! Narrow-char thread-safe logger with severity level support template< typename LevelT = int > class severity_logger_mt : public basic_composite_logger< char, severity_logger_mt< LevelT >, multi_thread_model< boost::log::aux::light_rw_mutex >, features< severity< LevelT > > > { ... }; #endif // !defined(BOOST_LOG_NO_THREADS)
par contre, plus loin, si la macro BOOST_LOG_DOXYGEN_PASS est définie, la classe utilisée est différente:
Code:

1 2 3 4 5 6 7 8 9 10 template< typename LevelT = int > class severity_logger_mt : public basic_composite_logger< char, severity_logger_mt< LevelT >, multi_thread_model< implementation_defined >, features< severity< LevelT > > > { };
Je continue à investiguer. :aie:
Si vous avez des remarques, n'hésitez pas, hein ?! :mrgreen:

10/03/2017, 14h16
bacelar

Moi, je pense à une incompatibilité dans les constantes de compilation.
Pensez à utiliser l'option /P de MSVC ou l'équivalent avec GCC (-E je crois), pour avoir le résultat du pre-processing et ne pas se noyer dans les #ifdef.

Citation:

Montrez-nous les extraits de ces en-tête qui donnerait tort au compilateur.
En particulier la déclaration de "try_lock_shared" dans "boost::log::v2_mt_nt5::aux::light_rw_mutex".

(BIS) :aie: