That still seems strange. The generated code explicitly refers to
::std::string, so it couldn't be using your type. So, it must be that your
compiler is misinterpreting the reference to "string" in
generated_message_util.h. It seems to be picking up your "string" from the
global scope before it finds the one in google::protobuf (which imports it
from std via "using namespace std"). This seems like a compiler bug,
although most things that seem like compiler bugs turn out to be unexpected
effects of C++'s over-complicated language spec.
On Tue, Sep 21, 2010 at 1:49 PM, Anand Ganesh
<anantharamangan...@gmail.com>wrote:
> 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<protobuf%2bunsubscr...@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.
