This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch 2/N] std::regex refactoring - sub _Executor for lookahead
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Tim Shen <timshen91 at gmail dot com>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 28 Apr 2014 15:55:26 +0100
- Subject: Re: [patch 2/N] std::regex refactoring - sub _Executor for lookahead
- Authentication-results: sourceware.org; auth=none
- References: <20140428124003 dot GW928 at redhat dot com> <20140428124535 dot GX928 at redhat dot com> <CAPrifDkFYPiDuS5s3VLJBgdkArveUFkx1j7s26bEdm0xRN0d=Q at mail dot gmail dot com>
On 28/04/14 10:18 -0400, Tim Shen wrote:
On Mon, Apr 28, 2014 at 8:45 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
Is there any reason this object is created on the heap?
Say, _Executor's size is so huge and a uncommon user gets a stack
overflow by keep invoking this function?
Ah yes, I didn't think of that. But the size of _Executor is fixed,
isn't it? If it has a huge number of states or matches those will be
on the heap anyway, in vectors/arrays.
It could be huge if instantiated with a huge iterator type, as it
stores three members of the iterator type, but I don't think users
should be too surprised if they overflow the stack with freakishly
large iterators :-)
Am I still missing something?
(I don't have a preference for whether to change this, but if we keep
it on the heap we should add a comment, or I'll keep forgetting the
rationale and try to change it again!)