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

#70328

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

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

The PDP-10 had a special representation for pointing to, and
accessing, "bytes" within a word, and instructions for doing loads,
stores, and pointer arithmetic in terms of "bytes" rather than
words.  A nice thing about the PDP-10 byte pointers is the width in
bits of a "byte" is part of the stored representation in each byte
pointer.  A C implementation on a PDP-10 could choose 9-bit bytes
for 'char' without too much trouble[*].  Alternatively, for a bit of
fun, bytes could be 12 bits, with two bytes for int's, and three
bytes for long (no longer works for C11, naturally), and two 36-bit
words for long long.  But 9-bit bytes would work just fine, even for
C11.  (Sorry folks - no uint32_t in those implementations.)

[*] IIRC, "bytes" in the PDP-10 were treated as unsigned, so
signed types would need sign extension on loading.

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

#70355

On 07/12/2019 06:36, Tim Rentsch wrote:
> The PDP-10 had a special representation for pointing to, and
> accessing, "bytes" within a word, and instructions for doing loads,
> stores, and pointer arithmetic in terms of "bytes" rather than
> words.

You obviously remember it better than I do.

OTOH I was supposed to be studying Biology...

Andy

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

#70319

On 05/12/2019 15:15, Vir Campestris wrote:
> 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?

Actual physical memory, or address space?

  On this thing it was literally 3 _bits_
> x800x600, when most machines would end up unpacking the pixels into bytes.)

I made one device (video memory) that used 1024 x 6 bits. Total physical 
RAM: 768 bytes; address space: 1KB. Another that used 16K x 4 bits. 
Total physical RAM: 8KB; address space: 16KB.

Unless this is a special kind of memory known to the language, it will 
be working with the address space.


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

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

#70320

On 04/12/2019 21:46, Vir Campestris wrote:
> 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)

You'd think the compiler would turn ++p into the correct step then.

p would have to be a pointer not an int containing a point. But then it 
wouldn't work properly on x64 or ARM either.


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

That machine had a hardware extension allowing you to refer to bytes (of 
any width) inside a word using special instructions.

This used spare bits in the top half a word, while the bottom half was 
the word address. So simply incrementing such a pointer would step to 
the next word not the next byte.

A language would need to be aware of this scheme so that ++p would step 
to the next byte.

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

#70326

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

> 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 with 36 bits (DECSystem10) an address was the address of a
> word, and you couldn't point to a character inside the word.

The PDP-10 did have a format, and instructions that used that
format, to access any contiguous set of bits within a 36-bit
word.  They were called, IIRC, byte pointers, and would serve
perfectly well as a representation for 'char *' and 'void *'.

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

#70309

On 04/12/2019 08: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.
> 

At least, on Windows 'long' is consistently 32-bit.

On Linux, as I understand it, 'long' is either 32 bits or 64 bits, 
depending on whether the OS is 32 or 64 bits.

This means that if you use 'long' on Linux64, and depend on it being 64 
bits, the same program might not work properly on Linux32.

And if a 'long' is wide enough on Linux32, then on Linux64 it will 
wastefully be 64 bits (ie. an array of 'long' takes twice the memory).

(Suggestion: don't bother with 'long' at all; either use plain int (32 
bits on most relevant machines), or long long int (64 bits), which has 
the -LL suffix for constants that need to be considered 64 bits.)

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

#70311

On Fri, 6 Dec 2019 16:20:07 +0000
Bart <bc@freeuk.com> wrote:
>On 04/12/2019 08: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.
>> 
>
>At least, on Windows 'long' is consistently 32-bit.
>
>On Linux, as I understand it, 'long' is either 32 bits or 64 bits, 
>depending on whether the OS is 32 or 64 bits.
>
>This means that if you use 'long' on Linux64, and depend on it being 64 
>bits, the same program might not work properly on Linux32.
>
>And if a 'long' is wide enough on Linux32, then on Linux64 it will 
>wastefully be 64 bits (ie. an array of 'long' takes twice the memory).
>
>(Suggestion: don't bother with 'long' at all; either use plain int (32 
>bits on most relevant machines), or long long int (64 bits), which has 
>the -LL suffix for constants that need to be considered 64 bits.)

#include <stdint.h>

int32_t myint;
int64_t mylong;
uint32_t myuint;
uint64_t myulong;

Sorted.

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

#70316

On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
> On Fri, 6 Dec 2019 16:20:07 +0000
> Bart <bc@freeuk.com> wrote:
>> On 04/12/2019 08:40, Paavo Helde wrote:

>>> 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.
>>>
>>
>> At least, on Windows 'long' is consistently 32-bit.
>>
>> On Linux, as I understand it, 'long' is either 32 bits or 64 bits,
>> depending on whether the OS is 32 or 64 bits.
>>
>> This means that if you use 'long' on Linux64, and depend on it being 64
>> bits, the same program might not work properly on Linux32.
>>
>> And if a 'long' is wide enough on Linux32, then on Linux64 it will
>> wastefully be 64 bits (ie. an array of 'long' takes twice the memory).
>>
>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>> bits on most relevant machines), or long long int (64 bits), which has
>> the -LL suffix for constants that need to be considered 64 bits.)
> 
> #include <stdint.h>
> 
> int32_t myint;
> int64_t mylong;

So, do you write 3, 3L or 3LL if you wanted three be considered a 'long' 
type in calculations?

If you need to use a format code (I don't know how much that is still 
prevalent in C++), is it %d, %ld or %lld?

> Sorted.

You use a library where the author also 'sorted' by using a type 'mylong'.

Is a mylong* of your type compatible with a mylong* of theirs? (Ignoring 
the name clashing, but the question would still be how your mylong1 
relates to their mylong2.)

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

#70317

Bart <bc@freeuk.com> writes:
>On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
>> On Fri, 6 Dec 2019 16:20:07 +0000
>> Bart <bc@freeuk.com> wrote:
>>> On 04/12/2019 08:40, Paavo Helde wrote:
>
>>>> 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.
>>>>
>>>
>>> At least, on Windows 'long' is consistently 32-bit.
>>>
>>> On Linux, as I understand it, 'long' is either 32 bits or 64 bits,
>>> depending on whether the OS is 32 or 64 bits.
>>>
>>> This means that if you use 'long' on Linux64, and depend on it being 64
>>> bits, the same program might not work properly on Linux32.
>>>
>>> And if a 'long' is wide enough on Linux32, then on Linux64 it will
>>> wastefully be 64 bits (ie. an array of 'long' takes twice the memory).
>>>
>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>> bits on most relevant machines), or long long int (64 bits), which has
>>> the -LL suffix for constants that need to be considered 64 bits.)
>> 
>> #include <stdint.h>
>> 
>> int32_t myint;
>> int64_t mylong;
>
>So, do you write 3, 3L or 3LL if you wanted three be considered a 'long' 
>type in calculations?

Yes.

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

#70330

On Fri, 6 Dec 2019 17:50:39 +0000
Bart <bc@freeuk.com> wrote:
>On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
>> On Fri, 6 Dec 2019 16:20:07 +0000
>> Bart <bc@freeuk.com> wrote:
>>> On 04/12/2019 08:40, Paavo Helde wrote:
>
>>>> 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.
>>>>
>>>
>>> At least, on Windows 'long' is consistently 32-bit.
>>>
>>> On Linux, as I understand it, 'long' is either 32 bits or 64 bits,
>>> depending on whether the OS is 32 or 64 bits.
>>>
>>> This means that if you use 'long' on Linux64, and depend on it being 64
>>> bits, the same program might not work properly on Linux32.
>>>
>>> And if a 'long' is wide enough on Linux32, then on Linux64 it will
>>> wastefully be 64 bits (ie. an array of 'long' takes twice the memory).
>>>
>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>> bits on most relevant machines), or long long int (64 bits), which has
>>> the -LL suffix for constants that need to be considered 64 bits.)
>> 
>> #include <stdint.h>
>> 
>> int32_t myint;
>> int64_t mylong;
>
>So, do you write 3, 3L or 3LL if you wanted three be considered a 'long' 
>type in calculations?
>
>If you need to use a format code (I don't know how much that is still 
>prevalent in C++), is it %d, %ld or %lld?

I still use printf, cout is bloody awful for simple text formatting. I've
seen multiple lines of setfill, setwidth etc loads of times, all of which could
have been done with something like a 20 char printf format.

But yes, officially you need to know the size of what you're passing to printf
(and scanf) so it outputs correctly, though given both are built into the
compiler I imagine the compiler could be a bit smart about it and promote/demote
as appropriate but I don't know how often thats done, if ever.

>> Sorted.
>
>You use a library where the author also 'sorted' by using a type 'mylong'.

stdint.h is an official standard header file and has been for decades.

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

#70331

On 07/12/2019 11:57, boltar@nowhere.co.uk wrote:
> On Fri, 6 Dec 2019 17:50:39 +0000
> Bart <bc@freeuk.com> wrote:
>> On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
>>> On Fri, 6 Dec 2019 16:20:07 +0000
>>> Bart <bc@freeuk.com> wrote:

>>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>>> bits on most relevant machines), or long long int (64 bits), which has
>>>> the -LL suffix for constants that need to be considered 64 bits.)
>>>
>>> #include <stdint.h>
>>>
>>> int32_t myint;
>>> int64_t mylong;

>>> Sorted.
>>
>> You use a library where the author also 'sorted' by using a type 'mylong'.
> 
> stdint.h is an official standard header file and has been for decades.

Sorry, I thought from the names used in your examples that you were 
typedef-ing myint and mylong, rather than declaring instances with those 
names.

In that case, you don't know whether your typedef-ed 'mylong' is going 
to be defined on top of the same ?intN_t types as someone else's 'mylong'.

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

#70333

On Sat, 7 Dec 2019 12:04:15 +0000
Bart <bc@freeuk.com> wrote:
>On 07/12/2019 11:57, boltar@nowhere.co.uk wrote:
>> On Fri, 6 Dec 2019 17:50:39 +0000
>> Bart <bc@freeuk.com> wrote:
>>> On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
>>>> On Fri, 6 Dec 2019 16:20:07 +0000
>>>> Bart <bc@freeuk.com> wrote:
>
>>>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>>>> bits on most relevant machines), or long long int (64 bits), which has
>>>>> the -LL suffix for constants that need to be considered 64 bits.)
>>>>
>>>> #include <stdint.h>
>>>>
>>>> int32_t myint;
>>>> int64_t mylong;
>
>>>> Sorted.
>>>
>>> You use a library where the author also 'sorted' by using a type 'mylong'.
>> 
>> stdint.h is an official standard header file and has been for decades.
>
>Sorry, I thought from the names used in your examples that you were 
>typedef-ing myint and mylong, rather than declaring instances with those 
>names.
>
>In that case, you don't know whether your typedef-ed 'mylong' is going 
>to be defined on top of the same ?intN_t types as someone else's 'mylong'.
>

Eh?

If you want to be sure of the size of an int or long just use the official
typedefs for 32 and 64 bit types. I don't see what the problem is.

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

#70334

On 07/12/2019 13:05, boltar@nowhere.co.uk wrote:
> On Sat, 7 Dec 2019 12:04:15 +0000
> Bart <bc@freeuk.com> wrote:
>> On 07/12/2019 11:57, boltar@nowhere.co.uk wrote:
>>> On Fri, 6 Dec 2019 17:50:39 +0000
>>> Bart <bc@freeuk.com> wrote:
>>>> On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
>>>>> On Fri, 6 Dec 2019 16:20:07 +0000
>>>>> Bart <bc@freeuk.com> wrote:
>>
>>>>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>>>>> bits on most relevant machines), or long long int (64 bits), which has
>>>>>> the -LL suffix for constants that need to be considered 64 bits.)
>>>>>
>>>>> #include <stdint.h>
>>>>>
>>>>> int32_t myint;
>>>>> int64_t mylong;
>>
>>>>> Sorted.
>>>>
>>>> You use a library where the author also 'sorted' by using a type 'mylong'.
>>>
>>> stdint.h is an official standard header file and has been for decades.
>>
>> Sorry, I thought from the names used in your examples that you were
>> typedef-ing myint and mylong, rather than declaring instances with those
>> names.
>>
>> In that case, you don't know whether your typedef-ed 'mylong' is going
>> to be defined on top of the same ?intN_t types as someone else's 'mylong'.
>>
> 
> Eh?
> 
> If you want to be sure of the size of an int or long just use the official
> typedefs for 32 and 64 bit types. I don't see what the problem is.
> 
> 

Yeah, /I/ can do that. The problem is not everyone else will do so.

Is int64_t* the same as long*? Sometimes yes, sometimes no, sometimes it 
depends. Is a 1234L constant equivalent to int64_t, or int32_t?

Messy, but I was originally replying to this comment:

[PH:] "As a result, now they [MS] cannot change 'long' to 64-bit because 
they have abused it so much."

As I said, at least on Windows, you know it will be 32-bits.

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

#70335

On Saturday, 7 December 2019 15:16:38 UTC+2, Bart  wrote:
> On 07/12/2019 13:05, boltar@nowhere.co.uk wrote:
> > On Sat, 7 Dec 2019 12:04:15 +0000
> > Bart <bc@freeuk.com> wrote:
> >> On 07/12/2019 11:57, boltar@nowhere.co.uk wrote:
> >>> On Fri, 6 Dec 2019 17:50:39 +0000
> >>> Bart <bc@freeuk.com> wrote:
> >>>> On 06/12/2019 16:30, boltar@nowhere.co.uk wrote:
> >>>>> On Fri, 6 Dec 2019 16:20:07 +0000
> >>>>> Bart <bc@freeuk.com> wrote:
> >>
> >>>>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
> >>>>>> bits on most relevant machines), or long long int (64 bits), which has
> >>>>>> the -LL suffix for constants that need to be considered 64 bits.)
> >>>>>
> >>>>> #include <stdint.h>
> >>>>>
> >>>>> int32_t myint;
> >>>>> int64_t mylong;
> >>
> >>>>> Sorted.
> >>>>
> >>>> You use a library where the author also 'sorted' by using a type 'mylong'.
> >>>
> >>> stdint.h is an official standard header file and has been for decades.
> >>
> >> Sorry, I thought from the names used in your examples that you were
> >> typedef-ing myint and mylong, rather than declaring instances with those
> >> names.
> >>
> >> In that case, you don't know whether your typedef-ed 'mylong' is going
> >> to be defined on top of the same ?intN_t types as someone else's 'mylong'.
> >>
> > 
> > Eh?
> > 
> > If you want to be sure of the size of an int or long just use the official
> > typedefs for 32 and 64 bit types. I don't see what the problem is.
> > 
> > 
> 
> Yeah, /I/ can do that. The problem is not everyone else will do so.

That is the problem of those others who do not use official typedefs. 
Why it is problem of yours?

> Is int64_t* the same as long*? Sometimes yes, sometimes no, sometimes it 
> depends. 

If it somehow matters use std::is_same_v<int64_t*,long*>, it is compile
time bool. But I don't use long* in my code anywhere so it does not matter.

> Is a 1234L constant equivalent to int64_t, or int32_t?

Same there. I don't use any longs in code and I don't use L suffixes to
integer literals. As result it is problem of those others who do it
wrong.
 
> Messy, but I was originally replying to this comment:
> 
> [PH:] "As a result, now they [MS] cannot change 'long' to 64-bit because 
> they have abused it so much."
> 
> As I said, at least on Windows, you know it will be 32-bits.

Where Windows API has long in interface? Signed 32 bit integers seem
everywhere to be LONG or INT32 in it. So user can use conversions
to those (often nop conversions) where integrating with Windows API.
Everywhere else it does not matter.

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

#70312

Bart <bc@freeuk.com> writes:
>On 04/12/2019 08: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.
>> 
>
>At least, on Windows 'long' is consistently 32-bit.
>
>On Linux, as I understand it, 'long' is either 32 bits or 64 bits, 
>depending on whether the OS is 32 or 64 bits.
>
>This means that if you use 'long' on Linux64, and depend on it being 64 
>bits, the same program might not work properly on Linux32.
>
>And if a 'long' is wide enough on Linux32, then on Linux64 it will 
>wastefully be 64 bits (ie. an array of 'long' takes twice the memory).
>
>(Suggestion: don't bother with 'long' at all; either use plain int (32 
>bits on most relevant machines), or long long int (64 bits), which has 
>the -LL suffix for constants that need to be considered 64 bits.)

Even better.  Use the standard types uint64_t or uint_least64_t if you
need values in the range 0 .. 2^64-1, or int64_t/int_least64_t if you
need values in the range -2^63 .. +2^63-1.

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

#70236

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

Forget it, these suffixes are mostly useless as the compiler can
determine the type from the value.

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

#70237

On Wednesday, December 4, 2019 at 9:47:55 AM UTC-3, 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?
> 
> Forget it, these suffixes are mostly useless as the compiler can
> determine the type from the value.

In C we have macros to expand to the corresponding size.
For instance
UINT64_C(0x123) might expand to the integer constant 0x123ULL.

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

#70239

Op 04.dec..2019 om 13:47 schreef Bonita Montero:
>>> 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?
> 
> Forget it, these suffixes are mostly useless as the compiler can
> determine the type from the value.

The suffixes can be very important, in particular if the macros are 
later used in operations. Take as an example a platform where int is 16 
bits and long is 32 bits.

#define V1 0X7EEE
#define V2 0X7EEEL

#define R1 (2 * V1)
#define R2 (2 * V2)

Then the result of R1 is undefined because of an integer overflow, 
whereas R2 is defined.

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

#70241

> The suffixes can be very important, in particular if the macros are 
> later used in operations. Take as an example a platform where int is 16 
> bits and long is 32 bits.
> #define V1 0X7EEE
> #define V2 0X7EEEL
> #define R1 (2 * V1)
> #define R2 (2 * V2)
> Then the result of R1 is undefined because of an integer overflow, 
> whereas R2 is defined.

I wrote "mostly useless" and not "useless every time".

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

#70240

Op 04.dec..2019 om 13:47 schreef Bonita Montero:
>>> 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?
> 
> Forget it, these suffixes are mostly useless as the compiler can
> determine the type from the value.

The whole point of the suffixes is cope with the possibility (which
occurs pretty frequently) that the type that is determined by the value
differs from the one you want the constant to have. A cast can be more
specific, but a suffix is more convenient, when it's sufficient to do
what you want.

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

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

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

csiph-web