[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++11 move semantics
From: |
Hans Åberg |
Subject: |
Re: C++11 move semantics |
Date: |
Sun, 11 Mar 2018 18:44:41 +0100 |
> On 11 Mar 2018, at 18:29, Frank Heckenbach <address@hidden> wrote:
>
> Hans Åberg wrote:
>
>> In old computers, such a limit might have been seen as necessary.
>
> I don't think so. I think I was due to the implementation in C where
> dynamic data structures are much more effort to write. Otherwise
> it's better to let the programs use as much memory as they can (by
> system limits, ulimit, etc.) and not impose arbitrary limits.
But the C parser has had dynamic allocations up to the limit as far as I
recall, the 1990s. And there are POSIX specs for YACC.
>>> vector deque
>>> %left 7.7s 7.9s
>>> %right 8.9s 9.5s
>>>
>>> So go ahead and use deque if you prefer, but now I'm even less
>>> convinced it's worth it. :)
>>
>> It is a good chance it varies with the application.
>
> Maybe if you use an unreasably large type for a semantic value, or a
> type that has an expensive copy constructor and no move constructor.
> Both are like "don't do that" kind of things, but if you really need
> to, as I said you'll be able to use deque.
It best is to time in the specific application , if one thinks it is critical.
>>> In fact that's interesting to me outside of Bison. In another
>>> program I wrote in a different language long time ago which doesn't
>>> use Bison, I had implemented a double indirect allocation much like
>>> deque.
>>
>> Called handles. They may be required if objects pointed to need to move, as
>> in a two space copy gc.
>
> I know what handles are. Handle use double indirection, but not all
> double indirection means handles. Deque needs double indirection to
> go to the block, then to the item, whereas vector can go to the item
> directly.
It the past double indirection was considered slow, but today it is best to
test the specific application.
- Re: C++11 move semantics, (continued)
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/09
- Re: C++11 move semantics, Hans Åberg, 2018/03/09
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/09
- Re: C++11 move semantics, Hans Åberg, 2018/03/10
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/10
- Re: C++11 move semantics, Rici Lake, 2018/03/10
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics,
Hans Åberg <=
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/05
Re: C++11 move semantics, Hans Åberg, 2018/03/04