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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#70753

On 2019-12-28 17:42, Bart wrote:
> On 29/12/2019 01:17, T wrote:
>> On 2019-12-27 17:46, Bart wrote:
>>> At what level are you coding, assembly?
>>
>> https://docs.raku.org/language/nativecall
> 
> 
> So, this seems to be (or was) Perl6, and it already has a foreign 
> function interface. Then you need to investigate how such calls are done 
> using Raku's FF interface. For example it says this:
> 
> "Note that a NULL string pointer can be passed by passing the Str type 
> object; a NULL return will also be represented by the type object."
> 
> Doesn't mean much to me, but in any case it's not really to do with C or 
> C++ (half of WinAPI was originally C but MS renamed all those C 
> interfaces as C++ at some point.)
> 
> I'm surprised there isn't a ready-made set of 'bindings' to WinAPI, 
> rather than having to create your own (there are some 10,000 WinAPI 
> functions plus 1000s of structs, types, macros and messages).
> 
> Even if you did know that a NULL pointer was passed as an all-zeros 32- 
> or 64-bit value or whatever, it would be unwise to go that low level; 
> you should use whatever Raku suggests is used as a null pointer.

Perl 5 has a WinAPI, but Perl6/Raku does not yet.

Native Call's documentation is terrible.  You have to experiment until 
you get it right.

I do believe that to pass a NULL, you just put "$" without
the quotes as the variable to be passed.  But I haven't
tested it yet.  It is also undocumented.

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

#70728

T <T@invalid.invalid> writes:
> In C++, when you make a call to Windows Kernel32.dll
> and it wants a NULL for one or more of its parameters,
> what exactly is the structure of a NULL?  A 32 bit
> word full of zeros?

You might get better answers if you explained why you want to know.

If you're making a call from C++, you can just pass a null pointer
value such as nullptr or NULL.  The compiler needs to know how
it's represented.  You probably don't.

-- 
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]

#70734

Keith Thompson wrote:
> T writes:
> >
> > In C++, when you make a call to Windows Kernel32.dll
> > and it wants a NULL for one or more of its parameters,
> > what exactly is the structure of a NULL?  A 32 bit
> > word full of zeros?
>
> You might get better answers if you explained why you want to know.
>
> If you're making a call from C++, you can just pass a null pointer
> value such as nullptr or NULL.  The compiler needs to know how
> it's represented.  You probably don't.

But knowing it can be useful, I use (void*) to cast integers and
unsigned integers for functions that require pointer parameters,
and if (parm) to test them.

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

#70744

Ned Latham <nedlatham@woden.valhalla.oz> writes:
> Keith Thompson wrote:
>> T writes:
>> >
>> > In C++, when you make a call to Windows Kernel32.dll
>> > and it wants a NULL for one or more of its parameters,
>> > what exactly is the structure of a NULL?  A 32 bit
>> > word full of zeros?
>>
>> You might get better answers if you explained why you want to know.
>>
>> If you're making a call from C++, you can just pass a null pointer
>> value such as nullptr or NULL.  The compiler needs to know how
>> it's represented.  You probably don't.
>
> But knowing it can be useful, I use (void*) to cast integers and
> unsigned integers for functions that require pointer parameters,
> and if (parm) to test them.

Why?  Can you share some examples?

If a function takes a pointer parameter, you need to pass a pointer
value to it.  There are cases where it might make sense to cast
an integer to void*, but they're rare.  If you need to pass a null
pointer, use nullptr or NULL.  (In some low-level code, you might
store pointer values in integers.)  As for `if (parm)`, that's
valid for any scalar type.

-- 
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]

#70746

On 12/28/2019 1:22 PM, Keith Thompson wrote:
> Ned Latham <nedlatham@woden.valhalla.oz> writes:
>> Keith Thompson wrote:
>>> T writes:
>>>>
>>>> In C++, when you make a call to Windows Kernel32.dll
>>>> and it wants a NULL for one or more of its parameters,
>>>> what exactly is the structure of a NULL?  A 32 bit
>>>> word full of zeros?
>>>
>>> You might get better answers if you explained why you want to know.
>>>
>>> If you're making a call from C++, you can just pass a null pointer
>>> value such as nullptr or NULL.  The compiler needs to know how
>>> it's represented.  You probably don't.
>>
>> But knowing it can be useful, I use (void*) to cast integers and
>> unsigned integers for functions that require pointer parameters,
>> and if (parm) to test them.
> 
> Why?  Can you share some examples?
> 
> If a function takes a pointer parameter, you need to pass a pointer
> value to it.  There are cases where it might make sense to cast
> an integer to void*, but they're rare.  If you need to pass a null
> pointer, use nullptr or NULL.  (In some low-level code, you might
> store pointer values in integers.)  As for `if (parm)`, that's
> valid for any scalar type.
> 

Fwiw, I remember using 0xDEADBEEF as a special place holder for a 
pointer in some lock-free algorithms. The pointer would have the value 
of 0xDEADBEEF in order to indicate a condition that was in progress to 
the algorihtm.

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

#70755

Chris M. Thomasson wrote in <qu8qej$q5p$3@gioia.aioe.org>:
> On 12/28/2019 1:22 PM, Keith Thompson wrote:
>> Ned Latham <nedlatham@woden.valhalla.oz> writes:
>>> Keith Thompson wrote:
>>>> T writes:
>>>>>
>>>>> In C++, when you make a call to Windows Kernel32.dll
>>>>> and it wants a NULL for one or more of its parameters,
>>>>> what exactly is the structure of a NULL?  A 32 bit
>>>>> word full of zeros?
>>>>
>>>> You might get better answers if you explained why you want to know.
>>>>
>>>> If you're making a call from C++, you can just pass a null pointer
>>>> value such as nullptr or NULL.  The compiler needs to know how
>>>> it's represented.  You probably don't.
>>>
>>> But knowing it can be useful, I use (void*) to cast integers and
>>> unsigned integers for functions that require pointer parameters,
>>> and if (parm) to test them.
>> 
>> Why?  Can you share some examples?
>> 
>> If a function takes a pointer parameter, you need to pass a pointer
>> value to it.  There are cases where it might make sense to cast
>> an integer to void*, but they're rare.  If you need to pass a null
>> pointer, use nullptr or NULL.  (In some low-level code, you might
>> store pointer values in integers.)  As for `if (parm)`, that's
>> valid for any scalar type.
>> 
>
> Fwiw, I remember using 0xDEADBEEF as a special place holder for a 
> pointer in some lock-free algorithms. The pointer would have the value 
> of 0xDEADBEEF in order to indicate a condition that was in progress to 
> the algorihtm.

Good one.

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

#70754

Keith Thompson wrote:
> Ned Latham writes:
> > Keith Thompson wrote:
> > > T writes:
> > > >
> > > > In C++, when you make a call to Windows Kernel32.dll
> > > > and it wants a NULL for one or more of its parameters,
> > > > what exactly is the structure of a NULL?  A 32 bit
> > > > word full of zeros?
> > >
> > > You might get better answers if you explained why you want to know.
> > >
> > > If you're making a call from C++, you can just pass a null pointer
> > > value such as nullptr or NULL.  The compiler needs to know how
> > > it's represented.  You probably don't.
> >
> > But knowing it can be useful, I use (void*) to cast integers and
> > unsigned integers for functions that require pointer parameters,
> > and if (parm) to test them.
>
> Why? Can you share some examples?

Why? In what way does the above need elucidation?

> If a function takes a pointer parameter, you need to pass a pointer
> value to it.  There are cases where it might make sense to cast
> an integer to void*, but they're rare.

Irelevant.

>                                         If you need to pass a null
> pointer, use nullptr or NULL.

Why? (void*) (well okay (defined_type*), actually) does perfectly well,
and it does away with the clumsiness of switching between constant
and variable.

>                                (In some low-level code, you might
> store pointer values in integers.)

Indeed.

>                                     As for `if (parm)`, that's
> valid for any scalar type.

Precisely.

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

#70756

Ned Latham <nedlatham@woden.valhalla.oz> writes:
> Keith Thompson wrote:
>> Ned Latham writes:
>> > Keith Thompson wrote:
>> > > T writes:
>> > > >
>> > > > In C++, when you make a call to Windows Kernel32.dll
>> > > > and it wants a NULL for one or more of its parameters,
>> > > > what exactly is the structure of a NULL?  A 32 bit
>> > > > word full of zeros?
>> > >
>> > > You might get better answers if you explained why you want to know.
>> > >
>> > > If you're making a call from C++, you can just pass a null pointer
>> > > value such as nullptr or NULL.  The compiler needs to know how
>> > > it's represented.  You probably don't.
>> >
>> > But knowing it can be useful, I use (void*) to cast integers and
>> > unsigned integers for functions that require pointer parameters,
>> > and if (parm) to test them.
>>
>> Why? Can you share some examples?
>
> Why? In what way does the above need elucidation?

You indicated that it's useful to know how a null pointer is
represented.  How is it useful?  Most of the time, the representation
doesn't matter.

>> If a function takes a pointer parameter, you need to pass a pointer
>> value to it.  There are cases where it might make sense to cast
>> an integer to void*, but they're rare.
>
> Irelevant.

Irrelevant to what exactly?

>>                                         If you need to pass a null
>> pointer, use nullptr or NULL.
>
> Why? (void*) (well okay (defined_type*), actually) does perfectly well,
> and it does away with the clumsiness of switching between constant
> and variable.

Do you mean "(void*)0"?  Yes, that's a valid null pointer constant, but
why do you prefer it to NULL or nullptr?  What do you mean by "switching
between constant and variable"?

>>                                (In some low-level code, you might
>> store pointer values in integers.)
>
> Indeed.
>
>>                                     As for `if (parm)`, that's
>> valid for any scalar type.
>
> Precisely.

Precisely what?  If parm is of pointer type, `if (parm)` tests whether
it's a null pointer or not, regardless of how it's represented.  You
seemed to be using that as an example of why it's useful to know how
pointers are represented.  It isn't.

Perhaps I'm missing something.  What exactly was your point?

-- 
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]

#70767

Keith Thompson wrote:
> Ned Latham writes:
> > Keith Thompson wrote:
> > > Ned Latham writes:
> > > > Keith Thompson wrote:
> > > > > T writes:
> > > > > >
> > > > > > In C++, when you make a call to Windows Kernel32.dll
> > > > > > and it wants a NULL for one or more of its parameters,
> > > > > > what exactly is the structure of a NULL?  A 32 bit
> > > > > > word full of zeros?
> > > > >
> > > > > You might get better answers if you explained why you want to know.
> > > > >
> > > > > If you're making a call from C++, you can just pass a null pointer
> > > > > value such as nullptr or NULL.  The compiler needs to know how
> > > > > it's represented.  You probably don't.
> > > >
> > > > But knowing it can be useful, I use (void*) to cast integers and
> > > > unsigned integers for functions that require pointer parameters,
> > > > and if (parm) to test them.
> > >
> > > Why? Can you share some examples?
> >
> > Why? In what way does the above need elucidation?
>
> You indicated that it's useful to know how a null pointer is
> represented.  How is it useful?  Most of the time, the representation
> doesn't matter.

Knowing it's useful in that it enables me to use it.

> > > If a function takes a pointer parameter, you need to pass a pointer
> > > value to it.  There are cases where it might make sense to cast
> > > an integer to void*, but they're rare.
> >
> > Irrelevant.
>
> Irrelevant to what exactly?

Except for that last phrase "but they're rare", your statement amounts to
an acceptance (inadveratant, I'm sure) of what I'm saying. You agree that
"there are cases"; their rarity or otherwise is irrelevanbt.

> > >                                         If you need to pass a null
> > > pointer, use nullptr or NULL.
> >
> > Why? (void*) (well okay (defined_type*), actually) does perfectly well,
> > and it does away with the clumsiness of switching between constant
> > and variable.
>
> Do you mean "(void*)0"?

Not particularly. (void*) applies safely to variables on systems where
sizeof(int) == sizeof(void*).

>                          Yes, that's a valid null pointer constant, but
> why do you prefer it to NULL or nullptr?  What do you mean by "switching
> between constant and variable"?

Pointer arithmetic.

> > >                                (In some low-level code, you might
> > > store pointer values in integers.)
> >
> > Indeed.
> >
> > >                                     As for `if (parm)`, that's
> > > valid for any scalar type.
> >
> > Precisely.
>
> Precisely what?

It's valid for pointers. If that's useful, use it.

>                  If parm is of pointer type, `if (parm)` tests whether
> it's a null pointer or not, regardless of how it's represented.  You
> seemed to be using that as an example of why it's useful to know how
> pointers are represented.  It isn't.
>
> Perhaps I'm missing something.  What exactly was your point?

I've stated it in every post in this thread. Knowing how NUL is
represented can be useful.

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

#70787

Ned Latham <nedlatham@woden.valhalla.oz> writes:
> Keith Thompson wrote:
>> Ned Latham writes:
>> > Keith Thompson wrote:
>> > > Ned Latham writes:
>> > > > Keith Thompson wrote:
>> > > > > T writes:
>> > > > > >
>> > > > > > In C++, when you make a call to Windows Kernel32.dll
>> > > > > > and it wants a NULL for one or more of its parameters,
>> > > > > > what exactly is the structure of a NULL?  A 32 bit
>> > > > > > word full of zeros?
>> > > > >
>> > > > > You might get better answers if you explained why you want to know.
>> > > > >
>> > > > > If you're making a call from C++, you can just pass a null pointer
>> > > > > value such as nullptr or NULL.  The compiler needs to know how
>> > > > > it's represented.  You probably don't.
>> > > >
>> > > > But knowing it can be useful, I use (void*) to cast integers and
>> > > > unsigned integers for functions that require pointer parameters,
>> > > > and if (parm) to test them.
>> > >
>> > > Why? Can you share some examples?
>> >
>> > Why? In what way does the above need elucidation?
>>
>> You indicated that it's useful to know how a null pointer is
>> represented.  How is it useful?  Most of the time, the representation
>> doesn't matter.
>
> Knowing it's useful in that it enables me to use it.

I'm about to give up on this conversation, since it seems unlikely to go
anywhere useful.

99% of the time, there is no good reason to care in C++ how a null
pointer, or any other pointer value, is represented.  It's an
abstraction.  You can write C++ code that uses null pointers, and you
haven't done anything unnecessarily tricky, your code will work
correctly on implementations with different representations.

How exactly does knowing how null pointers are represented make it
easier to use them?

>> > > If a function takes a pointer parameter, you need to pass a pointer
>> > > value to it.  There are cases where it might make sense to cast
>> > > an integer to void*, but they're rare.
>> >
>> > Irrelevant.
>>
>> Irrelevant to what exactly?
>
> Except for that last phrase "but they're rare", your statement amounts to
> an acceptance (inadveratant, I'm sure) of what I'm saying. You agree that
> "there are cases"; their rarity or otherwise is irrelevanbt.

You've decided that rarity is irrelevant.  Perhaps it is for whatever
you're talking about (I still haven't quite figured out what that is).
I acknowledge, of course, that there are some cases in very low-level
code where knowing pointer representation is useful.  The rarity of
those cases is extremely relevant to what I'm talking about.

>> > >                                         If you need to pass a null
>> > > pointer, use nullptr or NULL.
>> >
>> > Why? (void*) (well okay (defined_type*), actually) does perfectly well,
>> > and it does away with the clumsiness of switching between constant
>> > and variable.
>>
>> Do you mean "(void*)0"?
>
> Not particularly. (void*) applies safely to variables on systems where
> sizeof(int) == sizeof(void*).

What variables?  Of what type(s)?  Are you saying that something like
`(void*)42` is useful?

>>                          Yes, that's a valid null pointer constant, but
>> why do you prefer it to NULL or nullptr?  What do you mean by "switching
>> between constant and variable"?
>
> Pointer arithmetic.

I still don't know the answer to my question.  Perhaps an example would
help.

Please take a moment to consider that I really don't know what you're
talking about, and that perhaps that's because you haven't explained it
clearly.

Pointer arithmetic does not depend on the representation of pointers.
It's an abstraction defined in terms of the objects the pointers point
to.  Of course the implementation depends on the representation, but if
you're not writing a compiler you *probably* don't need to care about
that.

I've worked on systems where this:
    char *ptr = ...;
    char *p1 = ptr + 1;
    char *p2 = (char*)((int)ptr + 1);
would give p1 and p2 different values (and sizeof (int) == sizeof (char*)).

>> > >                                (In some low-level code, you might
>> > > store pointer values in integers.)
>> >
>> > Indeed.
>> >
>> > >                                     As for `if (parm)`, that's
>> > > valid for any scalar type.
>> >
>> > Precisely.
>>
>> Precisely what?
>
> It's valid for pointers. If that's useful, use it.

Yes, of course.  And it has nothing to do with pointer representation.
It doesn't support you claim that knowing how pointers are represented
is useful.

>>                  If parm is of pointer type, `if (parm)` tests whether
>> it's a null pointer or not, regardless of how it's represented.  You
>> seemed to be using that as an example of why it's useful to know how
>> pointers are represented.  It isn't.
>>
>> Perhaps I'm missing something.  What exactly was your point?
>
> I've stated it in every post in this thread. Knowing how NUL is
> represented can be useful.

It's spelled NULL.

I don't dispute that it *can* be useful.  I disagree that it's useful in
general.  In particular, I can write code without knowing or caring how
a null pointer is represented, and that will work correctly under
different implementations that represent it differently.

Languages define abstractions precisely so programmers don't have to
worry about the underlying details.

-- 
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]

#70798

Keith Thompson wrote:

----snip----

> I don't dispute that it *can* be useful.

If it *can* be useful, then it *is* useful.

>                                          I disagree that it's useful in
> general.

I gather you mean "widely useful". I say nothinbg about that.

----snip----

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

#70802

Ned Latham <nedlatham@woden.valhalla.oz> writes:
> Keith Thompson wrote:
>
> ----snip----
>
>> I don't dispute that it *can* be useful.
>
> If it *can* be useful, then it *is* useful.

That must be why English doesn't distinguish between "can be" and "is".
Oh, wait, it does.

>>                                          I disagree that it's useful in
>> general.
>
> I gather you mean "widely useful". I say nothinbg about that.

One clear example that you can post here would be helpful.

-- 
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]

#70796

On 12/29/19 5:45 AM, Ned Latham wrote:
> Keith Thompson wrote:
...
>> You indicated that it's useful to know how a null pointer is
>> represented.  How is it useful?  Most of the time, the representation
>> doesn't matter.
> 
> Knowing it's useful in that it enables me to use it.

Can you give an example of code involving a null pointer that you could
not have used if you had not known how null pointers are represented? I
write code that deals correctly with null pointers all the time, and to
the best of my knowledge, not a single line of code I've ever written
would need a re-write if ported to a system which uses a different
representation for null pointers.

...
> I've stated it in every post in this thread. Knowing how NUL is
> represented can be useful.

I thought that this discussion was about NULL, or null pointers, or null
pointer constants. Knowing how NUL is represented is a very different
issue, and can be useful - and has nothing to do with any of those other
three things.

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

#70799

James Kuyper wrote:
> Ned Latham wrote:
> > Keith Thompson wrote:
> > >
> > > You indicated that it's useful to know how a null pointer is
> > > represented.  How is it useful?  Most of the time, the representation
> > > doesn't matter.
> >
> > Knowing it's useful in that it enables me to use it.
>
> Can you give an example of code involving a null pointer that you could
> not have used if you had not known how null pointers are represented? I
> write code that deals correctly with null pointers all the time, and to
> the best of my knowledge, not a single line of code I've ever written
> would need a re-write if ported to a system which uses a different
> representation for null pointers.

http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html

Check AVLC and ListC, also read
http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html

The original intention was widespread compatibility, but when the
versionitis set in that faded. I won't be programming for other
than Linux anyway. When the versionitis conflicts with my standards
or violates my requirements, I'll maintain my development machine
at previous sofware version(s).

----twisted typo twittery snipped----

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

#70801

Ned Latham <nedlatham@woden.valhalla.oz> writes:
> James Kuyper wrote:
>> Ned Latham wrote:
>> > Keith Thompson wrote:
>> > >
>> > > You indicated that it's useful to know how a null pointer is
>> > > represented.  How is it useful?  Most of the time, the representation
>> > > doesn't matter.
>> >
>> > Knowing it's useful in that it enables me to use it.
>>
>> Can you give an example of code involving a null pointer that you could
>> not have used if you had not known how null pointers are represented? I
>> write code that deals correctly with null pointers all the time, and to
>> the best of my knowledge, not a single line of code I've ever written
>> would need a re-write if ported to a system which uses a different
>> representation for null pointers.
>
> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>
> Check AVLC and ListC, also read
> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html

Can you give a *succinct* example?  I'm not going to spend the time it
would take to read that.

Of course you *can* write code that depends on the representation of a
null pointer, but there is rarely a good reason to do so.

[...]

-- 
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]

#70804

On 30/12/2019 07:46, Keith Thompson wrote:
> Ned Latham <nedlatham@woden.valhalla.oz> writes:
>> James Kuyper wrote:
>>> Ned Latham wrote:
>>>> Keith Thompson wrote:
>>>>>
>>>>> You indicated that it's useful to know how a null pointer is
>>>>> represented.  How is it useful?  Most of the time, the representation
>>>>> doesn't matter.
>>>>
>>>> Knowing it's useful in that it enables me to use it.
>>>
>>> Can you give an example of code involving a null pointer that you could
>>> not have used if you had not known how null pointers are represented? I
>>> write code that deals correctly with null pointers all the time, and to
>>> the best of my knowledge, not a single line of code I've ever written
>>> would need a re-write if ported to a system which uses a different
>>> representation for null pointers.
>>
>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>>
>> Check AVLC and ListC, also read
>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
> 
> Can you give a *succinct* example?  I'm not going to spend the time it
> would take to read that.
> 

I had a quick look at the code - for the sake of your sanity, don't read
it.  I don't know what language Ned is trying to use, but it is not C++
as other people know it.  (Hint - it is full of macros like WHILE and IF
and the like, which are not defined anywhere.  And you know how C++ has
templates so that you can write container classes in a clear, type-safe
and efficient manner rather than the simple but riskier and less
efficient C-style use of void* pointers everywhere?  And it has RAII for
convenient resource handling?  New and delete rather than malloc and
free?  Ned doesn't.)

I didn't see any relevance of the the representation of null pointers in
the code.  But maybe I didn't look hard enough.  Certainly he has
managed to make enumeration constants held in a CHAR type, bitfield
structs to hold two 16-bit integers, and I gave up trying to comprehend
his "string" class.)

> Of course you *can* write code that depends on the representation of a
> null pointer, but there is rarely a good reason to do so.
> 
> [...]
> 

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

#70808

David Brown wrote:
> Keith Thompson wrote:
> > Ned Latham writes:
> > > James Kuyper wrote:
> > > > Ned Latham wrote:
> > > > > Keith Thompson wrote:
> > > > > >
> > > > > > You indicated that it's useful to know how a null pointer is
> > > > > > represented.  How is it useful?  Most of the time, the representation
> > > > > > doesn't matter.
> > > > >
> > > > > Knowing it's useful in that it enables me to use it.
> > > >
> > > > Can you give an example of code involving a null pointer that you could
> > > > not have used if you had not known how null pointers are represented? I
> > > > write code that deals correctly with null pointers all the time, and to
> > > > the best of my knowledge, not a single line of code I've ever written
> > > > would need a re-write if ported to a system which uses a different
> > > > representation for null pointers.
> > >
> > > http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
> > >
> > > Check AVLC and ListC, also read
> > > http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
> >
> > Can you give a *succinct* example?  I'm not going to spend the time it
> > would take to read that.
> >
>
> I had a quick look at the code - for the sake of your sanity, don't read
> it.

Well, if you're not going to read any documentation, why bother indeed.

>      I don't know what language Ned is trying to use,

Using, David. mclib is a working C++ library. Has been for at least ten
years.

>                                                       but it is not C++
> as other people know it.

The documentation tells you that. And why.

>                           (Hint - it is full of macros like WHILE and IF
> and the like, which are not defined anywhere.

Don't be stupider than you have to be, David.

>                                                And you know how C++ has
> templates so that you can write container classes in a clear, type-safe
> and efficient manner rather than the simple but riskier and less
> efficient C-style use of void* pointers everywhere?

The documentation would have told you that AVLC and ListC are designed to
be totally independent of type (past, present and future). Pointers can do
that; templates cannot. They're a code bloat idea, anyway.

>                                                      And it has RAII for
> convenient resource handling?  New and delete rather than malloc and
> free?  Ned doesn't.)

Those are design decisions too, idiot. The C++ library throws exceptions.
Exceptions are evil, especially in low-level code.

And BTW, it's calloc(), not malloc(). Linux malloc() has a tendency to
return "optimistic" pointers, which for my purposes is an unreliable
behaviour.

----snip----

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

#70827

On 30/12/2019 12:20, Ned Latham wrote:
> David Brown wrote:
>> Keith Thompson wrote:
>>> Ned Latham writes:
>>>> James Kuyper wrote:
>>>>> Ned Latham wrote:
>>>>>> Keith Thompson wrote:
>>>>>>>
>>>>>>> You indicated that it's useful to know how a null pointer is
>>>>>>> represented.  How is it useful?  Most of the time, the representation
>>>>>>> doesn't matter.
>>>>>>
>>>>>> Knowing it's useful in that it enables me to use it.
>>>>>
>>>>> Can you give an example of code involving a null pointer that you could
>>>>> not have used if you had not known how null pointers are represented? I
>>>>> write code that deals correctly with null pointers all the time, and to
>>>>> the best of my knowledge, not a single line of code I've ever written
>>>>> would need a re-write if ported to a system which uses a different
>>>>> representation for null pointers.
>>>>
>>>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html
>>>>
>>>> Check AVLC and ListC, also read
>>>> http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html
>>>
>>> Can you give a *succinct* example?  I'm not going to spend the time it
>>> would take to read that.
>>>
>>
>> I had a quick look at the code - for the sake of your sanity, don't read
>> it.
> 
> Well, if you're not going to read any documentation, why bother indeed.

You didn't link to documentation - you linked to the source code.  The
source code was, of course, the important part for the discussion.  (I
found the document pages too.)

> 
>>      I don't know what language Ned is trying to use,
> 
> Using, David. mclib is a working C++ library. Has been for at least ten
> years.
> 

I only looked at the source code you linked - it is not complete,
because it is written in a sort-of C, sort-of C++, sort-of something
else mix using your own macros.

>>                                                       but it is not C++
>> as other people know it.
> 
> The documentation tells you that. And why.

No, it does not.

> 
>>                           (Hint - it is full of macros like WHILE and IF
>> and the like, which are not defined anywhere.
> 
> Don't be stupider than you have to be, David.

They are not defined in the source code you linked.  They are defined in
the file "mcdef.h", which was not in the links (it is in the tarball
that can be found by a little digging from your links).

There are few thinks more irritating to programmers than some nitwit who
thinks it helps to make one programming language look like another.
Macros to try to make your C or C++ code like BASIC are /not/ a good
idea, and never have been.


> 
>>                                                And you know how C++ has
>> templates so that you can write container classes in a clear, type-safe
>> and efficient manner rather than the simple but riskier and less
>> efficient C-style use of void* pointers everywhere?
> 
> The documentation would have told you that AVLC and ListC are designed to
> be totally independent of type (past, present and future). Pointers can do
> that; templates cannot. They're a code bloat idea, anyway.

Had you linked to the documentation, it would have told me that.  It
says nothing about /why/ that might be a useful idea.  (A reasonable
answer would be "the code is from 1995, when C++ compilers had limited
and inefficient support for templates".)


> 
>>                                                      And it has RAII for
>> convenient resource handling?  New and delete rather than malloc and
>> free?  Ned doesn't.)
> 
> Those are design decisions too, idiot. The C++ library throws exceptions.
> Exceptions are evil, especially in low-level code.

RAII is orthogonal to exceptions.  You can use one feature without the
other, though they work well together.

I can appreciate that your code was written before non-throwing "new"
was widely available.  Some of your design decisions are reasonable
enough for code from 1995 - but hardly examples of how to write C++ in
this generation.


> 
> And BTW, it's calloc(), not malloc(). Linux malloc() has a tendency to
> return "optimistic" pointers, which for my purposes is an unreliable
> behaviour.
> 

Yes, you mentioned that in your documentation.  It was one of many
incorrect statements.

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

#70840

David Brown wrote:
> Ned Latham wrote:
>> David Brown wrote:
>>> Keith Thompson wrote:
>>>> Ned Latham writes:

----snip----

> I only looked at the source code you linked - it is not complete,

Bullshit.

> because it is written in a sort-of C, sort-of C++, sort-of something
> else mix using your own macros.

That's noi reason for saying "incomplete".,

>>>                                                       but it is not C++
>>> as other people know it.
>> 
>> The documentation tells you that. And why.
>
> No, it does not.

Don't lie to me about what I wrote, you fuck.

>> 
>>>                           (Hint - it is full of macros like WHILE and IF
>>> and the like, which are not defined anywhere.
>> 
>> Don't be stupider than you have to be, David.
>
> They are not defined in the source code you linked.

So? The statement is dead stupid.

>                                                      They are defined in
> the file "mcdef.h", which was not in the links (it is in the tarball
> that can be found by a little digging from your links).

There's a link to it in the documentation.

> There are few thinks more irritating to programmers than some nitwit who
> thinks it helps to make one programming language look like another.
> Macros to try to make your C or C++ code like BASIC are /not/ a good
> idea, and never have been.

"BASIC"? You're a moron.

>>>                                                And you know how C++ has
>>> templates so that you can write container classes in a clear, type-safe
>>> and efficient manner rather than the simple but riskier and less
>>> efficient C-style use of void* pointers everywhere?
>> 
>> The documentation would have told you that AVLC and ListC are designed to
>> be totally independent of type (past, present and future). Pointers can do
>> that; templates cannot. They're a code bloat idea, anyway.
>
> Had you linked to the documentation, it would have told me that.

Hmph. All you had to do to see the whole site is use BS and ENTER in
the location bar.

> It says nothing about /why/ that might be a useful idea.

You're insane. Why would type-indepedence *not* be useful?

----idiocy snipped----

>>>                                                      And it has RAII for
>>> convenient resource handling?  New and delete rather than malloc and
>>> free?  Ned doesn't.)
>> 
>> Those are design decisions too, idiot. The C++ library throws exceptions.
>> Exceptions are evil, especially in low-level code.
>
> RAII is orthogonal to exceptions.

It's bloat.

>                                    You can use one feature without the
> other, though they work well together.
>
> I can appreciate that your code was written before non-throwing "new"
> was widely available.  Some of your design decisions are reasonable
> enough for code from 1995 - but hardly examples of how to write C++ in
> this generation.

Mclib's not about C++.

>> And BTW, it's calloc(), not malloc(). Linux malloc() has a tendency to
>> return "optimistic" pointers, which for my purposes is an unreliable
>> behaviour.
>
> Yes, you mentioned that in your documentation.  It was one of many
> incorrect statements.

Dream on, Bozo.

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

#70863

On 31/12/2019 00:22, Ned Latham wrote:
> David Brown wrote:
>> Ned Latham wrote:
>>> David Brown wrote:
>>>> Keith Thompson wrote:
>>>>> Ned Latham writes:
> 
> ----snip----
> 
>> I only looked at the source code you linked - it is not complete,
> 
> Bullshit.
> 
>> because it is written in a sort-of C, sort-of C++, sort-of something
>> else mix using your own macros.
> 
> That's noi reason for saying "incomplete".,

That is not why I said it was incomplete.  I said it was incomplete
because you linked to some source code that relied on non-standard
headers that were not included in your links.

> 
>>>>                                                       but it is not C++
>>>> as other people know it.
>>>
>>> The documentation tells you that. And why.
>>
>> No, it does not.
> 
> Don't lie to me about what I wrote, you fuck.
> 

Throwing your toys out the pram does not help your argument.

>>>
>>>>                           (Hint - it is full of macros like WHILE and IF
>>>> and the like, which are not defined anywhere.
>>>
>>> Don't be stupider than you have to be, David.
>>
>> They are not defined in the source code you linked.
> 
> So? The statement is dead stupid.

It is /correct/.  You said "look at the source code in this link", and I
did.  I saw it was incomplete, and said so.  I could certainly make a
reasonable guess about how you defined macros like "WHILE", but I could
not be sure what else might be missing.  And there is a limit to how
much effort I'll put in deciphering spaghetti that mixes includes and
conditional compilation like your code.

> 
>>                                                      They are defined in
>> the file "mcdef.h", which was not in the links (it is in the tarball
>> that can be found by a little digging from your links).
> 
> There's a link to it in the documentation.

That would be the documentation that was not included in the original
links, but which I found by digging around?

Perhaps you sent the wrong links, or have not looked at the links for
some time.

> 
>> There are few thinks more irritating to programmers than some nitwit who
>> thinks it helps to make one programming language look like another.
>> Macros to try to make your C or C++ code like BASIC are /not/ a good
>> idea, and never have been.
> 
> "BASIC"? You're a moron.

	IF no tail THEN return NULL;

It's not quite BASIC, but it's C code with macros to make it look like
BASIC.

Maybe you had another language in mind, rather than BASIC - but not C or
C++.


> 
>>>>                                                And you know how C++ has
>>>> templates so that you can write container classes in a clear, type-safe
>>>> and efficient manner rather than the simple but riskier and less
>>>> efficient C-style use of void* pointers everywhere?
>>>
>>> The documentation would have told you that AVLC and ListC are designed to
>>> be totally independent of type (past, present and future). Pointers can do
>>> that; templates cannot. They're a code bloat idea, anyway.
>>
>> Had you linked to the documentation, it would have told me that.
> 
> Hmph. All you had to do to see the whole site is use BS and ENTER in
> the location bar.

It didn't take me much digging - I did not suggest it was difficult to
find.  But if you had intended for people to read the documentation it
would have made sense to link to it.

> 
>> It says nothing about /why/ that might be a useful idea.
> 
> You're insane. Why would type-indepedence *not* be useful?
> 

When it leads to inefficient and unsafe code, like yours?

> ----idiocy snipped----
> 
>>>>                                                      And it has RAII for
>>>> convenient resource handling?  New and delete rather than malloc and
>>>> free?  Ned doesn't.)
>>>
>>> Those are design decisions too, idiot. The C++ library throws exceptions.
>>> Exceptions are evil, especially in low-level code.
>>
>> RAII is orthogonal to exceptions.
> 
> It's bloat.

Please explain.

> 
>>                                    You can use one feature without the
>> other, though they work well together.
>>
>> I can appreciate that your code was written before non-throwing "new"
>> was widely available.  Some of your design decisions are reasonable
>> enough for code from 1995 - but hardly examples of how to write C++ in
>> this generation.
> 
> Mclib's not about C++.
> 

So you agree it is not written in normal C++ ?

>>> And BTW, it's calloc(), not malloc(). Linux malloc() has a tendency to
>>> return "optimistic" pointers, which for my purposes is an unreliable
>>> behaviour.
>>
>> Yes, you mentioned that in your documentation.  It was one of many
>> incorrect statements.
> 
> Dream on, Bozo.
> 

No, thanks, I will try to leave it at that - I have no plans to try to
list your mistakes.  People can read your posts in this thread and guess.

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

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

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

csiph-web