[protobuf] Support for std::basic_string?

2010-04-05 Thread skyork
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 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.



[protobuf] Re: Support for std::basic_string?

2010-04-06 Thread skyork
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.

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.

On Apr 5, 10:04 pm, Kenton Varda ken...@google.com 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 sky...@gmail.com 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 
  toproto...@googlegroups.com.
  To unsubscribe from this group, send email 
  toprotobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
  .
  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 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.