Daniel Richard G. wrote: > On Fri, 2007 Jul 20 12:16:47 -0700, Craig Silverstein wrote:
>
>> } PCRECPP_EXP_DEFN should not be defined in more than one place, as
>> } that is generally bad practice.
>>
>> Do you mean the code shouldn't be in more than place, or the compiler
>> (preprocessor) shouldn't be evaluating that code in more than one
>> place?
>>
>
> I meant the first, though the second also applies.
>
>
>> In the former, we already have it in two places, right -- once in
>> pcre.h (or pcre_internal.h), and once in pcrecpp.h. If the latter,
>> that's why we're expanding the #if guard.
>>
>
> Each library (pcre vs. pcreposix vs. pcrecpp) needs its own set of export
> directives, because they need to be set independently of each other. For
> example, when compiling pcrecpp, PCRECPP_EXP_DEFN should be
> __declspec(dllexport), but PCRE_EXP_DEFN has to be __declspec(dllimport)---
> as pcrecpp needs to import symbols from pcre, but also export its own
> symbols.
>
>
>> } , how about breaking out the PCRECPP_EXP_DEFN definitions into a
>> } separate "private" header file, to be referenced only by the pcrecpp
>> } headers themselves?
>>
>> We could, but then we'd need to install that file -- or rather, the
>> users would. In general, I like to keep the need-to-install header
>> files down to as small a count as possible.
>>
>
> I suppose we could put the PCRECPP_EXP_DEFN definitions in pcre.h, if it's
> kosher for pcre_stringpiece.h et al. to pull in that header.
>
>
> --Daniel
>
>
> I wonder if this discussion has any bearing on the fact the pattern
callouts stopped working in our application with pcre 7.2 (using shared
library configured with heap for recursion, Windows). Worked with 7.0
and 7.1. Now the application crashes when PCRE should be accepting the 0
or 1 result from the callout.
