Re: [protobuf] Support for J2ME
Hi Kenton,
*It seems to me that combining them would only be more work for both of us.
I would need you to be available...*
I haven't thought the whole thing through. You're right. It makes more sense
to keep my implementation in a separated project. Thanks for all the
advices.
Thanks,
-Gatis
On Mon, Mar 15, 2010 at 7:54 PM, Kenton Varda wrote:
> I wonder if we should consider making mutable-message mode a feature of the
> base implementation, rather than j2me-specific. Some people have requested
> this, even though I personally think the builder-based design is better.
>
> On Fri, Mar 12, 2010 at 7:13 PM, Igor Gatis wrote:
>
>> My experience with J2ME says performance is not the most important feature
>> for the majority of the applications. Trust me when I say JAR size is the
>> one people care the most.
>
>
> OK, you would know better than me.
>
>
>> I still need to go over all files to check code compliance with the style
>> guide and write tests. But besides that, do you think I still need to change
>> the design?
>>
>
> Based on my high-level look, what you have seems good. But, you don't need
> my approval for anything.
>
> Are you still hoping to add this to the official distribution? If so, can
> I ask why you prefer this over maintaining your own project? It seems to me
> that combining them would only be more work for both of us. I would need
> you to be available to update and test your implementation any time I'm
> trying to do a release or making Java code generator changes. Also, you
> would not be able to release updates to your implementation separately from
> the protobuf release cycle, which is probably far too slow for a new
> project. With the decentralized approach, you do not have to depend on me
> and I do not have to depend on you.
>
>
>>
>>
>> On Fri, Mar 12, 2010 at 9:10 PM, Kenton Varda wrote:
>>
>>> This may solve the problem but adding code to every setter may have a
>>> significant cost. It's harder to inline the setter this way. But it's hard
>>> to say exactly what the cost will be without some sort of benchmarks.
>>>
>>>
>>> On Fri, Mar 12, 2010 at 12:12 PM, Igor Gatis wrote:
>>>
I think I have a solution for the readonly messages.
Message.java now includes the following header:
public abstract class Message {
private boolean readOnly;
protected Message(boolean noInit) {
this.readOnly = true;
}
public Message() {}
protected void assertNotReadOnly() {
if (readOnly) {
throw new RuntimeException("Read only message!");
}
}
A generated message, HelloRequest, has:
public final class HelloRequest extends com.google.protobuf.Message {
public HelloRequest() {
initFields();
}
private HelloRequest(boolean noInit) { super(true); }
All methods that can modify HelloRequest look like this:
public void setName(java.lang.String value) {
assertNotReadOnly();
hasName = true;
name_ = value;
}
In other words, that example:
myMessage.getSubMessage().setFoo(1);
Would through an exception. just like
Collections.unmodifiableList(java.util.List)
does.
Do you think this solves the problem?
On Fri, Mar 12, 2010 at 4:16 PM, Igor Gatis wrote:
> myMessage.getSubMessage().setFoo(1);
>>
>
>> If they haven't previously called setSubMessage(new SubMessage()) then
>> this code will actually modify the shared default instance of SubMessage
>> which could cause all sorts of bugs around the system. Have you
>> considered
>> how to avoid this problem?
>>
>
> Uh, not really. But yeah, that's definitely a problem. Let me think
> about that. I'll get back to you when I have a solution for this problem.
>
>
> So the bottom line is that I had to squeeze the runtime to get it as
>>> small as possible - this is a fully functional protobuf runtime
>>> implementation that occupies 26KB against 173KB of standard Java
>>> implementation.
>>>
>>
>> Did you start from the lite implementation or the full one?
>>
>> 26k is pretty impressive.
>>
>
> Yep, I though LITE_RUNTIME would solve all my problems but generics and
> for-each loops were a problem.
>
> Flattening the Message class has a few side effects I haven't noticed
> until I implemented equals() and hashCode() methods.
>
> A bad effect is that now that there is no way to handle fields in a
> generic way, these methods are generated for each message, which makes the
> size per message bigger. For a small set of messages, that's not a
> problem -
> and that is the most common scenario for J2ME apps.
>
> A good one is that obfuscator
[protobuf] kInitialSize in RepeatedField
Hi all,
let's say you have a large number of messages of the same type in
memory. One field of this type is marked as repeated:
message Test {
repeated uint64 foo = 1;
}
RepeatedField defines the default size to be 4. If most of my objects
have 5 foos, I waste a lot of memory.
Is it possible to make kInitialSize into a template parameter of
RepeatedField? Thatway I could have different default sizes for
different message types. The message description could provide an
option for setting a new default length:
message Test {
repeated uint64 foo = 1 [default_size=5];
}
Cheers,
Thorsten
--
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] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
appearantly I didn't notice that when I clicked the .sln file, it opened with VS2005... I only started looking into it when compilation failed with the 2005 version. Linking with the 2005 version failed, the linker error I got was something to do with std::Base_container contstructor/destructor. I guess that's what changed between VS2005 and VS2008. On Tue, Mar 16, 2010 at 12:16 AM, Kenton Varda wrote: > I actually maintain the project files using VS2008, but I run a hack script > that "downgrades" them to VS2005 (by simply replacing the version number) > before release so that VS2005 users can use the package. > > I'm confused about how you managed to compile the project using VS2008 > without it automatically "upgrading" the files. Doesn't VS immediately > prompt you to upgrade when you open them? I'm also confused why compilation > would fail, considering that the only difference between the 2005 and 2008 > versions of the project files is the version number. > > I definitely do not want to try to maintain two separate copies of the VS > project files. Maintaining one set is already painful enough. I really > dislike the MSVC build system. > > On Sun, Mar 14, 2010 at 2:49 PM, Austin Ziegler wrote: > >> On Sun, Mar 14, 2010 at 3:15 PM, Marc Gravell >> wrote: >> > I'm really glad you found the cause of this; you had me worried I'd done >> > something horrible with the .NET encoding ;-p >> > Probably one for Kenton, but I wonder if it might be prudent to include >> > VS2008 (and presumably VS2010) project files for the core project? >> >> We've got some VS2008 versions we can contribute; we deliberately >> created them in parallel to to the existing vs/ directory. >> >> -austin >> -- >> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca >> http://www.halostatue.ca/ • http://twitter.com/halostatue >> > > -- 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] Support for J2ME
Great! I look forward to seeing it.
On Tue, Mar 16, 2010 at 6:38 AM, Igor Gatis wrote:
> Hi Kenton,
>
> *It seems to me that combining them would only be more work for both of
> us. I would need you to be available...*
>
> I haven't thought the whole thing through. You're right. It makes more
> sense to keep my implementation in a separated project. Thanks for all the
> advices.
>
> Thanks,
> -Gatis
>
> On Mon, Mar 15, 2010 at 7:54 PM, Kenton Varda wrote:
>
>> I wonder if we should consider making mutable-message mode a feature of
>> the base implementation, rather than j2me-specific. Some people have
>> requested this, even though I personally think the builder-based design is
>> better.
>>
>> On Fri, Mar 12, 2010 at 7:13 PM, Igor Gatis wrote:
>>
>>> My experience with J2ME says performance is not the most important
>>> feature for the majority of the applications. Trust me when I say JAR size
>>> is the one people care the most.
>>
>>
>> OK, you would know better than me.
>>
>>
>>> I still need to go over all files to check code compliance with the style
>>> guide and write tests. But besides that, do you think I still need to change
>>> the design?
>>>
>>
>> Based on my high-level look, what you have seems good. But, you don't
>> need my approval for anything.
>>
>> Are you still hoping to add this to the official distribution? If so, can
>> I ask why you prefer this over maintaining your own project? It seems to me
>> that combining them would only be more work for both of us. I would need
>> you to be available to update and test your implementation any time I'm
>> trying to do a release or making Java code generator changes. Also, you
>> would not be able to release updates to your implementation separately from
>> the protobuf release cycle, which is probably far too slow for a new
>> project. With the decentralized approach, you do not have to depend on me
>> and I do not have to depend on you.
>>
>>
>>>
>>>
>>> On Fri, Mar 12, 2010 at 9:10 PM, Kenton Varda wrote:
>>>
This may solve the problem but adding code to every setter may have a
significant cost. It's harder to inline the setter this way. But it's
hard
to say exactly what the cost will be without some sort of benchmarks.
On Fri, Mar 12, 2010 at 12:12 PM, Igor Gatis wrote:
> I think I have a solution for the readonly messages.
>
> Message.java now includes the following header:
>
> public abstract class Message {
>
> private boolean readOnly;
>
> protected Message(boolean noInit) {
> this.readOnly = true;
> }
>
> public Message() {}
> protected void assertNotReadOnly() {
> if (readOnly) {
> throw new RuntimeException("Read only message!");
> }
> }
>
> A generated message, HelloRequest, has:
>
> public final class HelloRequest extends com.google.protobuf.Message {
> public HelloRequest() {
> initFields();
> }
> private HelloRequest(boolean noInit) { super(true); }
>
>
> All methods that can modify HelloRequest look like this:
>
> public void setName(java.lang.String value) {
> assertNotReadOnly();
> hasName = true;
> name_ = value;
> }
>
> In other words, that example:
>
> myMessage.getSubMessage().setFoo(1);
>
> Would through an exception. just like
> Collections.unmodifiableList(java.util.List)
> does.
>
> Do you think this solves the problem?
>
> On Fri, Mar 12, 2010 at 4:16 PM, Igor Gatis wrote:
>
>> myMessage.getSubMessage().setFoo(1);
>>>
>>
>>> If they haven't previously called setSubMessage(new SubMessage())
>>> then this code will actually modify the shared default instance of
>>> SubMessage which could cause all sorts of bugs around the system. Have
>>> you
>>> considered how to avoid this problem?
>>>
>>
>> Uh, not really. But yeah, that's definitely a problem. Let me think
>> about that. I'll get back to you when I have a solution for this problem.
>>
>>
>> So the bottom line is that I had to squeeze the runtime to get it as
small as possible - this is a fully functional protobuf runtime
implementation that occupies 26KB against 173KB of standard Java
implementation.
>>>
>>> Did you start from the lite implementation or the full one?
>>>
>>> 26k is pretty impressive.
>>>
>>
>> Yep, I though LITE_RUNTIME would solve all my problems but generics
>> and for-each loops were a problem.
>>
>> Flattening the Message class has a few side effects I haven't noticed
>> until I implemented equals() and hashCode() methods.
>>
>> A bad effect is that now that there is no way to handle fields in a
>> generic way, the
Re: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
I do test each release with both VS2005 and VS2008, and haven't seen that problem before. Odd. On Mon, Mar 15, 2010 at 10:54 PM, Roey Lehman wrote: > appearantly I didn't notice that when I clicked the .sln file, it opened > with VS2005... > I only started looking into it when compilation failed with the 2005 > version. > Linking with the 2005 version failed, the linker error I got was something > to do with std::Base_container contstructor/destructor. I guess that's what > changed between VS2005 and VS2008. > > > > On Tue, Mar 16, 2010 at 12:16 AM, Kenton Varda wrote: > >> I actually maintain the project files using VS2008, but I run a hack >> script that "downgrades" them to VS2005 (by simply replacing the version >> number) before release so that VS2005 users can use the package. >> >> I'm confused about how you managed to compile the project using VS2008 >> without it automatically "upgrading" the files. Doesn't VS immediately >> prompt you to upgrade when you open them? I'm also confused why compilation >> would fail, considering that the only difference between the 2005 and 2008 >> versions of the project files is the version number. >> >> I definitely do not want to try to maintain two separate copies of the VS >> project files. Maintaining one set is already painful enough. I really >> dislike the MSVC build system. >> >> On Sun, Mar 14, 2010 at 2:49 PM, Austin Ziegler wrote: >> >>> On Sun, Mar 14, 2010 at 3:15 PM, Marc Gravell >>> wrote: >>> > I'm really glad you found the cause of this; you had me worried I'd >>> done >>> > something horrible with the .NET encoding ;-p >>> > Probably one for Kenton, but I wonder if it might be prudent to include >>> > VS2008 (and presumably VS2010) project files for the core project? >>> >>> We've got some VS2008 versions we can contribute; we deliberately >>> created them in parallel to to the existing vs/ directory. >>> >>> -austin >>> -- >>> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca >>> http://www.halostatue.ca/ • http://twitter.com/halostatue >>> >> >> > -- 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] kInitialSize in RepeatedField
You can, of course, modify the value all you want in your copy of the code.
However, the value is only useful if it is a compile-time constant, so we
can't really parameterize it in general. Note that if you change the value,
you must recompile libprotobuf and anything you have that depends on it.
On Tue, Mar 16, 2010 at 5:39 AM, Thorsten wrote:
> Hi all,
>
> let's say you have a large number of messages of the same type in
> memory. One field of this type is marked as repeated:
> message Test {
>repeated uint64 foo = 1;
> }
> RepeatedField defines the default size to be 4. If most of my objects
> have 5 foos, I waste a lot of memory.
>
> Is it possible to make kInitialSize into a template parameter of
> RepeatedField? Thatway I could have different default sizes for
> different message types. The message description could provide an
> option for setting a new default length:
> message Test {
>repeated uint64 foo = 1 [default_size=5];
> }
>
> Cheers,
> Thorsten
>
> --
> 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.
>
>
--
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] LNK2019 and LNK2001 problems in MSVS2008
Hi. I use MSVS2008 and I have next problem: I installed "protocol buffers" from "vsprojects" folder in Debug mode, like it was recomended in readme.txt. Next step I took example proto-file addressbook.proto and I had compiled it by using proto.exe (that i had got above). I created new solution and added in it next files: addressbook.pb.h, addressbook.pb.cc, add_person.cc (from examples folder) Solution comiles fine, but while linking process I have many errors like this: addressbook.pb.obj : error LNK2019: unresolved external symbol "public: __thiscall google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class google::protobuf::Descriptor const *,class google::protobuf::Message const *,int const * const,int,int,int,class google::protobuf::DescriptorPool const *,class google::protobuf::MessageFactory *,int)" (?? 0generatedmessagereflect...@internal@proto...@google@@q...@pbvdescriptor@2...@pbvmessage@2...@qbpbvdescriptorpool@2...@pavmessagefactory@2...@h@Z) referenced in function "void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void)" (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2019: unresolved external symbol "public: static class google::protobuf::MessageFactory * __cdecl google::protobuf::MessageFactory::generated_factory(void)" (? generated_fact...@messagefactory@proto...@google@@sapav...@xz) referenced in function "void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void)" (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2019: unresolved external symbol "public: __thiscall google::protobuf::internal::LogMessage::~LogMessage(void)" (?? 1logmess...@internal@proto...@google@@q...@xz) referenced in function "void __cdecl tutorial::protobuf_AssignDesc_addressbook_2eproto(void)" (? protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) addressbook.pb.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string,class std::allocator > __thiscall google::protobuf::Message::GetTypeName(void)const " (? gettypen...@message@proto...@google@@ube?av?$basic_str...@du? $char_tra...@d@std@@v?$alloca...@d@2@@std@@XZ) total 69 errors. I cannot solve this probelm. -- 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] kInitialSize in RepeatedField
We can't make it a template parameter because it would break reflection,
which depends on being able to find the RepeatedField objects via pointer
offsets. If it doesn't know exactly which template instance of
RepeatedField it is looking for it wouldn't work.
On Tue, Mar 16, 2010 at 2:00 PM, Kenton Varda wrote:
> You can, of course, modify the value all you want in your copy of the code.
> However, the value is only useful if it is a compile-time constant, so we
> can't really parameterize it in general. Note that if you change the value,
> you must recompile libprotobuf and anything you have that depends on it.
>
>
> On Tue, Mar 16, 2010 at 5:39 AM, Thorsten wrote:
>
>> Hi all,
>>
>> let's say you have a large number of messages of the same type in
>> memory. One field of this type is marked as repeated:
>> message Test {
>>repeated uint64 foo = 1;
>> }
>> RepeatedField defines the default size to be 4. If most of my objects
>> have 5 foos, I waste a lot of memory.
>>
>> Is it possible to make kInitialSize into a template parameter of
>> RepeatedField? Thatway I could have different default sizes for
>> different message types. The message description could provide an
>> option for setting a new default length:
>> message Test {
>>repeated uint64 foo = 1 [default_size=5];
>> }
>>
>> Cheers,
>> Thorsten
>>
>> --
>> 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.
>>
>>
>
--
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] LNK2019 and LNK2001 problems in MSVS2008
You need to link the example against libprotobuf.lib. On Tue, Mar 16, 2010 at 1:43 PM, mohito wrote: > Hi. > > I use MSVS2008 and I have next problem: > > I installed "protocol buffers" from "vsprojects" folder in Debug mode, > like it was recomended in readme.txt. > Next step I took example proto-file addressbook.proto and I had > compiled it by using proto.exe (that i had got above). > I created new solution and added in it next files: addressbook.pb.h, > addressbook.pb.cc, add_person.cc (from examples folder) > > Solution comiles fine, but while linking process I have many errors > like this: > > addressbook.pb.obj : error LNK2019: unresolved external symbol > "public: __thiscall > > google::protobuf::internal::GeneratedMessageReflection::GeneratedMessageReflection(class > google::protobuf::Descriptor const *,class google::protobuf::Message > const *,int const * const,int,int,int,class > google::protobuf::DescriptorPool const *,class > google::protobuf::MessageFactory *,int)" (?? > 0generatedmessagereflect...@internal@proto...@google@@q...@pbvdescriptor > @2...@pbvmessage@2...@qbpbvdescriptorpool@2...@pavmessagefactory@2...@h@Z) > referenced in function "void __cdecl > tutorial::protobuf_AssignDesc_addressbook_2eproto(void)" (? > protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) > addressbook.pb.obj : error LNK2019: unresolved external symbol > "public: static class google::protobuf::MessageFactory * __cdecl > google::protobuf::MessageFactory::generated_factory(void)" (? > generated_fact...@messagefactory@proto...@google@@sapav...@xz) > referenced in function "void __cdecl > tutorial::protobuf_AssignDesc_addressbook_2eproto(void)" (? > protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) > addressbook.pb.obj : error LNK2019: unresolved external symbol > "public: __thiscall > google::protobuf::internal::LogMessage::~LogMessage(void)" (?? > 1logmess...@internal@proto...@google@@q...@xz) referenced in function > "void __cdecl > tutorial::protobuf_AssignDesc_addressbook_2eproto(void)" (? > protobuf_assigndesc_addressbook_2epr...@tutorial@@YAXXZ) > > > addressbook.pb.obj : error LNK2001: unresolved external symbol > "public: virtual class std::basic_string std::char_traits,class std::allocator > __thiscall > google::protobuf::Message::GetTypeName(void)const " (? > gettypen...@message@proto...@google@@ube?av?$basic_str...@du? > $char_tra...@d@std@@v?$alloca...@d@2@@std@@XZ) > > total 69 errors. > > I cannot solve this probelm. > > -- > 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. > > -- 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] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
On Tue, Mar 16, 2010 at 3:24 PM, Kenton Varda wrote: > I do test each release with both VS2005 and VS2008, and haven't seen that > problem before. Odd. Do you have 2005 and 2008 on a single system, or are they on independent systems? If they're on the same system, VS does not always offer to upgrade, but opens the VS projects in the same VS that they were created in. You have to explicitly force them to upgrade. I agree that if you can avoid it, you shouldn't maintain two different sets of vsproj files, but if all you're doing is downconverting a vs2008 vsproj to vs2005, then it couldn't hurt to ship both in the tarball, even in separate directories. -austin -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- 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] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
On Tue, Mar 16, 2010 at 6:11 PM, Austin Ziegler wrote: > On Tue, Mar 16, 2010 at 3:24 PM, Kenton Varda wrote: > > I do test each release with both VS2005 and VS2008, and haven't seen that > > problem before. Odd. > > Do you have 2005 and 2008 on a single system, or are they on > independent systems? If they're on the same system, VS does not always > offer to upgrade, but opens the VS projects in the same VS that they > were created in. You have to explicitly force them to upgrade. > Different systems. > I agree that if you can avoid it, you shouldn't maintain two different > sets of vsproj files, but if all you're doing is downconverting a > vs2008 vsproj to vs2005, then it couldn't hurt to ship both in the > tarball, even in separate directories. > It also wouldn't help, because they are exactly the same except for the version number, and if a VS2008 user tries to open them, it auto-converts them to VS2008. -- 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] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
On Tue, Mar 16, 2010 at 10:21 PM, Kenton Varda wrote: > On Tue, Mar 16, 2010 at 6:11 PM, Austin Ziegler > wrote: >> On Tue, Mar 16, 2010 at 3:24 PM, Kenton Varda wrote: >> > I do test each release with both VS2005 and VS2008, and haven't seen >> > that >> > problem before. Odd. >> Do you have 2005 and 2008 on a single system, or are they on >> independent systems? If they're on the same system, VS does not always >> offer to upgrade, but opens the VS projects in the same VS that they >> were created in. You have to explicitly force them to upgrade. > Different systems. >> I agree that if you can avoid it, you shouldn't maintain two different >> sets of vsproj files, but if all you're doing is downconverting a >> vs2008 vsproj to vs2005, then it couldn't hurt to ship both in the >> tarball, even in separate directories. > It also wouldn't help, because they are exactly the same except for the > version number, and if a VS2008 user tries to open them, it auto-converts > them to VS2008. Except in the case where the user has both VS2005 and VS2008 installed on the same system. As many of the developers at my place of work do. If you give me VS2005 projects and I have both VS2005 and VS2008 installed, I have to explicitly open the VS2005 projects with VS2008 to make them work. This also may not work in scenarios where someone may need to provide compiled versions that work with VS2005 and VS2008 (separately built versions). It's able to be worked around (we copied the VS2005 projects to a new directory and forced them to be opened with VS2008), but it is a little annoying. -austin -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- 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.
