[ 
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177426#comment-14177426
 ] 

Colin Patrick McCabe commented on HDFS-7207:
--------------------------------------------

bq. As you mentioned, exposing \[shared_ptr\] might force the users to run 
tools like valgrind to detect leaks. It is impractical to use valgrind in many 
real-world use cases – valgrind can easily slows the program down for 20x. See 
http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf

I believe that using {{shared_ptr}} can reduce the frequency of memory leaks in 
many scenarios, such as this one.  Avoiding memory leaks is one reason to use 
{{shared_ptr}}, in fact.  Please do not forget that the C interface can 
generate memory leaks as well.

bq. Though I prefer to having a native C\+\+ interface, for the first cut I 
think it is fine to implement it using the C interface and to declare the 
interface as unstable. On the other hand, however, I think we also need to 
clean up the interface a little bit to make it more usable for C++ users.

I agree.  Let's move this JIRA out of the HDFS-6994 branch and consider it 
later.  Adding a new API requires a lot of discussion and care, and should be 
done for all our interface libraries, not just for one.  We should focus 
HDFS-6994 on getting libhdfs3 into a usable state.

> libhdfs3 should not expose exceptions in public C++ API
> -------------------------------------------------------
>
>                 Key: HDFS-7207
>                 URL: https://issues.apache.org/jira/browse/HDFS-7207
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>            Reporter: Haohui Mai
>            Assignee: Colin Patrick McCabe
>            Priority: Blocker
>         Attachments: HDFS-7207.001.patch
>
>
> There are three major disadvantages of exposing exceptions in the public API:
> * Exposing exceptions in public APIs forces the downstream users to be 
> compiled with {{-fexceptions}}, which might be infeasible in many use cases.
> * It forces other bindings to properly handle all C++ exceptions, which might 
> be infeasible especially when the binding is generated by tools like SWIG.
> * It forces the downstream users to properly handle all C++ exceptions, which 
> can be cumbersome as in certain cases it will lead to undefined behavior 
> (e.g., throwing an exception in a destructor is undefined.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to