Peter Eisentraut wrote:
> Larry Rosenman writes:
>
> > You can reduce the example down to
> >
> > extern char *strcpy(char *, const char *);
> >
> > static void f(char *p, int n){
> >strcpy(p+n,"");
> > }
> > void g(void){
> >f(0, 0);
> > }
> >
> > compi
Ok, I've attached new versions of list.c and pg_list.h -- this is just a
*rough sketch* of the new List code -- it definitely won't compile, the
intent is just to concretely specify the new List design. Also, I've
only updated the important list functions: I stopped at nth().
(I've attached the wh
--On Wednesday, November 05, 2003 04:23:35 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Peter Eisentraut wrote:
Larry Rosenman writes:
> You can reduce the example down to
>
>extern char *strcpy(char *, const char *);
>
>static void f(char *p, int n){
> strcpy(p+n,"");
>
Neil Conway <[EMAIL PROTECTED]> writes:
> #define length(l) ((l)->length)
> #define value(cell) ((cell)->elem.ptr_value)
> #define ivalue(cell) ((cell)->elem.int_value)
> #define ovalue(cell) ((cell)->elem.oid_value)
Couple of objections here
I said:
> No, lfirst and friends will need to apply to ListCells not to Lists,
> else the coding of foreach loops will break everywhere. I think there
> are many more places that will want lfirst to apply to a ListCell than
> will want it to apply to a raw List.
On the other hand, we will need to
Neil Conway wrote:
Ok, I've attached new versions of list.c and pg_list.h -- this is just a
*rough sketch* of the new List code -- it definitely won't compile, the
intent is just to concretely specify the new List design. Also, I've
only updated the important list functions: I stopped at nth().
(I'
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Why instead of reinvent the whell not use, or at least do a "C" port of
> stl::list ?
Because (a) implementing a linked list is pretty trivial (b) the only
difficult part is getting the semantics / API right. I don't see how
std::list would help with (
This is a repost of my 29 Oct 2003 message, which didn't seem to make it all
the way in. It restores Tcl 8.0 compatibility, which was lost in my patch to
fix corrupt binary data transfer in pg_lo_read and pg_lo_write. Sorry, this
is against PostgreSQL-7.4beta5 which was the latest when I did this u
Neil Conway wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
Why instead of reinvent the whell not use, or at least do a "C" port of
stl::list ?
Because (a) implementing a linked list is pretty trivial (b) the only
difficult part is getting the semantics / API right. I don't see how
std::list
ljb <[EMAIL PROTECTED]> writes:
> +#if TCL_MAJOR_VERSION == 8 && TCL_MINOR_VERSION >= 1 || TCL_MAJOR_VERSION > 8
> + bufObj = Tcl_NewByteArrayObj(buf, nbytes);
> +#else
> bufObj = Tcl_NewStringObj(buf, nbytes);
> +#endif
Hmm. We could certainly do it like that, but does this actually fi
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> An interesting think that stl::list do is to never do
> an "if" branch during an insert/remove phase
Why is this significant? Surely you're not claiming that avoid the
branch will affect performance in a meaningful way...
> What if you will never call
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> [ use list with master node and circular linking ]
> now is very late here ( 04:17 AM ) so I wrote
> the wrong code ( not checked ) but show the idea of
> avoid "if".
This saves an "if" during addition of a list item, at the cost of
greater expense du
Neil Conway <[EMAIL PROTECTED]> writes:
> (2) An additional word per List is hardly a prohibitive amount of
> overhead, as we don't create an obscene number of Lists (saving a
> word per ListCell would be a different matter).
Actually, it's free, considering that the alternatives are
Tom Lane <[EMAIL PROTECTED]> writes:
> This does suggest that it might be worth making the struct layout be
>
> int NodeTag;
> int length;
> foo *head;
> foo *tail;
>
> since this would avoid some padding overhead on a machine where pointers
> are 8 bytes and need 8-byte ali
14 matches
Mail list logo
