| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the system queue header file fully usable within C++ programs by
adding macros to define class lists.
This change is backwards compatible for all use within C and C++
programs. Only C++ programs will have added support to use the queue
macros within classes. Previously the queue macros could only be used
within structures.
The queue.3 manual page has been updated to describe the new
functionality and some alphabetic sorting has been done while
at it.
Differential Revision: https://reviews.freebsd.org/D2745
PR: 200827 (exp-run)
|
|
|
|
|
|
|
|
| |
r281605:
Fix a minor function definition inconsistancy.
r281768:
Bump doc date missed in r281605.
|
|
|
|
|
|
|
|
|
|
|
| |
optionally start the traversal from a previously found element by passing the
element in as "var". Passing a NULL "var" retains the same semantics as the
regular FOREACH macros.
Kudos to phk for suggesting the "FROM" suffix instead of my original proposal.
Reviewed by: jhb (previous version), rpaulo
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regular LISTs have been implemented in such a way that the prev-pointer
does not point to the previous element, but to the next-pointer stored
in the previous element. This is done to simplify LIST_REMOVE(). This
macro can be implemented without knowing the address of the list head.
Unfortunately this makes it harder to implement LIST_PREV(), which is
why this macro was never here. Still, it is possible to implement this
macro. If the prev-pointer points to the list head, we return NULL.
Otherwise we simply subtract the offset of the prev-pointer within the
structure.
It's not as efficient as traversing forward of course, but in practice
it shouldn't be that bad. In almost all use cases, people will want to
compare the value returned by LIST_PREV() against NULL, so an optimizing
compiler will not emit code that does more branching than TAILQs.
While there, make the code a bit more readable by introducing
__member2struct(). This makes STAILQ_LAST() far more readable.
MFC after: 1 month
|
|
|
|
|
|
| |
text to the remaining description.
Approved by: re
|
|
|
|
|
|
|
|
| |
Also place STAILQ_REMOVE_HEAD in alphabetical order. Lastly, document
the _SWAP macros.
PR: kern/143033
MFC after: 1 week
|
|
|
|
|
|
|
| |
It has also been included within the feature lists to which it is relevant.
Submitted by: tobez
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
| |
PR: 140615
Submitted by: Andrius Morkunas <hinokind@gmail.com>
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Last year I added SLIST_REMOVE_NEXT and STAILQ_REMOVE_NEXT, to remove
entries behind an element in the list, using O(1) time. I recently
discovered NetBSD also has a similar macro, called SLIST_REMOVE_AFTER.
In my opinion this approach is a lot better:
- It doesn't have the unused first argument of the list pointer. I added
this, mainly because OpenBSD also had it.
- The _AFTER suffix makes a lot more sense, because it is related to
SLIST_INSERT_AFTER. _NEXT is only used to iterate through the list.
The reason why I want to rename this now, is to make sure we don't
release a major version with the badly named macros.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though single linked lists allow items to be removed at constant time
(when the previous element is known), the queue macro's don't allow this.
Implement new REMOVE_NEXT() macro's. Because the REMOVE() macro's also
contain the same code, make it call REMOVE_NEXT().
The OpenBSD version of SLIST_REMOVE_NEXT() needs a reference to the list
head, even though it is unused. We'd better mimic this. The STAILQ version
also needs a reference to the list. This means the prototypes of both
macro's are the same.
Approved by: philip (mentor)
PR: kern/121117
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
in the man page update.
PR: docs/94938
Submitted by: Ed Schouten <ed@fxq.nl>
MFC After: 3 days
|
|
|
|
|
|
|
| |
If a tail queue is empty the return value of TAILQ_LAST is not
undefined, it is NULL.
Submitted by: Ruslan Ermilov <ru@FreeBSD.org>
|
|
|
|
| |
undefined, it is NULL.
|
|
|
|
|
|
| |
deletion' example.
MFC after: 1 week
|
|
|
|
|
| |
PR: 75581
Submitted by: Nobuyuki Koganemaru n-kogane@syd.odn.ne.jp (original version)
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Asked with "please" by Ruslan Ermilov. I've always had a weakness
for "please".
|
|
|
|
|
|
|
| |
PR: 20024
Submitted by: Tony Finch <dot@dotat.at> (TAILQ_CONCAT, slightly changed
by me)
Reviewed by: ru (earlier version)
|
| |
|
|
|
|
| |
(TAILQ_FOREACH leaves the variable NULL if there were no more to do)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
cd src/share; find man[1-9] -type f|xargs perl -pi -e 's/[ \t]+$//'
BTW, what editors are the culprits? I'm using vim and it shows
me whitespace at EOL in troff files with a thick blue block...
Reviewed by: Silence from cvs diff -b
MFC after: 7 days
|
| |
|
|
|
|
|
|
| |
PR: 25184
Submitted by: Alex Kapranoff <alex@kapran.bitmcnit.bryansk.su>
Approved by: nik
|
| |
|
|
|
|
|
|
| |
Retire them before anybody starts to use them again.
Use TAILQ instead, it provides the same functionality.
|
|
|
|
|
| |
called 'elm'. It doesn't take an arg 'elm', it simply removes the
element at the head of the list.
|
| |
|
|
|
|
|
|
|
| |
(2) fix a STAILQ_HEAD that should have been STAILQ_FIRST
Requested by: (1) bde
(2) W Gerald Hicks <jhix@mindspring.com>
|
|
|
|
| |
Submitted by: Jake Burkholder <jburkhol@home.com>
|
|
|
|
|
|
|
| |
TAILQ_REMOVE_HEAD.
PR: docs/17590
Submitted by: Benno Rice <benno@netizen.com.au>
|
|
|
|
|
| |
PR: docs/15036
Submitted by: Jake Burkholder <jburkhol@home.com>
|
| |
|
|
|
|
|
| |
PR: 6868
Submitted by: Josh Gilliam <josh@quick.net>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Is it time to split this into one "intro" type and a number of
detailed pages ?
|
| |
|
| |
|
| |
|
| |
|