This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [profile-stdlib][patch] Stdlib advisory tool implemetation


Hello Paolo,

Thank you for the review!  It is very helpful, especially that we do
not have any prior experience with libstdc++-v3 internals.  We'll go
over them carefully and fix what you pointed out.

For now, I just want to make sure I understand the part with the
release schedule.  You mention convincing maintainers about putting it
in 4.4.0, but we are developing on a branch [profile-stdlib] and do
not plan to merge into trunk until the next stage 1.  I think we are
only about 30% done with implementation and keep coming up with new
ideas faster than we can code them.  Our targeted merge point is
sometime early next year.  Does this schedule make sense?


Thank you,
Silvius


On Thu, Aug 28, 2008 at 2:43 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>
> Hi,
>
> and first congratulations for the excellent progress in this project!
>
> I have a few rather basic comments:
> 1- Certainly new testcases don't go in 31_*, because those numbers correspond to chapters in the Standard, and I don't think this is an ISO Standard yet ;) Maybe subdirectory of the existing onew are ok, as we are doing for debug-mode. Or, if you want, a separate subdir is ok, but with a different name.
> 2- Are you really, really, sure you have to change the compiler driver? First, we are very close to the end of Stage 1, and we have only a few days to convince the compiler maintainers that this is an important change for 4.4.0, in case should be submitted separately and clearly "advertised". Anyway, for debug-mode and parallel-mode we don't do that, and, at the very least for consistency, I think we should reconsider carefully the option of simply defining macros.
> 3- Similarly, are you really, really, really, sure you need a separate library? For debug-mode, which isn't really trivial, we managed to avoid that.
> 4- Afterwards, there are smaller issues, like I'm seeing many non-"uglified" symbols in headers included by the user-code, this is a no-no, *everything* (besides the names of functions, classes and constants specified in the Standard, of course) must begin by __ or _ + Capital (macros included, really there are no exceptions).
> 5- In general, we never include C headers, always the <c*> versions and we qualify with std:: the calls.
> 6- More important, **make sure** not using anything not in C89 without proper configure-time tests checking for the availability of the facility on the given target (then, conditionally, it's Ok including, e.g., <execinfo.h>)
>
> Huumm... if the above issues are satisfactorily resolved, I think we are actually not so far from committing something!
>
> Paolo.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]