[
https://issues.apache.org/jira/browse/HDFS-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177158#comment-14177158
]
Haohui Mai commented on HDFS-7207:
----------------------------------
bq. That is the C way-- manual allocation and de-allocation. So if we're going
to do the same here, it makes me wonder why we need a new interface.
I believe that the value of a good C\+\+ interface is more than correctly
handling memory allocation. Many C\+\+ applications appreciate the integration
and the simplicity of a native, properly designed C\+\+ interface. I understand
that you're not a C++ fan, but there are many users are interested in a native
C\+\+ interface. libhdfs3 should address these use cases.
bq. I guess you could argue that it allows us to detect use-after-free, but
this is something that valgrind and ASAN do a great job detecting already, and
without runtime overhead in production.
Talking about the issue of memory allocation -- currently the {{FileSystem}} is
a {{shared_ptr}} in the interface. I think that this is a detail on how libhdfs
is managing the object, but not a part of the interface.
As you mentioned, exposing this detail 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
> 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)
