[PATCH][GSoC] Extend shared_ptr to support arrays

Jonathan Wakely jwakely@redhat.com
Tue Jun 16 13:28:00 GMT 2015


On 16/06/15 21:15 +0800, Fan You wrote:
>> You will also need to write new tests (under testsuite/experimental/)
>> to check that your new code works as intended.
>
>
>Is there any pattern or rules I should follow when writing testcase, or I
>can just refer to 20_util/* and add some array specified tests?

Follow the style of the 20_util tests, but put the new ones under
testsuite/experimental. Tim can help you with any questions about the
testsuite, it doesn't need to be discussed on the gcc-patches list
(since there's nothing ready to be committed yet anyway).

>> I wonder if all the new code really needs to be in <bits/shared_ptr.h>
>>
>
>why it need to be in <bits/shared_ptr.h>?

It doesn't, that's what I mean.

All the new code is only usable after including <experimental/memory>,
but you have added lots of code to <bits/shared_ptr.h>.

>> or if it can just be in <experimental/memory> instead. There should be
>> no need to declare most of it (except maybe the enable_shared_from_this
>> parts?) when users include <memory>.
>>
>>
>>
>>
>So, what else should I do before its ready to be committed?

Tests, tests and more tests.

Currently you haven't got a single test, so I have no way of knowing
if the code even does what it's supposed to do.

Once you have written tests and they all pass then we can review the
code again fully and get it ready to commit. We are not there yet.

It might be a good idea to publish your changes somewhere visible, so
that people who want to try your code can clone it and test it without
having to apply patches. Are you using Git locally?  If you have a
github account you could fork https://github.com/gcc-mirror/gcc and
then push your changes to a new branch in your fork.



More information about the Libstdc++ mailing list