On Tue, Apr 6, 2010 at 1:41 AM, skyork <[email protected]> wrote: > To be honest, I didn't get as far as reflection because it didn't show > up immediately as a compile error after I changed the underlying > basic_string type in the messages. But as far as reflection is > concerned, the only difference between my string and std::string is > the allocator, so at least for now I don't mind generalizing the > reflection interface to use basic_string for strings and leaving it up > to the caller to make sure they cast to the correct underlying type -- > whether the generated message uses my string or ::std::string is a > command-line option, so the unit tests should remain operational. >
No, leaving it up to the caller to cast doesn't work. The reflection object itself needs to know how to copy and clear the value, and anyway the whole point of reflection is to allow you to write generic code that doesn't know on what type it is operating. > However I'm open to other approaches to getting around this issue, > that doesn't involve refactoring so much 3rd party (at least from my > point of view) code. > Maybe just define some helpers? my_string std2mine(std::string); std::string mine2std(my_string); > > On Apr 5, 10:04 pm, Kenton Varda <[email protected]> wrote: > > Unlikely. I don't know how you'd implement GeneratedMessageReflection > such > > that it can deal with user-specified instances of basic_string. > > > > On Mon, Apr 5, 2010 at 5:15 PM, skyork <[email protected]> wrote: > > > I was wondering if there was any plans to support std::basic_string, > > > as opposed to std::string? The reason I ask is because our code base > > > uses a custom allocator for strings and hence our own string type > > > (i.e. typedef std::basic_string<...> MyString), and the generated > > > protocol buffer code is hard-coded against ::std::string. Even when I > > > changed the outputted string type, a lot of the library I/O still only > > > accepted std::string. It took a few more hours of compiler/library > > > modifications to get that fixed up, and now everything seems to > > > compile and run correctly, however all my delicate changes will be > > > stomped in the next version release... > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Protocol Buffers" group.> To post to this group, send email > [email protected]. > > > To unsubscribe from this group, send email to> > [email protected]<protobuf%[email protected]> > <protobuf%[email protected]<protobuf%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/protobuf?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
