[protobuf] Re: Issue 166 in protobuf: by_symbol_.insert(iter, make_pair(name, value)); fails with Sun Studio 12

2010-08-24 Thread protobuf


Comment #4 on issue 166 by philip.logan: by_symbol_.insert(iter,  
make_pair(name, value)); fails with Sun Studio 12

http://code.google.com/p/protobuf/issues/detail?id=166

BTW, compiler/command_line_interface.cc contains a similar problem with Sun  
Studio compiler with default STL implementation:

Changing
  proto_path_.push_back(make_pair(, .));
to
  proto_path_.push_back(make_pairstring, string(, .));
resolves problem (or replace make_pair with value_type for collection).

--
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.



Re: [protobuf] Scala protocol buffers protoc plugin

2010-08-24 Thread Kenton Varda
On Wed, Aug 18, 2010 at 7:07 AM, Jeff Plaisance jeffplaisa...@gmail.comwrote:

 It seems like the issue here is that optional has been overloaded to mean
 two different things:

 1) Not really optional but in order to do rolling upgrades we're making it
 optional.  The default should be used if it is not set.  In my opinion, in
 this case there should be no has method because either its result is
 irrelevant or it is being used to overload some other meaning on top of
 optional.
 2) Optional in the sense of Option, Maybe, Nullable, empty, can be null,
 whatever you want to call it.  In my opinion this should be encapsulated in
 the type so that the programmer is forced to handle all possible cases.  The
 has method should not be used for this because it is too easy to ignore.


Yes, I think you're right, and I see how it makes sense to distinguish these
two by the presence or absence of an explicit default value.

-- 
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.



Re: [protobuf] What's the right way to bundle Google's code in my project?

2010-08-24 Thread Kenton Varda
On Wed, Aug 18, 2010 at 12:16 AM, Eugene Vigdorchik 
eugene.vigdorc...@gmail.com wrote:

 I'm missing the following 3 files and as a result am forced to either
 copy-paste or duplicate them in my project:
 google/protobuf/compiler/java/java_helpers.h
 google/protobuf/stubs/strutil.h
 google/protobuf/stubs/substitute.h


These headers are intentionally not public, as they are not intended to be
part of the protobuf library interface.

You may, of course, simply copy the code into your project.

Ideally we would have some sort of library encapsulating the Java helpers so
that you could write a Java code generator plugin without copying all that
code, but no one has time to work on this.

-- 
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.



Re: [protobuf] Enum values are siblings of their type, not children of it.

2010-08-24 Thread Kenton Varda
How would you make this change without updating millions of lines of
existing C++ code that uses protobuf enums?

On Fri, Aug 20, 2010 at 11:12 AM, alopecoid alopec...@gmail.com wrote:

 Hi,

 This post is about the fact that protobuf enum values use C++ scoping
 rules, meaning that, unlike in Java, enum values are siblings of their
 type, not children of it.

 Say I have the following contrived message:

  message MyMessage {
enum Foo {
  FIRST = 0;
  SECOND = 1;
  BOTH = 2;
}
required Foo foo = 1;

enum Bar {
  FIRST = 0;
  SECOND = 1;
  BOTH = 2;
}
required Bar bar = 2;
  }

 This wouldn't compile because the protobuf compiler recognizes the
 fact that for C++, the generated enum values for Foo and Bar would
 conflict with each other.

 However, for Java, this wouldn't be a problem. I would like to propose
 that instead of punishing the generated Java code because of C++'s
 strange enum behavior (by forcing developers to rename their enum
 values even though they don't collide), that instead, the generated C+
 + enum declarations are wrapped in their own nested namespaces? For
 example, something like:

  namespace Foo {
enum Enum {
  FIRST = 0;
  SECOND = 1;
  BOTH = 2;
}
  }

  namespace Bar {
enum Enum {
  FIRST = 0;
  SECOND = 1;
  BOTH = 2;
}
  }

 At this point, the enum values would be accessed like Foo::FIRST,
 Bar::FIRST, etc, which would eliminate the enum value collision
 problem altogether, and at the same time make them appear to behave
 more like Java's enum scoping rules (which arguably make more sense).

 Thoughts?

 Thank you.

 --
 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.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.



Re: [protobuf] Service can only receive one argument

2010-08-24 Thread Kenton Varda
message Object1And2 {
  required Object1 object1 = 1;
  required Object2 object2 = 2;
}

service MyService {
  rpc send(Object1And2) returns(VOID);
}

On Sun, Aug 22, 2010 at 1:36 AM, omer.c chechiko...@gmail.com wrote:

 Hello,

 Can a service receive multiplate arugments or only one?

 For example,

 message VOID {}

 message Object1
 {
required int32 t = 1;
required int32 s = 2;
 }

 message Object2
 {
required int32 t2 = 1;
required int32 s2 = 2;
 }

 How can I define a service which will accept both arguments:

 service my_service
 {
  rpc send(Object1, Object2) returns(VOID);   // doesn't compile
 }

 Is it possible ?

 Thanks,
 Omer

 --
 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.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.