This is what my generated_message_reflection.h file contains:

==============================
// Helper for EnumType_Parse functions: try to parse the string 'name'
as an
// enum name of the given type, returning true and filling in value on
success,
// or returning false and leaving value unchanged on failure.
LIBPROTOBUF_EXPORT bool ParseNamedEnum(const EnumDescriptor*
descriptor,
                    const string& name,
                    int* value);

template<typename EnumType>
bool ParseNamedEnum(const EnumDescriptor* descriptor,
                    const string& name,
                    EnumType* value) {
  int tmp;
  if (!ParseNamedEnum(descriptor, name, &tmp)) return false;
  *value = static_cast<EnumType>(tmp);
  return true;
}
==============================

This header is not using namespace std explicitly (protobuf-2.1.0).
Notice how it's gotten generated with 'const string&'.


On Sep 21, 5:19 pm, Kenton Varda <ken...@google.com> wrote:
> 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.

Reply via email to