Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70695 > unrolled thread

What is the data structure of a NULL?

Back to article view | Back to comp.lang.c++

Contents

  What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 13:24 -0800
    Re: What is the data structure of a NULL? Ian Collins <ian-news@hotmail.com> - 2019-12-28 10:36 +1300
      Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 13:55 -0800
        Re: What is the data structure of a NULL? Bo Persson <bo@bo-persson.se> - 2019-12-28 11:28 +0100
      Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-27 20:50 -0500
        Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 17:14 -0800
        Re: What is the data structure of a NULL? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:56 -0800
    Re: What is the data structure of a NULL? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-27 22:42 +0100
      Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 13:55 -0800
        Re: What is the data structure of a NULL? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-27 23:10 +0100
        Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-27 14:15 -0800
          Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-27 14:24 -0800
            Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-27 14:41 -0800
            Re: What is the data structure of a NULL? Manfred <noname@add.invalid> - 2019-12-28 20:11 +0100
              Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 17:16 -0800
                Re: What is the data structure of a NULL? Manfred <noname@invalid.add> - 2019-12-29 17:52 +0100
                  Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-29 12:21 -0800
        Re: What is the data structure of a NULL? Bart <bc@freeuk.com> - 2019-12-28 01:46 +0000
          Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 17:17 -0800
            Re: What is the data structure of a NULL? Bart <bc@freeuk.com> - 2019-12-29 01:42 +0000
              Re: What is the data structure of a NULL? T <T@invalid.invalid> - 2019-12-28 18:39 -0800
    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-28 02:14 -0800
      Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-28 08:33 -0600
        Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-28 13:22 -0800
          Re: What is the data structure of a NULL? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-28 16:02 -0800
            Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-28 22:37 -0600
          Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-28 22:37 -0600
            Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-28 21:12 -0800
              Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-29 04:45 -0600
                Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 13:31 -0800
                  Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-29 21:34 -0600
                    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 22:48 -0800
                Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-29 20:20 -0500
                  Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-29 21:50 -0600
                    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-29 22:46 -0800
                      Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-30 10:25 +0100
                        Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 05:20 -0600
                          Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-30 17:24 +0100
                            Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 17:22 -0600
                              Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-31 13:57 +0100
                                Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 07:33 -0600
                                  Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-31 15:45 +0100
                          Re: What is the data structure of a NULL? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-30 18:16 +0000
                            Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-30 10:45 -0800
                              Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 17:29 -0600
                                Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-30 21:48 -0800
                      Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 04:19 -0600
                        Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-30 17:27 +0100
                      Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-30 03:25 -0800
                        Re: What is the data structure of a NULL? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-31 21:54 +0000
                    Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 06:03 -0800
                      Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-30 17:01 -0600
                        Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 21:42 -0500
                          Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 06:03 -0600
                            Re: What is the data structure of a NULL? Öö Tiib <ootiib@hot.ee> - 2019-12-31 06:17 -0800
                              Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 10:46 -0600
                                Re: What is the data structure of a NULL? Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 16:57 +0000
                                  Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2019-12-31 18:15 +0100
                                    Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-31 11:20 -0800
                                      Re: What is the data structure of a NULL? David Brown <david.brown@hesbynett.no> - 2020-01-01 17:01 +0100
                                  Re: What is the data structure of a NULL? Ned Latham <nedlatham@woden.valhalla.oz> - 2019-12-31 11:21 -0600
                                    Re: What is the data structure of a NULL? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-31 21:37 +0000
                                    Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-31 15:21 -0800
                                Re: What is the data structure of a NULL? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 17:26 +0000
                                Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-31 23:30 -0500
                                  Re: What is the data structure of a NULL? Manfred <noname@add.invalid> - 2020-01-01 18:10 +0100
                                    Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-01 12:21 -0500
                            Re: What is the data structure of a NULL? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 15:20 +0000
                              Re: What is the data structure of a NULL? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-31 11:11 -0800
                                Re: What is the data structure of a NULL? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 19:47 +0000
                            Re: What is the data structure of a NULL? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-31 10:27 -0800

Page 4 of 4 — ← Prev page 1 2 3 [4]

#70890

Melzzzzz wrote:
> Ned Latham wrote:
> > Öö Tiib wrote:

----snip----

> > > You were asked example of it ... is it so hard to produce one?
> >
> > int i, j;
> >
> > if (i - j == NULL) // then do whatever.
>
> except that this does not compiles. Imlicit conversion of int to pointer
> is not done...

Ok. if ((void*)(i - j) == NULL) // then do whatever.

[toc] | [prev] | [next] | [standalone]

#70908

On Tue, 2019-12-31, Ned Latham wrote:
> Melzzzzz wrote:
>> Ned Latham wrote:
>> > Öö Tiib wrote:
>
> ----snip----
>
>> > > You were asked example of it ... is it so hard to produce one?
>> >
>> > int i, j;
>> >
>> > if (i - j == NULL) // then do whatever.
>>
>> except that this does not compiles. Imlicit conversion of int to pointer
>> is not done...
>
> Ok. if ((void*)(i - j) == NULL) // then do whatever.

Then rewrite it as

    if (i==j)

and that reason to know extra things about null pointers disappears.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#70910

Ned Latham wrote:
> Ok. if ((void*)(i - j) == NULL)
>  // then do whatever.

Were you under the impression that the left hand side of that comparison was required to be a null pointer value when i==j? There is no such requirement. The requirement you're probably thinking is 7.11p1, but that only applies to integer literals with a value of zero. (i - j) is not an integer literal. 

Note that even if it does result in a null pointer value, the behavior would still not depend upon representation of null pointer values. NULL is required to expand to a null pointer constant, and the comparison causes it to be converted to void*, resulting in a null pointer value. All null pointer values are required to compare equal, regardless of how they are represented.

In any event, what did you expect this line of code to do that couldn't be done more simply and portable by writing if(i == j)?

[toc] | [prev] | [next] | [standalone]

#70892

On Tue, 31 Dec 2019 10:46:30 -0600
Ned Latham <nedlatham@woden.valhalla.oz> wrote:
> Öö Tiib wrote:
[snip]
> > That is addressed by different place of standard:
> > [conv.bool]
> > "A zero value, null pointer value, or null member pointer value is
> > converted to false; any other value is converted to true."
> 
> News to me. Might be because I'm a lazy reader or because my references
> are out of date: Kernigan and Ritchie for C (ANSI 2) and Stroustrup
> (Edition 3) for C++. Both 1990s.
> 
> > It does not say that bit-wise checks are made,
> 
> If NULL == 0, bitwise checks aren't required, just a check of the
> Z flag of the register that received the return.

'NULL == 0' will always evaluate to true, by virtue of the definition
of NULL.  The bit pattern of the integer literal 0 as null pointer
constant may be different from its bit pattern as an integer, so your
check is meaningless.

[toc] | [prev] | [next] | [standalone]

#70916

On 12/31/19 11:46 AM, Ned Latham wrote:
> �� Tiib wrote:
>> Ned Latham  wrote:
...
>> [conv.bool]
>> "A zero value, null pointer value, or null member pointer value is
>> converted to false; any other value is converted to true."
> 
> News to me. Might be because I'm a lazy reader or because my references
> are out of date: Kernigan and Ritchie for C (ANSI 2) and Stroustrup
> (Edition 3) for C++. Both 1990s.

Yes, those sources are thirty years out of date. bool didn't even exist
in K&R C, and if conditions were and are handled differently. In first
edition of K&R C, it says "The unary negation operator ! converts a
non-zero or true operand into 0, and a zero or false operand into l."
However, the second edition came out shortly before the C89 was
approved, and used wording closer to that of the soon-to-be approved
standard: "The operand of the ! operator must have arithmetic type or be
a pointer, and the result is 1 if the value of its operand compares
equal to 0, and 0 otherwise." (A.7.4.7). The key issue may is the phrase
"compares equal to". What happens when a pointer value is compared for
equality with 0? Comparison for equality is covered by A.7.10, and for
the special case where a pointer is "compared to a constant integral
expression with a value of 0", it cross-references A.6.6. That
paragraphs indicates that comparison operators are one way in which an
integral constant expression with a value of 0 gets converted to pointer
type, and it specifies that "This produces a null pointer that is equal
to another null pointer of the same type, but unequal to any pointer to
a function or object."

Thus, !array has the value !(array==0), and array==0 has a value of true
if array is a null pointer, and 1 if it does not, completely independent
of how null pointers are represented.
That is exactly the way the same issue is handled in all later versions
of the C standard.

My copy of Stroustrup disappeared a long time ago. My copy of the C++98
standard was saved on a hard disk which crashed. The oldest version of
the standard I can locate is C++2011. As of that version, the relevant
issues were addressed in the same fashion as in the current version: the
unary ! is described in terms of inverting the result of a conversion to
bool, and the rules for conversion to bool specify that null pointer
values get converted to false. Thus, the result is guaranteed to be
false for null pointer values, regardless of how they are represented.

I'm curious: how does the description of these issues in your copy of
Stroustrup differ from those descriptions? With the preceding C standard
and the following C++ standards so carefully written to produce results
that are independent of how null pointers are represented, it would seem
very odd if that version of C++ was defined in a way which did depend
upon the representation.


>> It does not say that bit-wise checks are made,
> 
> If NULL == 0, bitwise checks aren't required, just a check of the
> Z flag of the register that received the return.

How would that work? If null pointer values are, for instance,
represented by having all bits set to 1 (as has actually been done by at
least one implementation), NULL == 0 will still be true - the standard
requires it to be.

I suspect that your comments are specific to a particular architecture,
one for which "all bits 1" would not be a suitable choice for null
pointers. It was a very natural choice on the platform where that
representation was actually used.

[toc] | [prev] | [next] | [standalone]

#70936

On 1/1/2020 5:30 AM, James Kuyper wrote:
> I'm curious: how does the description of these issues in your copy of
> Stroustrup differ from those descriptions? With the preceding C standard
> and the following C++ standards so carefully written to produce results
> that are independent of how null pointers are represented, it would seem
> very odd if that version of C++ was defined in a way which did depend
> upon the representation.

FWIW, the current (fourth) edition says (§7.2.2):
"Before nullptr was introduced, zero (0) was used as a notation for the 
null pointer.
...
No object is allocated with the address 0, and 0 (the all-zeros bit 
pattern) is the most common representation of nullptr. Zero (0) is an 
int. However, the standard conversions (§10.5.2.3) allow 0 to be used as 
a constant of pointer or pointer-to-member type."

AFAICT, other references to nullptr do not make assumptions on the 
representation of the null pointer.

Note that §10.5.2.3 says that "A constant expression (...) that 
evaluates to 0 can be implicitly converted to a null pointer of any 
pointer type." and an example is given:

int* p = (1+2)*(2*(1-1)); // OK, but weird

"Prefer nullptr (§7.2.2)."

So, implicit conversion is not restricted to the integer literal 0 
(although anything else than nullptr is in fact deprecated).

[toc] | [prev] | [next] | [standalone]

#70938

On 1/1/20 12:10 PM, Manfred wrote:
> On 1/1/2020 5:30 AM, James Kuyper wrote:
>> I'm curious: how does the description of these issues in your copy of
>> Stroustrup differ from those descriptions? With the preceding C standard
>> and the following C++ standards so carefully written to produce results
>> that are independent of how null pointers are represented, it would seem
>> very odd if that version of C++ was defined in a way which did depend
>> upon the representation.
> 
> FWIW, the current (fourth) edition says (§7.2.2):
> "Before nullptr was introduced, zero (0) was used as a notation for the 
> null pointer.
> ...
> No object is allocated with the address 0, and 0 (the all-zeros bit 
> pattern) is the most common representation of nullptr. Zero (0) is an 
> int. However, the standard conversions (§10.5.2.3) allow 0 to be used as 
> a constant of pointer or pointer-to-member type."

That's not the most important issue. What does it say about:
1. Unary ! as applied to pointer values.
2. Conversion of pointer values to bool.
3. How if-conditions are interpreted.

> AFAICT, other references to nullptr do not make assumptions on the 
> representation of the null pointer.
> 
> Note that §10.5.2.3 says that "A constant expression (...) that 
> evaluates to 0 can be implicitly converted to a null pointer of any 
> pointer type." and an example is given:
> 
> int* p = (1+2)*(2*(1-1)); // OK, but weird
> 
> "Prefer nullptr (§7.2.2)."
> 
> So, implicit conversion is not restricted to the integer literal 0 
> (although anything else than nullptr is in fact deprecated).

Yes, that's a fairly recent change in the C++ standard - it used to
allow any integer constant expression with a value of 0, just like C
(though the C++ standard's definition of integral constant expressions
was slightly different from C's definition of integer constant expressions).

Of course, (i-j), where i and j are variables that just happen to
currently be equal, has never qualified, under any version of either
standard.

[toc] | [prev] | [next] | [standalone]

#70871

On Tue, 31 Dec 2019 06:03:32 -0600
Ned Latham <nedlatham@woden.valhalla.oz> wrote:
> James Kuyper wrote:
> 
> ----snip----
> 
> > The fundamental problem is that I won't even necessarily recognize what
> > you're referring to, even if it's staring me in the face. There's a
> > pretty good chance that what you think is code that depends upon the
> > representation of null pointers is, in fact, not so dependent.
> 
> I don't know why you haven't already got it. If NULL == 0 the same
> logic can be used with pointers as with integers and all their bitwidth
> lookalikes and all the functions that require or return those types.
> Tests like
> 
> if (!(array=calloc(hemeny,sizeof(arrayrcrd)))) // then deal with OOM.
> 
> wouldn't work correctly otherwise.
> 
> Knowing the way NULL is represented can be useful.

You have a point so far as concerns, say, memset'ing structs of
trivial type to all-bits-zero where those structs contain pointers
which you want to be NULL (should your code actually do that).  But you
are completely wrong in your example above.  'array' will be a null
pointer constant if calloc fails, and the test for falsity will work
correctly irrespective of whether the null pointer constant is
signalled by all-bits-zero.

You have something wrong with your mental image of this.

[toc] | [prev] | [next] | [standalone]

#70903

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
[...]
> You have a point so far as concerns, say, memset'ing structs of
> trivial type to all-bits-zero where those structs contain pointers
> which you want to be NULL (should your code actually do that).  But you

null, not NULL.

> are completely wrong in your example above.  'array' will be a null
> pointer constant if calloc fails, and the test for falsity will work
> correctly irrespective of whether the null pointer constant is
> signalled by all-bits-zero.

'array' will be a null pointer, not a null pointer constant.

A *null pointer constant* is a source code construct (and NULL is a
macro that expands to a null pointer constant).  A *null pointer* is a
value that can exist at run time.

It's probably OK in most cases to use the term "NULL" to refer to a null
pointer value, but in this case the distinction is a large part of what
we're talking about, so I suggest being a bit more pedantic than usual.

> You have something wrong with your mental image of this.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#70905

On Tue, 31 Dec 2019 11:11:17 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> [...]
> > You have a point so far as concerns, say, memset'ing structs of
> > trivial type to all-bits-zero where those structs contain pointers
> > which you want to be NULL (should your code actually do that).  But you
> 
> null, not NULL.

I think you mean that "hold a null pointer value" should replace "be
NULL".  If so, I don't object although I think the meaning is clear
enough and you are being somewhat on the pedantic side.

> > are completely wrong in your example above.  'array' will be a null
> > pointer constant if calloc fails, and the test for falsity will work
> > correctly irrespective of whether the null pointer constant is
> > signalled by all-bits-zero.
> 
> 'array' will be a null pointer, not a null pointer constant.
> 
> A *null pointer constant* is a source code construct (and NULL is a
> macro that expands to a null pointer constant).  A *null pointer* is a
> value that can exist at run time.

I agree, clumsy language - for one thing, 'array' is neither a
constant nor a literal.  As you say, I meant that 'array' will hold a
null pointer value.  I doubt anyone misunderstood me however.

> It's probably OK in most cases to use the term "NULL" to refer to a null
> pointer value, but in this case the distinction is a large part of what
> we're talking about, so I suggest being a bit more pedantic than usual.

[toc] | [prev] | [next] | [standalone]

#70899

Ned Latham wrote:
> James Kuyper wrote:
>
> ----snip----

> > The fundamental problem is that I won't even necessarily recognize what
> > you're referring to, even if it's staring me in the face. There's a
> > pretty good chance that what you think is code that depends upon the
> > representation of null pointers is, in fact, not so dependent.
> 
> I don't know why you haven't already got it. If NULL == 0 the same
> logic can be used with pointers as with integers and all their bitwidth
> lookalikes and all the functions that require or return those types.

NULL is absolutely guaranteed to compare equal to 0 when using any
conforming implementation of C++, regardless of how null pointers are
represented. That's because NULL is required to expand into a null
pointer constant (21.2.3p2). 7.11p1 allows for only two possibilities
for a null pointer constant. The first is that it can be an "integer
literal with a value of zero", which obviously compares equal to 0. The
second is that it can be "a prvalue of type std::nullptr_t". Since the 0
it's being compared with also qualifies as a null pointer constant, they
necessarily compare equal (8.10p4). Therefore, checking whether NULL==0
doesn't give you any information about whether an implementation has
null pointers with all bits set to zero.
This matters if you've made the mistake of relying on things like
calloc() or memset(0) to fill pointer objects with representations of
null pointers. On the flip side, it's not a problem if you're relying
on zero-initialization, since zero-initialization of a pointer is
guaranteed to give it a valid representation of a null pointer(11.6p6,
7.11p1), even if that representation doesn't have all bits 0.

> Tests like
>
> if (!(array=calloc(hemeny,sizeof(arrayrcrd)))) // then deal with OOM.
>
> wouldn't work correctly otherwise.

Yes they will. 
Clause 8.3.1p9 says "The operand of the logical negation operator ! is
contextually converted to bool (Clause 7); its value is true if the
converted operand is false and false otherwise. The type of the result
is bool." 7.14p1 describes the results of converting values to bool. It
says that "A ... null pointer value ... is converted to false ...".
That's true, regardless of how null pointers are represented. Therefore,
this code does precisely what it's supposed to do, regardless of that
representation.

Note that this also applies to if(array). In all statements that contain
a condition (other than switch), the condition is "... contextually
converted to bool ..." (9p4). All null pointers, regardless of how they
are represented, convert to a bool value of false, so using a pointer as
a condition always handles null pointer values the way you'd expect,
even if the representation of null values is not what you'd expect

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c++

csiph-web