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

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

What does the "L" mean

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

Contents

  What does the "L" mean T <T@invalid.invalid> - 2019-12-03 23:38 -0800
    Re: What does the "L" mean Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-04 08:43 +0100
      Re: What does the "L" mean T <T@invalid.invalid> - 2019-12-04 00:05 -0800
        Re: What does the "L" mean Geoff <geoff@invalid.invalid> - 2019-12-04 00:32 -0800
          Re: What does the "L" mean T <T@invalid.invalid> - 2019-12-04 00:33 -0800
          Re: What does the "L" mean Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-04 11:11 +0200
            Re: What does the "L" mean Geoff <geoff@invalid.invalid> - 2019-12-04 01:14 -0800
        Re: What does the "L" mean "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2019-12-04 09:39 +0100
          Re: What does the "L" mean T <T@invalid.invalid> - 2019-12-04 00:51 -0800
        Re: What does the "L" mean Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-04 10:40 +0200
          Re: What does the "L" mean T <T@invalid.invalid> - 2019-12-04 00:56 -0800
            Re: What does the "L" mean Bo Persson <bo@bo-persson.se> - 2019-12-04 10:08 +0100
              Re: What does the "L" mean T <T@invalid.invalid> - 2019-12-04 01:20 -0800
                Re: What does the "L" mean Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-04 21:46 +0000
                  Re: What does the "L" mean Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-05 01:33 +0000
                    Re: What does the "L" mean Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-05 15:15 +0000
                      Re: What does the "L" mean Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-05 15:31 +0000
                        Re: What does the "L" mean Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-06 10:59 +0000
                          Re: What does the "L" mean Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-07 03:55 +0000
                            Re: What does the "L" mean James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-06 23:38 -0500
                            Re: What does the "L" mean Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-06 22:36 -0800
                              Re: What does the "L" mean Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-08 21:33 +0000
                      Re: What does the "L" mean Bart <bc@freeuk.com> - 2019-12-06 20:44 +0000
                  Re: What does the "L" mean Bart <bc@freeuk.com> - 2019-12-06 20:52 +0000
                  Re: What does the "L" mean Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-06 22:20 -0800
          Re: What does the "L" mean Bart <bc@freeuk.com> - 2019-12-06 16:20 +0000
            Re: What does the "L" mean boltar@nowhere.co.uk - 2019-12-06 16:30 +0000
              Re: What does the "L" mean Bart <bc@freeuk.com> - 2019-12-06 17:50 +0000
                Re: What does the "L" mean scott@slp53.sl.home (Scott Lurndal) - 2019-12-06 18:18 +0000
                Re: What does the "L" mean boltar@nowhere.co.uk - 2019-12-07 11:57 +0000
                  Re: What does the "L" mean Bart <bc@freeuk.com> - 2019-12-07 12:04 +0000
                    Re: What does the "L" mean boltar@nowhere.co.uk - 2019-12-07 13:05 +0000
                      Re: What does the "L" mean Bart <bc@freeuk.com> - 2019-12-07 13:16 +0000
                        Re: What does the "L" mean Öö Tiib <ootiib@hot.ee> - 2019-12-07 05:49 -0800
            Re: What does the "L" mean scott@slp53.sl.home (Scott Lurndal) - 2019-12-06 16:36 +0000
        Re: What does the "L" mean Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-04 13:47 +0100
          Re: What does the "L" mean Thiago Adams <thiago.adams@gmail.com> - 2019-12-04 04:57 -0800
          Re: What does the "L" mean "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2019-12-04 14:41 +0100
            Re: What does the "L" mean Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-04 15:06 +0100
          Re: What does the "L" mean James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-04 08:55 -0500
      Re: What does the "L" mean T <T@invalid.invalid> - 2019-12-04 00:34 -0800
    Re: What does the "L" mean Keith Thompson <kst-u@mib.org> - 2019-12-04 08:28 -0800
      Re: What does the "L" mean Robert Wessel <robertwessel2@yahoo.com> - 2019-12-05 09:32 -0600
        Re: What does the "L" mean Keith Thompson <kst-u@mib.org> - 2019-12-05 10:03 -0800

Page 1 of 3  [1] 2 3  Next page →

#70221 — What does the "L" mean

Hi All

MB_ICONEXCLAMATION
0x00000030L

What does the "L" at the end mean?

Many thanks,
-T

[toc] | [next] | [standalone]

#70222

Am 04.12.2019 um 08:38 schrieb T:
> Hi All
> MB_ICONEXCLAMATION
> 0x00000030L
> What does the "L" at the end mean?

It means that the integral literal is a long.

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

#70223

On 2019-12-03 23:43, Bonita Montero wrote:
> Am 04.12.2019 um 08:38 schrieb T:
>> Hi All
>> MB_ICONEXCLAMATION
>> 0x00000030L
>> What does the "L" at the end mean?
> 
> It means that the integral literal is a long.

64 bit integer?

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

#70224

On Wed, 4 Dec 2019 00:05:33 -0800, T <T@invalid.invalid> wrote:

>On 2019-12-03 23:43, Bonita Montero wrote:
>> Am 04.12.2019 um 08:38 schrieb T:
>>> Hi All
>>> MB_ICONEXCLAMATION
>>> 0x00000030L
>>> What does the "L" at the end mean?
>> 
>> It means that the integral literal is a long.
>
>64 bit integer?

No. It has 8 hexadecimal digits and they are 4 bits each. 
8 x 4 = 32 last I checked.

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

#70225

On 2019-12-04 00:32, Geoff wrote:
> On Wed, 4 Dec 2019 00:05:33 -0800, T <T@invalid.invalid> wrote:
> 
>> On 2019-12-03 23:43, Bonita Montero wrote:
>>> Am 04.12.2019 um 08:38 schrieb T:
>>>> Hi All
>>>> MB_ICONEXCLAMATION
>>>> 0x00000030L
>>>> What does the "L" at the end mean?
>>>
>>> It means that the integral literal is a long.
>>
>> 64 bit integer?
> 
> No. It has 8 hexadecimal digits and they are 4 bits each.
> 8 x 4 = 32 last I checked.
> 

Cool.  Thank you!

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

#70232

On 4.12.2019 10:32, Geoff wrote:
> On Wed, 4 Dec 2019 00:05:33 -0800, T <T@invalid.invalid> wrote:
>
>> On 2019-12-03 23:43, Bonita Montero wrote:
>>> Am 04.12.2019 um 08:38 schrieb T:
>>>> Hi All
>>>> MB_ICONEXCLAMATION
>>>> 0x00000030L
>>>> What does the "L" at the end mean?
>>>
>>> It means that the integral literal is a long.
>>
>> 64 bit integer?
>
> No. It has 8 hexadecimal digits and they are 4 bits each.
> 8 x 4 = 32 last I checked.

Does not follow. 0x30L is not 8 bits even though it has 2 hex digits only.

The reason why MB_ICONEXCLAMATION is written with 8 hex digits is 
because MS programmers *thought* long is always 32 bits.

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

#70233

On Wed, 04 Dec 2019 11:11:20 +0200, Paavo Helde
<myfirstname@osa.pri.ee> wrote:

>On 4.12.2019 10:32, Geoff wrote:
>> On Wed, 4 Dec 2019 00:05:33 -0800, T <T@invalid.invalid> wrote:
>>
>>> On 2019-12-03 23:43, Bonita Montero wrote:
>>>> Am 04.12.2019 um 08:38 schrieb T:
>>>>> Hi All
>>>>> MB_ICONEXCLAMATION
>>>>> 0x00000030L
>>>>> What does the "L" at the end mean?
>>>>
>>>> It means that the integral literal is a long.
>>>
>>> 64 bit integer?
>>
>> No. It has 8 hexadecimal digits and they are 4 bits each.
>> 8 x 4 = 32 last I checked.
>
>Does not follow. 0x30L is not 8 bits even though it has 2 hex digits only.
>
>The reason why MB_ICONEXCLAMATION is written with 8 hex digits is 
>because MS programmers *thought* long is always 32 bits.

I agree. They were signaling to themselves to expect 32 bits.
Serves me right for being a smart ass about it. :)

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

#70227

Op 04.dec..2019 om 09:05 schreef T:
> On 2019-12-03 23:43, Bonita Montero wrote:
>> Am 04.12.2019 um 08:38 schrieb T:
>>> Hi All
>>> MB_ICONEXCLAMATION
>>> 0x00000030L
>>> What does the "L" at the end mean?
>>
>> It means that the integral literal is a long.
> 
> 64 bit integer?

It means "long". The size of long depends on your platform.

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

#70229

On 2019-12-04 00:39, Fred. Zwarts wrote:
> Op 04.dec..2019 om 09:05 schreef T:
>> On 2019-12-03 23:43, Bonita Montero wrote:
>>> Am 04.12.2019 um 08:38 schrieb T:
>>>> Hi All
>>>> MB_ICONEXCLAMATION
>>>> 0x00000030L
>>>> What does the "L" at the end mean?
>>>
>>> It means that the integral literal is a long.
>>
>> 64 bit integer?
> 
> It means "long". The size of long depends on your platform.

Thank you!

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

#70228

On 4.12.2019 10:05, T wrote:
> On 2019-12-03 23:43, Bonita Montero wrote:
>> Am 04.12.2019 um 08:38 schrieb T:
>>> Hi All
>>> MB_ICONEXCLAMATION
>>> 0x00000030L
>>> What does the "L" at the end mean?
>>
>> It means that the integral literal is a long.
>
> 64 bit integer?

Depends on the platform/implementation. In this case the constant is 
from Windows headers, and in Windows/MSVC a long is 32-bit even in 
64-bit Windows.

This is basically so because long happened to be 32-bit in 16-bit DOS 35 
years ago, and MS used it a lot instead of 16-bit int (which was indeed 
unusable for many purposes). As a result, now they cannot change 'long' 
to 64-bit because they have abused it so much.

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

#70230

On 2019-12-04 00:40, Paavo Helde wrote:
> On 4.12.2019 10:05, T wrote:
>> On 2019-12-03 23:43, Bonita Montero wrote:
>>> Am 04.12.2019 um 08:38 schrieb T:
>>>> Hi All
>>>> MB_ICONEXCLAMATION
>>>> 0x00000030L
>>>> What does the "L" at the end mean?
>>>
>>> It means that the integral literal is a long.
>>
>> 64 bit integer?
> 
> Depends on the platform/implementation. In this case the constant is 
> from Windows headers, and in Windows/MSVC a long is 32-bit even in 
> 64-bit Windows.
> 
> This is basically so because long happened to be 32-bit in 16-bit DOS 35 
> years ago, and MS used it a lot instead of 16-bit int (which was indeed 
> unusable for many purposes). As a result, now they cannot change 'long' 
> to 64-bit because they have abused it so much.
> 

Great explanation.  Thank you!

In Perl6 , we have:

int8 	(int8_t in C)
int16 	(int16_t in C)
int32 	(int32_t in C)
int64 	(int64_t in C)

$ p6 'my int64 $x=0xF; say $x;'
15

$ p6 'my int64 $x=0xFFFFFFFFFFFFFFF; say $x;'
1152921504606846975

$ p6 'my int64 $x=0xFFFFFFFFFFFFFFFF; say $x;'
Cannot unbox 64 bit wide bigint into native integer
   in block <unit> at -e line 1

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

#70231

On 2019-12-04 at 09:56, T wrote:
> On 2019-12-04 00:40, Paavo Helde wrote:
>> On 4.12.2019 10:05, T wrote:
>>> On 2019-12-03 23:43, Bonita Montero wrote:
>>>> Am 04.12.2019 um 08:38 schrieb T:
>>>>> Hi All
>>>>> MB_ICONEXCLAMATION
>>>>> 0x00000030L
>>>>> What does the "L" at the end mean?
>>>>
>>>> It means that the integral literal is a long.
>>>
>>> 64 bit integer?
>>
>> Depends on the platform/implementation. In this case the constant is 
>> from Windows headers, and in Windows/MSVC a long is 32-bit even in 
>> 64-bit Windows.
>>
>> This is basically so because long happened to be 32-bit in 16-bit DOS 
>> 35 years ago, and MS used it a lot instead of 16-bit int (which was 
>> indeed unusable for many purposes). As a result, now they cannot 
>> change 'long' to 64-bit because they have abused it so much.
>>
> 
> Great explanation.  Thank you!
> 
> In Perl6 , we have:
> 
> int8     (int8_t in C)
> int16     (int16_t in C)
> int32     (int32_t in C)
> int64     (int64_t in C)
> 
> $ p6 'my int64 $x=0xF; say $x;'
> 15
> 
> $ p6 'my int64 $x=0xFFFFFFFFFFFFFFF; say $x;'
> 1152921504606846975
> 
> $ p6 'my int64 $x=0xFFFFFFFFFFFFFFFF; say $x;'
> Cannot unbox 64 bit wide bigint into native integer
>    in block <unit> at -e line 1
> 
> 

Some languages historically also target more exotic hardware, so in C 
(and C++) int and long are allowed be 36 bits instead of 16 and 32

https://stackoverflow.com/a/6972551


     Bo Persson

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

#70235

On 2019-12-04 01:08, Bo Persson wrote:
> On 2019-12-04 at 09:56, T wrote:
>> On 2019-12-04 00:40, Paavo Helde wrote:
>>> On 4.12.2019 10:05, T wrote:
>>>> On 2019-12-03 23:43, Bonita Montero wrote:
>>>>> Am 04.12.2019 um 08:38 schrieb T:
>>>>>> Hi All
>>>>>> MB_ICONEXCLAMATION
>>>>>> 0x00000030L
>>>>>> What does the "L" at the end mean?
>>>>>
>>>>> It means that the integral literal is a long.
>>>>
>>>> 64 bit integer?
>>>
>>> Depends on the platform/implementation. In this case the constant is 
>>> from Windows headers, and in Windows/MSVC a long is 32-bit even in 
>>> 64-bit Windows.
>>>
>>> This is basically so because long happened to be 32-bit in 16-bit DOS 
>>> 35 years ago, and MS used it a lot instead of 16-bit int (which was 
>>> indeed unusable for many purposes). As a result, now they cannot 
>>> change 'long' to 64-bit because they have abused it so much.
>>>
>>
>> Great explanation.  Thank you!
>>
>> In Perl6 , we have:
>>
>> int8     (int8_t in C)
>> int16     (int16_t in C)
>> int32     (int32_t in C)
>> int64     (int64_t in C)
>>
>> $ p6 'my int64 $x=0xF; say $x;'
>> 15
>>
>> $ p6 'my int64 $x=0xFFFFFFFFFFFFFFF; say $x;'
>> 1152921504606846975
>>
>> $ p6 'my int64 $x=0xFFFFFFFFFFFFFFFF; say $x;'
>> Cannot unbox 64 bit wide bigint into native integer
>>    in block <unit> at -e line 1
>>
>>
> 
> Some languages historically also target more exotic hardware, so in C 
> (and C++) int and long are allowed be 36 bits instead of 16 and 32
> 
> https://stackoverflow.com/a/6972551
> 
> 
>      Bo Persson
> 

36 bit?  My brain hurts

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

#70259

On 04/12/2019 09:20, T wrote:
> 36 bit?  My brain hurts

I've used systems where the native word size is 16, 24, 32, 36 and 64 
bit. Other values are available :(

The one that really strained C was the one where incrementing a pointer 
by 1 went to the next bit. Not byte or word. (TI GPU)

The one with 36 bits (DECSystem10) an address was the address of a word, 
and you couldn't point to a character inside the word. I didn't use C on it.

Andy

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

#70268

Vir Campestris <vir.campestris@invalid.invalid> writes:
<cut>
> The one that really strained C was the one where incrementing a
> pointer by 1 went to the next bit. Not byte or word. (TI GPU)

What problems does C have on a bit-addressed machine?

-- 
Ben.

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

#70283

On 05/12/2019 01:33, Ben Bacarisse wrote:
> Vir Campestris <vir.campestris@invalid.invalid> writes:
> <cut>
>> The one that really strained C was the one where incrementing a
>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
> 
> What problems does C have on a bit-addressed machine?
> 

Code that assumes you can copy a pointer into a number, then manipulate 
it. Lots of people do it, even though they shouldn't.

sizeof is interesting when things don't have to be whole numbers of 
bytes. (you have a greyscale graphics plane with 3 bits per pixel, 
800x600. How much RAM is that? On this thing it was literally 3 _bits_ 
x800x600, when most machines would end up unpacking the pixels into bytes.)

But it's a long time ago. I don't recall all the details.

Andy

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

#70284

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 05/12/2019 01:33, Ben Bacarisse wrote:
>> Vir Campestris <vir.campestris@invalid.invalid> writes:
>> <cut>
>>> The one that really strained C was the one where incrementing a
>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
>>
>> What problems does C have on a bit-addressed machine?
>
> Code that assumes you can copy a pointer into a number, then
> manipulate it. Lots of people do it, even though they shouldn't.

That also should work on a bit-addressed machine.  You mean, I think,
that the code assumes some very specific things about the manipulation,
most probably that (int)(p + 1) == (int)p + sizeof *p.

<cut>
-- 
Ben.

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

#70302

On 05/12/2019 15:31, Ben Bacarisse wrote:
> Vir Campestris<vir.campestris@invalid.invalid>  writes:
> 
>> On 05/12/2019 01:33, Ben Bacarisse wrote:
>>> Vir Campestris<vir.campestris@invalid.invalid>  writes:
>>> <cut>
>>>> The one that really strained C was the one where incrementing a
>>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
>>> What problems does C have on a bit-addressed machine?
>> Code that assumes you can copy a pointer into a number, then
>> manipulate it. Lots of people do it, even though they shouldn't.
> That also should work on a bit-addressed machine.  You mean, I think,
> that the code assumes some very specific things about the manipulation,
> most probably that (int)(p + 1) == (int)p + sizeof *p.

You could write code that worked on that TI chip, making assumptions 
about the way the addresses work.

You could also write code that works on the 99% of machines where

char vec[2];
assert(((int)&vec[1] - (int)vec) == 1);

works.

BTW the Dec10 - the 36 bit one I used - an int was 36 bits, but a 
character string was stored as set of 5 7-bit ASCII characters plus one 
pad bit in each word... Never used C on it though.

Andy

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

#70323

Vir Campestris <vir.campestris@invalid.invalid> writes:
<cut>
>>>> Vir Campestris<vir.campestris@invalid.invalid>  writes:
>>>> <cut>
>>>>> The one that really strained C was the one where incrementing a
>>>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
<cut>
> BTW the Dec10 - the 36 bit one I used - an int was 36 bits, but a
> character string was stored as set of 5 7-bit ASCII characters plus
> one pad bit in each word... Never used C on it though.

It would be very expensive to implement C using that packed format for
character strings.  Some C implementations on other word addressed
machines decided to make char one word; on others arithmetic was needed
to convert between word and "char" pointers.  It's notable that,
programmer assumptions aside, word addressed machines are probably more
awkward for C the bit-addressed ones.

-- 
Ben.

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

#70324

On 12/6/19 10:55 PM, Ben Bacarisse wrote:
> Vir Campestris <vir.campestris@invalid.invalid> writes:
...
>> BTW the Dec10 - the 36 bit one I used - an int was 36 bits, but a
>> character string was stored as set of 5 7-bit ASCII characters plus
>> one pad bit in each word... Never used C on it though.
> 
> It would be very expensive to implement C using that packed format for
> character strings.  Some C implementations on other word addressed
> machines decided to make char one word; on others arithmetic was needed
> to convert between word and "char" pointers.  It's notable that,
> programmer assumptions aside, word addressed machines are probably more
> awkward for C the bit-addressed ones.

I can't vouch for this from personal experience, but I remember being
informed by others in this newsgroup that the byte size was configurable
on that machine. 5 7-bit bytes was just one option. 4 9-bit bytes was
another, and somewhat less expensive than using an entire word to store
a character.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web