Thanks for your answer, now I understand the motivation behind library 
design.

On Friday, February 24, 2017 at 1:08:31 AM UTC+3, Feng Xiao wrote:
>
> We don't use exceptions in protobuf as exceptions are disallowed per 
> Google C++ Style Guide:
> https://google.github.io/styleguide/cppguide.html#Exceptions
>
> As such the code likely won't work if some objects throw.
>
> On Thu, Feb 23, 2017 at 4:50 AM, tdiff <td...@yandex.ru <javascript:>> 
> wrote:
>
>> Hi,
>>
>> I am building static protobuf 3.2.0 with MSVC 14 from nmake makefiles (as 
>> described in 
>> https://github.com/google/protobuf/blob/master/cmake/README.md).
>> When compiling, I get lots of C4530 warnings from STL headers: *C++ 
>> exception handler used, but unwind semantics are not enabled. Specify 
>> /EHsc.*
>>
>> This is a known issue (
>> https://connect.microsoft.com/VisualStudio/feedback/details/776348/vs2012-c-exception-warning-on-xlocale),
>>  
>> and comment from STL says that MS is not officially supporting no-exception 
>> mode in standard library.
>>
>> This led me to following questions:
>> 1. Does protobuf relies on any STL feature, that does not work properly 
>> without exceptions?
>>
> No. Protobuf code actually relies on all objects not throwing.
>  
>
>>
>> 2. Are exceptions properly handled in internal protobuf implementation?
>>
> No.
>  
>
>> What if some object used by the library, such as istream, throws?
>>
> The program will likely crash if istream throws.
>  
>
>> Is there any exception safety guarantee and does protobuf need to be 
>> built with exception support? 
>>
>
>>
>> 3. I was not able to find any piece of documentation on error-handling 
>> policy in protobuf. Can I assume that protobuf functions never throw 
>> errors, (may be except for generated by runtime (e.g. badalloc))? I checked 
>> the source code and did not find throw statements, however can it be 
>> changed later or is it a part of library contract? 
>>
> It's part of Google C++ Style Guide that exceptions are disallowed.
>  
>
>>
>> 4.  There is a difference in default behavior between flags passed to cl 
>> by nmake and devenv. For example, the latter by default uses /EHsc handling 
>> mode and thus C4530 warnings are not produced. CMakeList.txt does not 
>> account for this difference. Which set of cl flags is recommended for 
>> building protobuf?
>>
> We mostly only use flags to disable warnings when compiling with Visual 
> C++ compiler.
>  
>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to prot...@googlegroups.com 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to