Rationale Behind PCL `shared_ptr` Interfaces
Many PCL interfaces accept only shared_ptr<T> arguments (e.g. boost::shared_ptr< PointCloud>). [Aside: that is it boost::shared_ptr and not std::shared_ptr is another issue, but should be fixed in upcoming versions.]
Typically such interfaces are a valid option for multi-threaded applications where object lifetimes need to be managed and prevent shared references objects from going out of scope. However, PCL isn't necessarily used in such a context and this API forces one to create many objects on the heap just to support this API style (and always checking for nullptr).
Is there another rationale that I am missing for why this is so?
For local objects, I now need to create a shared_ptr with a custom nop deleter object just to pass it to the algorithms.
(If there is a better forum to ask this question, please lmk.)
c++ api-design point-cloud-library rationale
asked yesterday
Adi Shavit
11.3k14597
|
show 4 more comments
Many PCL interfaces accept only shared_ptr<T> arguments (e.g. boost::shared_ptr< PointCloud>). [Aside: that is it boost::shared_ptr and not std::shared_ptr is another issue, but should be fixed in upcoming versions.]
Typically such interfaces are a valid option for multi-threaded applications where object lifetimes need to be managed and prevent shared references objects from going out of scope. However, PCL isn't necessarily used in such a context and this API forces one to create many objects on the heap just to support this API style (and always checking for nullptr).
Is there another rationale that I am missing for why this is so?
For local objects, I now need to create a shared_ptr with a custom nop deleter object just to pass it to the algorithms.
(If there is a better forum to ask this question, please lmk.)
c++ api-design point-cloud-library rationale
asked yesterday
Adi Shavit
11.3k14597
3
Exposing non-trivial objects across module boundaries is never not a problem, they have to agree about the memory allocator they use. shared_ptr can ensure that the module that allocated the object is also the one that destroys it.
– Hans Passant
yesterday
1
@HansPassant: Doesshared_ptr<>really transparently pass through module boundaries and allow calling the "remote" dealloc? Even if so, I wonder if this is the real consideration for PCL as many uses do not need this and the nop-deleter option is clunky.
– Adi Shavit
yesterday
You mean why they useshared_ptrinstead ofunique_ptror why they don't accept a interface for both, or why they don't accept raw pointer that you initialized withnew?
– t.niese
yesterday
I mean why only ashared_ptr<>interface and e.g. no reference or raw (non-owning) pointer version.
– Adi Shavit
yesterday
1
@AdiShavit I don't know about which particular part of the pcl you are talking, but those parts that expect ashared_ptras input normally indeed need to own it until the data is processed. If you e.g. take theVoxelGridand thesetInputCloudandfilterfunction, the gird has to own the input cloud until filter is called, as of thatshared_ptris used forsetInputCloudand reference is used forfilter, only that way pcl can guarantee that the input cloud is not deleted beforefilteris called.
– t.niese
yesterday
|
show 4 more comments
Many PCL interfaces accept only shared_ptr<T> arguments (e.g. boost::shared_ptr< PointCloud>). [Aside: that is it boost::shared_ptr and not std::shared_ptr is another issue, but should be fixed in upcoming versions.]
Typically such interfaces are a valid option for multi-threaded applications where object lifetimes need to be managed and prevent shared references objects from going out of scope. However, PCL isn't necessarily used in such a context and this API forces one to create many objects on the heap just to support this API style (and always checking for nullptr).
Is there another rationale that I am missing for why this is so?
For local objects, I now need to create a shared_ptr with a custom nop deleter object just to pass it to the algorithms.
(If there is a better forum to ask this question, please lmk.)
c++ api-design point-cloud-library rationale
asked yesterday
Adi Shavit
11.3k14597
Many PCL interfaces accept only shared_ptr<T> arguments (e.g. boost::shared_ptr< PointCloud>). [Aside: that is it boost::shared_ptr and not std::shared_ptr is another issue, but should be fixed in upcoming versions.]
Typically such interfaces are a valid option for multi-threaded applications where object lifetimes need to be managed and prevent shared references objects from going out of scope. However, PCL isn't necessarily used in such a context and this API forces one to create many objects on the heap just to support this API style (and always checking for nullptr).
Is there another rationale that I am missing for why this is so?
For local objects, I now need to create a shared_ptr with a custom nop deleter object just to pass it to the algorithms.
(If there is a better forum to ask this question, please lmk.)
c++ api-design point-cloud-library rationale
c++ api-design point-cloud-library rationale
asked yesterday
Adi Shavit
11.3k14597
asked yesterday
Adi Shavit
11.3k14597
edited yesterday
asked yesterday
Adi Shavit
11.3k14597
asked yesterday
Adi Shavit
11.3k14597
asked yesterday
Adi Shavit
11.3k14597
11.3k14597
3
Exposing non-trivial objects across module boundaries is never not a problem, they have to agree about the memory allocator they use. shared_ptr can ensure that the module that allocated the object is also the one that destroys it.
– Hans Passant
yesterday
1
@HansPassant: Doesshared_ptr<>really transparently pass through module boundaries and allow calling the "remote" dealloc? Even if so, I wonder if this is the real consideration for PCL as many uses do not need this and the nop-deleter option is clunky.
– Adi Shavit
yesterday
You mean why they useshared_ptrinstead ofunique_ptror why they don't accept a interface for both, or why they don't accept raw pointer that you initialized withnew?
– t.niese
yesterday
I mean why only ashared_ptr<>interface and e.g. no reference or raw (non-owning) pointer version.
– Adi Shavit
yesterday
1
@AdiShavit I don't know about which particular part of the pcl you are talking, but those parts that expect ashared_ptras input normally indeed need to own it until the data is processed. If you e.g. take theVoxelGridand thesetInputCloudandfilterfunction, the gird has to own the input cloud until filter is called, as of thatshared_ptris used forsetInputCloudand reference is used forfilter, only that way pcl can guarantee that the input cloud is not deleted beforefilteris called.
– t.niese
yesterday
|
show 4 more comments
3
Exposing non-trivial objects across module boundaries is never not a problem, they have to agree about the memory allocator they use. shared_ptr can ensure that the module that allocated the object is also the one that destroys it.
– Hans Passant
yesterday
1
@HansPassant: Doesshared_ptr<>really transparently pass through module boundaries and allow calling the "remote" dealloc? Even if so, I wonder if this is the real consideration for PCL as many uses do not need this and the nop-deleter option is clunky.
– Adi Shavit
yesterday
You mean why they useshared_ptrinstead ofunique_ptror why they don't accept a interface for both, or why they don't accept raw pointer that you initialized withnew?
– t.niese
yesterday
I mean why only ashared_ptr<>interface and e.g. no reference or raw (non-owning) pointer version.
– Adi Shavit
yesterday
1
@AdiShavit I don't know about which particular part of the pcl you are talking, but those parts that expect ashared_ptras input normally indeed need to own it until the data is processed. If you e.g. take theVoxelGridand thesetInputCloudandfilterfunction, the gird has to own the input cloud until filter is called, as of thatshared_ptris used forsetInputCloudand reference is used forfilter, only that way pcl can guarantee that the input cloud is not deleted beforefilteris called.
– t.niese
yesterday
3
3
Exposing non-trivial objects across module boundaries is never not a problem, they have to agree about the memory allocator they use. shared_ptr can ensure that the module that allocated the object is also the one that destroys it.
– Hans Passant
yesterday
Exposing non-trivial objects across module boundaries is never not a problem, they have to agree about the memory allocator they use. shared_ptr can ensure that the module that allocated the object is also the one that destroys it.
– Hans Passant
yesterday
1
1
@HansPassant: Does
shared_ptr<> really transparently pass through module boundaries and allow calling the "remote" dealloc? Even if so, I wonder if this is the real consideration for PCL as many uses do not need this and the nop-deleter option is clunky.– Adi Shavit
yesterday
@HansPassant: Does
shared_ptr<> really transparently pass through module boundaries and allow calling the "remote" dealloc? Even if so, I wonder if this is the real consideration for PCL as many uses do not need this and the nop-deleter option is clunky.– Adi Shavit
yesterday
You mean why they use
shared_ptr instead of unique_ptr or why they don't accept a interface for both, or why they don't accept raw pointer that you initialized with new?– t.niese
yesterday
You mean why they use
shared_ptr instead of unique_ptr or why they don't accept a interface for both, or why they don't accept raw pointer that you initialized with new?– t.niese
yesterday
I mean why only a
shared_ptr<> interface and e.g. no reference or raw (non-owning) pointer version.– Adi Shavit
yesterday
I mean why only a
shared_ptr<> interface and e.g. no reference or raw (non-owning) pointer version.– Adi Shavit
yesterday
1
1
@AdiShavit I don't know about which particular part of the pcl you are talking, but those parts that expect a
shared_ptr as input normally indeed need to own it until the data is processed. If you e.g. take the VoxelGrid and the setInputCloud and filter function, the gird has to own the input cloud until filter is called, as of that shared_ptr is used for setInputCloud and reference is used for filter, only that way pcl can guarantee that the input cloud is not deleted before filter is called.– t.niese
yesterday
@AdiShavit I don't know about which particular part of the pcl you are talking, but those parts that expect a
shared_ptr as input normally indeed need to own it until the data is processed. If you e.g. take the VoxelGrid and the setInputCloud and filter function, the gird has to own the input cloud until filter is called, as of that shared_ptr is used for setInputCloud and reference is used for filter, only that way pcl can guarantee that the input cloud is not deleted before filter is called.– t.niese
yesterday
|
show 4 more comments
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53944822%2frationale-behind-pcl-shared-ptr-interfaces%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53944822%2frationale-behind-pcl-shared-ptr-interfaces%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Exposing non-trivial objects across module boundaries is never not a problem, they have to agree about the memory allocator they use. shared_ptr can ensure that the module that allocated the object is also the one that destroys it.
– Hans Passant
yesterday
1
@HansPassant: Does
shared_ptr<>really transparently pass through module boundaries and allow calling the "remote" dealloc? Even if so, I wonder if this is the real consideration for PCL as many uses do not need this and the nop-deleter option is clunky.– Adi Shavit
yesterday
You mean why they use
shared_ptrinstead ofunique_ptror why they don't accept a interface for both, or why they don't accept raw pointer that you initialized withnew?– t.niese
yesterday
I mean why only a
shared_ptr<>interface and e.g. no reference or raw (non-owning) pointer version.– Adi Shavit
yesterday
1
@AdiShavit I don't know about which particular part of the pcl you are talking, but those parts that expect a
shared_ptras input normally indeed need to own it until the data is processed. If you e.g. take theVoxelGridand thesetInputCloudandfilterfunction, the gird has to own the input cloud until filter is called, as of thatshared_ptris used forsetInputCloudand reference is used forfilter, only that way pcl can guarantee that the input cloud is not deleted beforefilteris called.– t.niese
yesterday