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: [patch] Make vector::at() assertion message more useful


On Sun, 2013-08-18 at 11:38 +0100, Chris Jefferson wrote:
> On 18/08/13 08:09, VÃclav Zeman wrote:
> > On 08/17/2013 05:10 PM, Gabriel Dos Reis wrote:
> >> On Sat, Aug 17, 2013 at 5:41 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Paul Pluzhnikov <ppluzhnikov@google.com> ha scritto: __throw_out_of_range(__N("vector::_M_range_check"));
> >>>> +        {
> >>>> +          char __s[256];
> >>>> +          __builtin_snprintf(__s, sizeof(__s),
> >>>> +                             __N("vector::_M_range_check: %zu >= %zu"),
> >>>> +                             __n, this->size());
> >>>> +          __throw_out_of_range(__s);
> >>>> +        }
> >>> The idea makes sense, but while we are at it I think the message could be more clear, say what the two numbers are. Also, I don't think we can unconditionally call snprintf, it's C99 and supported targets lack it. Maybe with some libiberty magic? I don't think such magic automagically triggers when __builtin_snprintf is expanded, or does it? Please investigate that.
> >> I agree that we can't embark a significant IO library as part of a purely
> >> data structure components.
> >>
> >> Furthermore, __builtin_snprintf doesn't always expand to a
> >> compiler magic -- it can be a normal function call.
> >>
> >> This would be a regression, not an improvement.
> > What about adding a simple template function that converts integer into
> > std::string using division by 10? You could then concatenate the message
> > from std::string fragments, avoiding IO library but having to pull in
> > std::string instead. Would that be acceptable?
> Rather than making up new functions, why not use a std::ostringstream?

Because that would pull in the IO library parts, which is undesired in
this case.

Cheers,
Oleg


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