Thanks Kenton. I was meaning to update the discussion group this
morning about what I found but I got caught up with something.

Yes, we have another symbol called "string" in our code (our own
implementation of something wrapping a char *; not a class) and if we
include the header file containing the definition for our string
before we include the pb.h file in any source-file (e.g. myfile.c)
then the compilation fails because the signatures get generated
differently. I am still to find out what *exactly* happens underneath
the covers when we invoke the proto-compiler to generate the pb.h and
pb.c files and why AttrCompareList_AttrCompareListType_Parse() and
ParseNamedEnum() should generate different signatures, but I'll get to
that sometime later.

Reversing the order of includes fixed the problem.

Thanks again for taking the time.

Regards,
Anand

On 21 September 2010 12:32, Kenton Varda <ken...@google.com> wrote:
> Both "string"s should be referring to the same type.  google::protobuf has
> "using namespace std;" (terrible, I know, it's a long story), so when
> google::protobuf::internal::ParseNamedEnum declares its parameter to be
> "const string&", that "string" should resolve to "std::string".  So I'm not
> sure how this problem could be coming about -- and I've never heard this
> reported before.
> Are you declaring anything called "string" in your code?  It's not supposed
> to matter, but maybe there's a problem I'm missing.
>
> On Mon, Sep 20, 2010 at 7:31 PM, Anand Ganesh <anantharamangan...@gmail.com>
> wrote:
>>
>> Hello,
>>
>> I am getting the following error when I compile my project (myproj) on
>> Windows 64-bit:
>> ------------------------------------------------------------
>> cl /nologo /MDd /Od /Z7 /TP /DEBUG /D"_DEBUG"  -DNOI18N  -
>> DPLAT_ENDIAN=LITTLE_ENDIAN -DPLAT_ISA=64 -DPLAT_OS=WINDOWS -
>> D__WINDOWS__ -DWIN32    -DAPR_DECLARE_STATIC  -DAPU_DECLARE_STATIC -
>> DAPI_DECLARE_STATIC -WX -EHsc -TP  -I../../../src/include -I../../../
>> extern/INSTALL/Windows-x86_64/include /FoOBJ/Windows-x86_64/myfile.o -
>> c myfile.c
>> myfile.c
>> c:\myproj\src\include\policy.pb.h(58) : error C2664: 'bool
>>
>> google::protobuf::internal::ParseNamedEnum<MyProjPolicy::AttrCompareList_AttrCompareListType>(const
>> google::protobuf::EnumDescriptor *,const string &,EnumType *)' :
>> cannot convert parameter 2 from 'const std::string' to 'const string
>> &'
>>        with
>>        [
>>            EnumType=MyProjPolicy::AttrCompareList_AttrCompareListType
>>        ]
>>        Reason: cannot convert from 'const std::string' to 'const
>> string'
>>        No user-defined-conversion operator available that can perform
>> this conversion, or the operator cannot be called
>> ------------------------------------------------------------
>>
>> policy.pb.h: 58: contains --
>>
>> 55 inline bool AttrCompareList_AttrCompareListType_Parse(
>> 56     const ::std::string& name, AttrCompareList_AttrCompareListType*
>> value) {
>> 57
>> return
>> ::google::protobuf::internal::ParseNamedEnum<AttrCompareList_AttrCompareListType>(
>> 58     AttrCompareList_AttrCompareListType_descriptor(), name, value);
>> 59 }
>>
>> Seems like AttrCompareList_AttrCompareListType_Parse() was generated
>> with the 'name' parameter to be 'const ::std::string&' but seems like
>> ParseNamedEnum()'s second parameter takes 'const string &'.
>>
>> policy.pb.h was generated from policy.proto and it has just started
>> complaining after I started using extensions inside policy.proto.
>>
>> <snip>
>> message PolicyMsg {
>>            // .. many different fields
>> }
>>
>> extend MsgInOtherFile {
>>             repeated PolicyMsg foo = 100;
>> }
>> </snip>
>>
>> I have tried to check my compiler settings, etc. but I am not able to
>> make progress. Since the signatures for both
>> AttrCompareList_AttrCompareListType_Parse() and ParseNamedEnum() are
>> both generated by the proto-compiler, I figured I'll post this on the
>> group before continuing my investigations.
>>
>> Any help would be great.
>>
>> Thanks,
>> - Anand
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To post to this group, send email to proto...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> protobuf+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/protobuf?hl=en.
>>
>
>



-- 
Sent from my old desktop computer

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to