C++ disabled c++ exceptions

[tdiff]

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?

2. Are exceptions properly handled in internal protobuf implementation? What if some object used by the library, such as 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? 

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?

[Feng Xiao]

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> 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+unsubscribe@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[tdiff]

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

To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.