J'ai remarqué que lorsque j'utilise xp :: sregex :: compile dans mon code, la chaîne ... \ 3rdparty \ boost-1_58 \ boost/xpressive/detail/core/matcher/regex_byref_matcher.hpp (avec mon chemin local) apparaît dans le code binaire, compilé dans les mods de version. Y a-t-il un moyen de l'enlever?chemin de regex_byref_matcher.hpp lors de l'utilisation de xp :: sregex :: compile
1
A
Répondre
1
Ceci est sans aucun doute lorsque le code utilise __FILE__
pour obtenir de beaux messages d'affirmation/d'exception.
Le seul endroit où Xpressive utilise est directement regex_error.hpp
:
#define BOOST_XPR_ENSURE_(pred, code, msg) \
boost::xpressive::detail::ensure_(!!(pred), code, msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__) \
/**/
Vous pouvez facilement pirater être
#include <boost/xpressive/regex_error.hpp>
#undef BOOST_XPR_ENSURE_
#define BOOST_XPR_ENSURE_(pred, code, msg) \
boost::xpressive::detail::ensure_(!!(pred), code, msg, BOOST_CURRENT_FUNCTION, "(source-hidden)", __LINE__) \
/**/
Gardez à l'esprit:
- les besoins de pirater pour aller avant tout autre Xpressive inclut
- cela limite l'utilité des messages, si elles se produisent
- il y a une possibilité que l'une des bibliothèques qui Xpressive dépend utilise des constructions similaires
s'il vous plaît poster un [SSCCE] (http: // sscce.org/)/[MCVE](http://stackoverflow.com/help/mcve) – sehe
Merci, ça a du sens, je l'ai essayé mais je reçois toujours le chemin de regex_byref_matcher.hpp dans le binaire, et je ne fais pas t voir la chaîne "source-hidden" à la place. En outre, il compilé avec succès seulement avec l'undef, donc il n'a pas vraiment répondre à cette macro. – user3136169
Je suis un peu confus maintenant. L'avez-vous résolu? – sehe