[Block Pointer] make_block
Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/blo... Is it time for a review? -Phil
On 4/29/2011 3:13 PM, Phil Bouchard wrote:
Hi,
I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/blo...
It looks like the performance was better using operator new because of the lack of the need of temporaries: time of new block: 0.144u 0.016s 0:00.16 93.7% time of make_block: 0.328u 0.012s 0:00.34 97.0% Any thoughts? -Phil
On 30/04/2011 02:38, Phil Bouchard wrote:
On 4/29/2011 3:13 PM, Phil Bouchard wrote:
Hi,
I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/blo...
It looks like the performance was better using operator new because of the lack of the need of temporaries:
time of new block: 0.144u 0.016s 0:00.16 93.7%
time of make_block: 0.328u 0.012s 0:00.34 97.0%
Any thoughts?
There is no difference between block_ptr<T> a = make_block<T>(whatever); and block_ptr<T> a(new block<T>(whatever)); Your temporaries in question are removed by NRVO.
On 4/30/2011 8:05 AM, Mathias Gaunard wrote:
On 30/04/2011 02:38, Phil Bouchard wrote:
time of new block: 0.144u 0.016s 0:00.16 93.7%
time of make_block: 0.328u 0.012s 0:00.34 97.0%
Any thoughts?
There is no difference between
block_ptr<T> a = make_block<T>(whatever); and block_ptr<T> a(new block<T>(whatever));
Your temporaries in question are removed by NRVO.
That's right, with the optimization flags turned on I get: 0.116u 0.004s 0:00.12 91.6% (This is block_ptr_test3 BTW) -Phil
On 4/30/2011 9:59 AM, Phil Bouchard wrote:
On 4/30/2011 8:05 AM, Mathias Gaunard wrote:
On 30/04/2011 02:38, Phil Bouchard wrote:
time of new block: 0.144u 0.016s 0:00.16 93.7%
time of make_block: 0.328u 0.012s 0:00.34 97.0%
Any thoughts?
There is no difference between
block_ptr<T> a = make_block<T>(whatever); and block_ptr<T> a(new block<T>(whatever));
Your temporaries in question are removed by NRVO.
That's right, with the optimization flags turned on I get: 0.116u 0.004s 0:00.12 91.6%
(This is block_ptr_test3 BTW)
Sorry operator new is still faster with optimization flags turned on: time of new block (O3): 0.044u 0.040s 0:00.09 88.8% time of make_block (O3): 0.116u 0.004s 0:00.12 91.6% -Phil
2011/5/1 Phil Bouchard <philippe@fornux.com>
On 4/30/2011 9:59 AM, Phil Bouchard wrote:
On 4/30/2011 8:05 AM, Mathias Gaunard wrote:
On 30/04/2011 02:38, Phil Bouchard wrote:
time of new block: 0.144u 0.016s 0:00.16 93.7%
time of make_block: 0.328u 0.012s 0:00.34 97.0%
Any thoughts?
There is no difference between
block_ptr<T> a = make_block<T>(whatever); and block_ptr<T> a(new block<T>(whatever));
Your temporaries in question are removed by NRVO.
That's right, with the optimization flags turned on I get: 0.116u 0.004s 0:00.12 91.6%
(This is block_ptr_test3 BTW)
Sorry operator new is still faster with optimization flags turned on: time of new block (O3): 0.044u 0.040s 0:00.09 88.8%
time of make_block (O3):
0.116u 0.004s 0:00.12 91.6%
What if block_ptr<T> a(make_block<T>(whatever)); v.s. block_ptr<T> a(new block<T>(whatever)); ?
2011/5/1 Phil Bouchard <philippe@fornux.com>
On 4/30/2011 12:14 PM, TONGARI wrote:
What if block_ptr<T> a(make_block<T>(whatever)); v.s. block_ptr<T> a(new block<T>(whatever)); ?
I just confirmed that there is no difference between
block_ptr<T> a = make_block<T>(whatever);
and block_ptr<T> a(make_block<T>(whatever));
I mean, block_ptr<T> a(...); & block_ptr<T> a = ...; may have some difference, I'm not sure...
2011/5/1 TONGARI <tongari95@gmail.com>
2011/5/1 Phil Bouchard <philippe@fornux.com>
On 4/30/2011 12:14 PM, TONGARI wrote:
What if block_ptr<T> a(make_block<T>(whatever)); v.s. block_ptr<T> a(new block<T>(whatever)); ?
I just confirmed that there is no difference between
block_ptr<T> a = make_block<T>(whatever);
and block_ptr<T> a(make_block<T>(whatever));
I mean,
block_ptr<T> a(...); & block_ptr<T> a = ...;
may have some difference, I'm not sure...
Oh, oops, my overlooking, sorry for the noise.
Phil Bouchard wrote:
I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function.
I should think that would be named make_block_ptr().
Is it time for a review?
Perhaps you could just wait for discussion to die down and then ask to put it on the review queue. Furthermore, it seems you've not figured out why the factory function adds overhead. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 02/05/2011 17:17, Stewart, Robert wrote:
Phil Bouchard wrote:
I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function.
I should think that would be named make_block_ptr().
It should follow the same convention as (boost/std)::shared_ptr
Mathias Gaunard wrote:
On 02/05/2011 17:17, Stewart, Robert wrote:
Phil Bouchard wrote:
I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function.
I should think that would be named make_block_ptr().
It should follow the same convention as (boost/std)::shared_ptr
I don't like make_shared() for the same reason. (Now Joachim will have to jump in to declare that the name should be make_block() regardless! ;-) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 4/29/11 3:13 PM, Phil Bouchard wrote:
Is it time for a review?
Phil, While I feel bad saying "no" given that you are clearly so eager and have been working so hard to respond to all of the criticisms of your library in order to get a review, at this time the documentation is incredibly sparse and makes it very difficult to figure out what the point of the library is and how to use it from the perspective of a user uninterested in the technical details, so in my opinion you really need to flesh the documentation out a lot --- including the (currently non-existent?) reference section --- before asking for a review. Cheers, Greg
I depends on whether he is asking for a formal review, or for the suggested review of a preview version. The documentation at <https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.html> at least makes it clear what the library tried to do, and how the user is supposed to access this functionality. This is enough to allow for reasonable technical feedback. We are already seeing this type of feedback, for example with respect to the destruction order for cyclic references discussion. Regards, Thomas
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of Gregory Crosswhite Sent: Monday, May 02, 2011 7:16 PM To: boost@lists.boost.org Subject: Re: [boost] [Block Pointer] make_block
On 4/29/11 3:13 PM, Phil Bouchard wrote:
Is it time for a review?
Phil,
While I feel bad saying "no" given that you are clearly so eager and have been working so hard to respond to all of the criticisms of your library in order to get a review, at this time the documentation is incredibly sparse and makes it very difficult to figure out what the point of the library is and how to use it from the perspective of a user uninterested in the technical details, so in my opinion you really need to flesh the documentation out a lot --- including the (currently non-existent?) reference section --- before asking for a review.
Cheers, Greg _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 05/02/2011 10:36 AM, Thomas Klimpel wrote:
I depends on whether he is asking for a formal review, or for the suggested review of a preview version.
The documentation at
<https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.html>
at least makes it clear what the library tried to do, and how the user is supposed to access this functionality. This is enough to allow for reasonable technical feedback. We are already seeing this type of feedback, for example with respect to the destruction order for cyclic references discussion.
Regards, Thomas
I got the strong impression that he is asking for a formal review for the project in its current state rather than just preliminary technical feedback, but if I am wrong then you are of course correct that as it is now it is certainly good enough for reasonable technical feedback as is evidenced by the productive discussions we have seen on this point. Cheers, Greg
Phil, you've been asking for a formal review at what seems to be the conclusion of every response you give. It's unfortunate to say, and I say it impersonally, but it can get quite annoying. Just be patient and give things as long as they need. Give people more time to respond and even read this before you assume there's nothing more to say; it's going to take weeks or even months, and the best thing to do is just wait until this thing is really fleshed out and well informally-reviewed before you finally say "I think it's ready". On Tue, May 3, 2011 at 2:11 PM, Phil Bouchard <philippe@fornux.com> wrote:
On 5/2/2011 10:36 AM, Thomas Klimpel wrote:
I depends on whether he is asking for a formal review, or for the suggested review of a preview version.
I am asking for a formal review.
Thanks, -Phil
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GMan, Nick Gorski
On 5/3/2011 2:20 PM, GMan wrote:
Phil, you've been asking for a formal review at what seems to be the conclusion of every response you give. It's unfortunate to say, and I say it impersonally, but it can get quite annoying.
I know it was annoying but we don't live in a perfect world and I simply have forgotten part of the requirements. The name change didn't help either but now its seems to be descriptive enough.
Just be patient and give things as long as they need. Give people more time to respond and even read this before you assume there's nothing more to say; it's going to take weeks or even months, and the best thing to do is just wait until this thing is really fleshed out and well informally-reviewed before you finally say "I think it's ready".
This time everything is complete and I am happy it works well. I was in a hurry to complete all of the requirements because I had the opportunity to do so but it won't unfortunately be true in the weeks to follow. -Phil
On Tue, May 3, 2011 at 2:44 PM, Phil Bouchard <philippe@fornux.com> wrote:
This time everything is complete and I am happy it works well.
How do you know that? That's the issue here; you don't, and cannot until you leave time for people to take a look at it and comment. But it seems you assume after every fix that'll be the last one. :) -- GMan, Nick Gorski
On 5/3/2011 2:54 PM, GMan wrote:
How do you know that?
The tests it went through cover pretty much most of the possible problems.
That's the issue here; you don't, and cannot until you leave time for people to take a look at it and comment. But it seems you assume after every fix that'll be the last one. :)
This time is official. There might be an issue I still need to take a look at in a multi-threaded mode but in a single threaded mode everything is guaranteed to work well, or you'll have your money back ;) -Phil
On 05/03/2011 06:01 PM, Phil Bouchard wrote:
On 5/3/2011 2:54 PM, GMan wrote:
How do you know that?
The tests it went through cover pretty much most of the possible problems.
That's the issue here; you don't, and cannot until you leave time for people to take a look at it and comment. But it seems you assume after every fix that'll be the last one. :)
This time is official. There might be an issue I still need to take a look at in a multi-threaded mode but in a single threaded mode everything is guaranteed to work well, or you'll have your money back ;)
-Phil
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Then I will repeat what I said before and say that you really need to flesh out the documentation a whole lot before submitting it for a full review. At the moment the documentation is very user unfriendly, consisting mostly of a technical description of the ideas behind the implementation with basically the minimum number of token examples thrown in so that you could check a box saying that you included documentation explaining its usage. To get a sense of what you should be striving for, you should look at the documentation for some of the other Boost libraries such as Boost.Thread. One thing that I like about the documentation of Boost.Thread is that the reference documentation is structured in such a way that you can read through from beginning to end to learn about the full functionality of the library, which contrasts with your Doxygen-generated reference documentation which only helps those who know what they are looking for, and in particular contains what looks to me like both interface and implementation details so it is a bit overwhelming to a user who already doesn't know what is going on due to the sparseness of documentation everywhere else. I really want to emphasize this again since it is so important: a user considering using your library is not going to care about all of the fancy technical details behind it, he or she will want to know what kinds of problems it solves and how specifically it can be used to solve them, and you spend almost no time talking about this. Your library can be the greatest piece of code in the world but if it takes forever for anyone to learn how to use it then nobody will bother because there are plenty of "good enough" libraries out there that don't require as much trouble. Cheers, Greg
On 5/3/2011 6:32 PM, Gregory Crosswhite wrote:
I really want to emphasize this again since it is so important: a user considering using your library is not going to care about all of the fancy technical details behind it, he or she will want to know what kinds of problems it solves and how specifically it can be used to solve them, and you spend almost no time talking about this. Your library can be the greatest piece of code in the world but if it takes forever for anyone to learn how to use it then nobody will bother because there are plenty of "good enough" libraries out there that don't require as much trouble.
A comparison with shared_ptr should be helpful since everybody now should know shared_ptr (I'm basically expecting a user to know the standards). -Phil
On 5/3/2011 7:47 PM, Phil Bouchard wrote:
A comparison with shared_ptr should be helpful since everybody now should know shared_ptr (I'm basically expecting a user to know the standards).
I just added examples to the overview and clearly states the advantage of using block_ptr over shared_ptr: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/overvie... Thanks, -Phil
On 5/2/2011 10:16 AM, Gregory Crosswhite wrote:
On 4/29/11 3:13 PM, Phil Bouchard wrote:
Is it time for a review?
Phil,
While I feel bad saying "no" given that you are clearly so eager and have been working so hard to respond to all of the criticisms of your library in order to get a review, at this time the documentation is incredibly sparse and makes it very difficult to figure out what the point of the library is and how to use it from the perspective of a user uninterested in the technical details, so in my opinion you really need to flesh the documentation out a lot --- including the (currently non-existent?) reference section --- before asking for a review.
I just generated and committed the reference: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/html/an... "block_ptr_base" isn't there and I am currently trying to figure out why. -Phil
participants (7)
-
GMan -
Gregory Crosswhite -
Mathias Gaunard -
Phil Bouchard -
Stewart, Robert -
Thomas Klimpel -
TONGARI