On Tue, 26 Nov 2024 at 18:16, Marc Glisse wrote:
>
> On Tue, 26 Nov 2024, Jonathan Wakely wrote:
>
> >>> In the bla() example above, the call bla() is a constant expression
> >>> when used to initialize a const int, so the compiler is required to
> >>> evaluate it at compile time.
> >>
> >> When u
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
In the bla() example above, the call bla() is a constant expression
when used to initialize a const int, so the compiler is required to
evaluate it at compile time.
When used in contexts that doesn't require an integral constant I think a
distinction
Hello,
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
> So the 'const int' doesn't really matter for any -On level, as you
> say, but just avoiding two separate uses of the __deque_buf_size
> function is worthwhile for -std=c++98 -O0
Oh, definitely. Avoiding duplicate calls in C++ sources (no matt
On Tue, 26 Nov 2024 at 16:15, Michael Matz wrote:
>
> Hello,
>
> thanks for bearing with me :)
>
> On Tue, 26 Nov 2024, Jonathan Wakely wrote:
>
> > Being a member function makes no difference, but yes, I'm specifically
> > talking about the case of calling a constexpr function.
> >
> > constexpr
Hello,
thanks for bearing with me :)
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
> Being a member function makes no difference, but yes, I'm specifically
> talking about the case of calling a constexpr function.
>
> constexpr int bla() { return 2; }
> int foo (void) {
> const int x = bla();
>
On Tue, 26 Nov 2024 at 14:27, Michael Matz wrote:
>
> Hello,
>
> I don't have anything to add to the threads topic itself, but was
> triggered by something:
>
> On Tue, 26 Nov 2024, Jonathan Wakely wrote:
>
> > > > const size_t __bufsz = __deque_buf_size(sizeof(_Tp));
> > > ...
> > > I wonder wh
Hello,
I don't have anything to add to the threads topic itself, but was
triggered by something:
On Tue, 26 Nov 2024, Jonathan Wakely wrote:
> > > const size_t __bufsz = __deque_buf_size(sizeof(_Tp));
> > ...
> > I wonder why "const" is useful here.
>
> Because if you don't initialize a cons
> > diff --git a/libstdc++-v3/include/bits/deque.tcc
> > b/libstdc++-v3/include/bits/deque.tcc
> > index deb010a0ebb..e56cd0b9319 100644
> > --- a/libstdc++-v3/include/bits/deque.tcc
> > +++ b/libstdc++-v3/include/bits/deque.tcc
> > @@ -955,6 +955,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> >
On Tue, 26 Nov 2024 at 12:08, Jan Hubicka wrote:
>
> > > diff --git a/libstdc++-v3/include/bits/deque.tcc
> > > b/libstdc++-v3/include/bits/deque.tcc
> > > index deb010a0ebb..e56cd0b9319 100644
> > > --- a/libstdc++-v3/include/bits/deque.tcc
> > > +++ b/libstdc++-v3/include/bits/deque.tcc
> > > @
On 24/11/24 16:26 +0100, Jan Hubicka wrote:
Hi,
looking into reason why we still do throw_bad_alloc in clang binary I noticed
that quite few calls come from deque::_M_reallocate_map. This patch adds
unreachable to limit the size of realloc_map. _M_reallocate_map is called only
if new size is sm
> Hi,
> looking into reason why we still do throw_bad_alloc in clang binary I noticed
> that quite few calls come from deque::_M_reallocate_map. This patch adds
> unreachable to limit the size of realloc_map. _M_reallocate_map is called
> only
> if new size is smaller then max_size. map is an a
Hi,
looking into reason why we still do throw_bad_alloc in clang binary I noticed
that quite few calls come from deque::_M_reallocate_map. This patch adds
unreachable to limit the size of realloc_map. _M_reallocate_map is called only
if new size is smaller then max_size. map is an array holding
12 matches
Mail list logo