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

Groups > comp.lang.c > #76081 > unrolled thread

Array manipulation techniques

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

Contents

  Array manipulation techniques "Morten W. Petersen" <morphex@gmail.com> - 2015-11-15 09:44 +0100
    Re: Array manipulation techniques Barry Schwarz <schwarzb@dqel.com> - 2015-11-15 01:56 -0800
      Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-15 10:43 -0800
        Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 10:54 -0800
          Re: Array manipulation techniques Ian Collins <ian-news@hotmail.com> - 2015-11-16 08:13 +1300
            Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 12:50 -0800
          Re: Array manipulation techniques Les Cargill <lcargill99@comcast.com> - 2015-11-15 14:07 -0600
        Re: Array manipulation techniques Barry Schwarz <schwarzb@dqel.com> - 2015-11-15 15:12 -0800
    Re: Array manipulation techniques glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-15 09:57 +0000
    Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-15 03:02 -0800
    Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:02 -0800
      Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:05 -0800
        Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:28 -0800
          Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 12:48 -0800
          Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:05 -0800
            Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-15 19:09 -0800
            Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 22:52 -0800
              Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 23:00 -0800
                Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 07:17 +0000
                  Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 23:41 -0800
                    Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 07:47 +0000
                      Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-16 09:51 +0100
                        Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 16:49 +0000
                  Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-16 11:10 +0000
                    Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 03:33 -0800
                      Re: Array manipulation techniques Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 13:09 +0000
                        Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 05:59 -0800
                          Re: Array manipulation techniques Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 15:22 +0000
                    Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 16:57 +0000
                    Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 10:29 -0800
                      Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-17 09:02 +0100
                        Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-17 10:46 +0000
                        Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-17 07:05 -0800
                          Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-17 16:47 +0100
                            Re: Array manipulation techniques supercat@casperkitty.com - 2015-11-17 12:33 -0800
                Development Best Practices and C "nomenclature" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-16 12:15 -0500
                  Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 10:33 -0800
                    Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 10:51 -0800
                      Re: Development Best Practices and C "nomenclature" "Morten W. Petersen" <morphex@gmail.com> - 2015-11-16 20:14 +0100
                        Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 11:28 -0800
                          Re: Development Best Practices and C "nomenclature" "Morten W. Petersen" <morphex@gmail.com> - 2015-11-17 00:20 +0100
                        Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-17 10:03 +0100
                          Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-17 08:54 -0800
                            Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-17 20:12 +0000
                              Re: Development Best Practices and C "nomenclature" Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 23:38 -0600
                                Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:22 +0000
                      Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 20:25 +0000
                      Re: Development Best Practices and C "nomenclature" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-16 16:20 -0500
                        Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 13:28 -0800
                        Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 21:30 +0000
                        Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 14:38 -0800
                          Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 14:52 -0800
                            Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-17 22:51 -0800
                              Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 06:59 +0000
                    Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 20:24 +0000
                    Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-17 09:55 +0100
                      Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-17 23:00 +0000
                  Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:55 +0000
                    Re: Development Best Practices and C "nomenclature" Ian Collins <ian-news@hotmail.com> - 2015-11-18 12:07 +1300
                      Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-17 18:45 -0500
                        Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-18 15:50 +0100
                          Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-18 08:39 -0800
                            Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:07 -0800
                              Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-20 14:16 -0800
                                [OT] Re: Development Best Practices and C "nomenclature" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 17:30 -0500
                                  Re: [OT] Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 19:29 -0800
                                  Re: [OT] Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-21 22:44 +0000
                            Re: Development Best Practices and C "nomenclature" jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-22 00:09 +0100
                              Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-21 15:57 -0800
                                Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-21 20:49 -0500
                                  Re: Development Best Practices and C "nomenclature" Rosario19 <Ros@invalid.invalid> - 2015-11-25 10:13 +0100
                                    Re: Development Best Practices and C "nomenclature" "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-25 18:58 -0500
                                      Re: Development Best Practices and C "nomenclature" Rosario19 <Ros@invalid.invalid> - 2015-11-26 12:13 +0100
                                        Re: Development Best Practices and C "nomenclature" "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-26 07:22 -0500
                                Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 14:51 +0000
                                  Re: Development Best Practices and C "nomenclature" "Charles Richmond" <numerist@aquaporin4.com> - 2015-11-23 15:53 -0600
                          Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 08:55 -0800
                            Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-18 09:17 -0800
                          Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:19 -0500
                          Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:32 +0000
                  Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:17 -0800
                    Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 07:08 +0000
                      Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 13:52 -0800
        Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:03 -0800
      Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-15 15:09 -0500
      Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-15 21:47 +0000
      Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:02 -0800
      Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 10:44 -0800
        Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-16 11:13 -0800
          Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 11:57 -0800
            Re: Array manipulation techniques Ian Collins <ian-news@hotmail.com> - 2015-11-17 10:30 +1300
          Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-17 08:11 -0500
            Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-17 13:24 +0000
            Re: Array manipulation techniques Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:09 -0800
              Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 16:20 -0500

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

#76165

On 16/11/15 07:41, asetofsymbols@gmail.com wrote:
> Richard Heathfield wrote:
> On 16/11/15 07:00, asetof...@gmail.com wrote:
>> This seems right:
>> #define u8 unsigned char
>
> Already it isn't.
>
> If you want a new name for an existing type, use typedef, not #define.
> And pick a meaningful name. u8 is not a good synonym for unsigned char
> _____
> I in my code it appear to use few typedef
> and no enum
>
> But the name u8 is ok as name

No, it isn't.

> especially when one has to write
> the function definition:
> u8* f(i32 a, u32 b)
> it is better (as visual effects)
> than
> unsigned char* f(int a, unsigned b)

I y a r, y w h n p re th rp.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#76168

On 16/11/15 08:47, Richard Heathfield wrote:
> On 16/11/15 07:41, asetofsymbols@gmail.com wrote:
>> Richard Heathfield wrote:
>> On 16/11/15 07:00, asetof...@gmail.com wrote:
>>> This seems right:
>>> #define u8 unsigned char
>>
>> Already it isn't.
>>
>> If you want a new name for an existing type, use typedef, not #define.
>> And pick a meaningful name. u8 is not a good synonym for unsigned char
>> _____
>> I in my code it appear to use few typedef
>> and no enum
>>
>> But the name u8 is ok as name
> 
> No, it isn't.
> 
>> especially when one has to write
>> the function definition:
>> u8* f(i32 a, u32 b)
>> it is better (as visual effects)
>> than
>> unsigned char* f(int a, unsigned b)
> 
> I y a r, y w h n p re th rp.
> 

I h n p re th rp, b h i s wr.

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

#76187

On 16/11/15 08:51, David Brown wrote:
> On 16/11/15 08:47, Richard Heathfield wrote:
>> On 16/11/15 07:41, asetofsymbols@gmail.com wrote:
>>> Richard Heathfield wrote:
>>> On 16/11/15 07:00, asetof...@gmail.com wrote:
>>>> This seems right:
>>>> #define u8 unsigned char
>>>
>>> Already it isn't.
>>>
>>> If you want a new name for an existing type, use typedef, not #define.
>>> And pick a meaningful name. u8 is not a good synonym for unsigned char
>>> _____
>>> I in my code it appear to use few typedef
>>> and no enum
>>>
>>> But the name u8 is ok as name
>>
>> No, it isn't.
>>
>>> especially when one has to write
>>> the function definition:
>>> u8* f(i32 a, u32 b)
>>> it is better (as visual effects)
>>> than
>>> unsigned char* f(int a, unsigned b)
>>
>> I y a r, y w h n p re th rp.
>>
>
> I h n p re th rp, b h i s wr.

I c a m.  :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#76173

On 16/11/2015 07:17, Richard Heathfield wrote:
> On 16/11/15 07:00, asetofsymbols@gmail.com wrote:
>> This seems right:
>> #define u8 unsigned char
>
> Already it isn't.
>
> If you want a new name for an existing type, use typedef, not #define.
> And pick a meaningful name. u8 is not a good synonym for unsigned char.

What about 'byte'?

You see u8, u16, u32 etc all the time and it is perfectly obvious what 
they mean or what they are intended to represent.

So, given that 'unsigned char' is too long-winded and unwieldy, that 
'unsigned_char' would be pointless, and sill unwieldy, and 'uint8_t' is 
too ugly, I'd be interested in what typedef name /you/ would choose 
rather than 'unsigned char'.

And would your choice still be the same is this was needed for storing 
small numbers between, say, 0 and 255, rather than actual characters.

-- 
Bartc

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

#76175

On Monday, November 16, 2015 at 11:10:42 AM UTC, Bart wrote:
> On 16/11/2015 07:17, Richard Heathfield wrote:
> > On 16/11/15 07:00, asetofsymbols@gmail.com wrote:
> >> This seems right:
> >> #define u8 unsigned char
> >
> > Already it isn't.
> >
> > If you want a new name for an existing type, use typedef, not #define.
> > And pick a meaningful name. u8 is not a good synonym for unsigned char.
> 
> What about 'byte'?
> 
> You see u8, u16, u32 etc all the time and it is perfectly obvious what 
> they mean or what they are intended to represent.
> 
> So, given that 'unsigned char' is too long-winded and unwieldy, that 
> 'unsigned_char' would be pointless, and sill unwieldy, and 'uint8_t' is 
> too ugly, I'd be interested in what typedef name /you/ would choose 
> rather than 'unsigned char'.
> 
> And would your choice still be the same is this was needed for storing 
> small numbers between, say, 0 and 255, rather than actual characters.
> 
Ideally I'd use "byte" for data which consists of bits arranged in 8-bit chunks,
uint8_t for unsigned values that go from 0-255, int8_t for signed values
that go from -128 to 127, and char for ascii/ UTF-8 values. (If you have 
converted UTF-8 to a code point, pass around as int).
That leaves an identifier to represent patterns of machine memory, where CHAR_BIT
might not be 8. These should be passed about as void *s, so you'll hardly every use
such a identifier, except for things like implementing memcpy() itself.

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

#76179

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> Ideally I'd use [...] uint8_t for unsigned values that go from 0-255,
> [...] and char for ascii/ UTF-8 values. (If you have converted UTF-8
> to a code point, pass around as int).

That's only safe if int is big enough.  Also, I would favour uint8_t (or
unsigned char in older code) for UTF-8.  The bytes in UTF-8 are not
characters (at least not always) so char seems to be a bit of lie --
they are either positive numbers or bit patterns (depending on your point
of view) that combine arithmetically to represent characters.

<snip>
-- 
Ben.

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

#76183

On Monday, November 16, 2015 at 1:09:33 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
> > Ideally I'd use [...] uint8_t for unsigned values that go from 0-255,
> > [...] and char for ascii/ UTF-8 values. (If you have converted UTF-8
> > to a code point, pass around as int).
> 
> That's only safe if int is big enough.  Also, I would favour uint8_t (or
> unsigned char in older code) for UTF-8.  The bytes in UTF-8 are not
> characters (at least not always) so char seems to be a bit of lie --
> they are either positive numbers or bit patterns (depending on your point
> of view) that combine arithmetically to represent characters.
> 
But the point of UTF-8 is that it's as backwards compatible as an extended coding
can be with ascii. Most C programs are full of functions that take char *s and
process them transparently as tags or messages.

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

#76185

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Monday, November 16, 2015 at 1:09:33 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>> > Ideally I'd use [...] uint8_t for unsigned values that go from 0-255,
>> > [...] and char for ascii/ UTF-8 values. (If you have converted UTF-8
>> > to a code point, pass around as int).
>> 
>> That's only safe if int is big enough.  Also, I would favour uint8_t (or
>> unsigned char in older code) for UTF-8.  The bytes in UTF-8 are not
>> characters (at least not always) so char seems to be a bit of lie --
>> they are either positive numbers or bit patterns (depending on your point
>> of view) that combine arithmetically to represent characters.
>> 
> But the point of UTF-8 is that it's as backwards compatible as an
> extended coding can be with ascii. Most C programs are full of
> functions that take char *s and process them transparently as tags or
> messages.

Yes, I would not advice changing existing declarations just because you
might now be handling UTF-8.  I was talking about the situation where I
knew the data and wanted the "best" type for it.

-- 
Ben.

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

#76188

On 16/11/15 11:10, BartC wrote:
> On 16/11/2015 07:17, Richard Heathfield wrote:
>> On 16/11/15 07:00, asetofsymbols@gmail.com wrote:
>>> This seems right:
>>> #define u8 unsigned char
>>
>> Already it isn't.
>>
>> If you want a new name for an existing type, use typedef, not #define.
>> And pick a meaningful name. u8 is not a good synonym for unsigned char.
>
> What about 'byte'?

I'm actually fine with 'unsigned char'. But yes, if you have to have a 
synonym for it, 'byte' is a good alternative.

> You see u8, u16, u32 etc all the time

You might. I tend to see them only on comp.lang.c.

> and it is perfectly obvious what
> they mean or what they are intended to represent.

Perfectly obvious to you? Fine. Less obvious to me. That doesn't mean I 
couldn't get used to it, rather in the same way that I can get used to 
u, l8, 2mro, and other texemes of that ilk. It doesn't mean I have to 
like it.

> So, given that 'unsigned char' is too long-winded and unwieldy,

Clearly, for you it is a given. For me, it isn't.

> that
> 'unsigned_char' would be pointless,

Agreed.

> and sill unwieldy, and 'uint8_t' is too ugly,

Ditto.

> I'd be interested in what typedef name /you/ would choose
> rather than 'unsigned char'.

'byte' is a good choice, if one must choose.

> And would your choice still be the same is this was needed for storing
> small numbers between, say, 0 and 255, rather than actual characters.

I wouldn't use unsigned char for storing "actual characters" per se. 
Rather, I would (and in fact do) use it for storing arbitrary 'binary' 
data. If I want to store characters, I will store them in an array of 
char. That is what char is for.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#76190

BartC <bc@freeuk.com> writes:
> On 16/11/2015 07:17, Richard Heathfield wrote:
>> On 16/11/15 07:00, asetofsymbols@gmail.com wrote:
>>> This seems right:
>>> #define u8 unsigned char
>>
>> Already it isn't.
>>
>> If you want a new name for an existing type, use typedef, not #define.
>> And pick a meaningful name. u8 is not a good synonym for unsigned char.
>
> What about 'byte'?
>
> You see u8, u16, u32 etc all the time and it is perfectly obvious what 
> they mean or what they are intended to represent.
>
> So, given that 'unsigned char' is too long-winded and unwieldy, that 
> 'unsigned_char' would be pointless, and sill unwieldy, and 'uint8_t' is 
> too ugly, I'd be interested in what typedef name /you/ would choose 
> rather than 'unsigned char'.

I'd use `unsigned char`.  I *might* consider `typedef unsigned
char byte;`, but I probably wouldn't bother.  I know exactly what
`unsigned char` means, and I'd expect the same of anyone reading
my code.  I don't consider it unwieldy -- though I might have preferred
it if the language had made "byte" a keyword.

> And would your choice still be the same is this was needed for storing 
> small numbers between, say, 0 and 255, rather than actual characters.

Yes.

As for "u8", I see no point in inventing new naming conventions for
existing entities that already have perfectly good names.  (Saving a few
keystrokes is a negligible advantage, far outweighed by the added
confusion.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76222

On 16/11/15 19:29, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 16/11/2015 07:17, Richard Heathfield wrote:
>>> On 16/11/15 07:00, asetofsymbols@gmail.com wrote:
>>>> This seems right:
>>>> #define u8 unsigned char
>>>
>>> Already it isn't.
>>>
>>> If you want a new name for an existing type, use typedef, not #define.
>>> And pick a meaningful name. u8 is not a good synonym for unsigned char.
>>
>> What about 'byte'?
>>
>> You see u8, u16, u32 etc all the time and it is perfectly obvious what 
>> they mean or what they are intended to represent.
>>
>> So, given that 'unsigned char' is too long-winded and unwieldy, that 
>> 'unsigned_char' would be pointless, and sill unwieldy, and 'uint8_t' is 
>> too ugly, I'd be interested in what typedef name /you/ would choose 
>> rather than 'unsigned char'.
> 
> I'd use `unsigned char`.  I *might* consider `typedef unsigned
> char byte;`, but I probably wouldn't bother.  I know exactly what
> `unsigned char` means, and I'd expect the same of anyone reading
> my code.  I don't consider it unwieldy -- though I might have preferred
> it if the language had made "byte" a keyword.
> 

I think it would be nice if the language had a defined "byte" type for
plain data storage.  But a problem there is that the C standards use the
term "byte" in a different way from almost every other document in the
computing world, which would lead to confusion.

For me, "char" is a type for holding characters.  Types for small
integers are uint8_t and int8_t, and uint8_t is my choice of type for "a
piece of data".  I might consider "typedef uint8_t byte;", but haven't
felt the need so far.

As for "uint8_t" being ugly, I think it is clear enough, and much nicer
than the overly short u8 and friends.  It is also, for better or worse,
the standard.

>> And would your choice still be the same is this was needed for storing 
>> small numbers between, say, 0 and 255, rather than actual characters.
> 
> Yes.
> 
> As for "u8", I see no point in inventing new naming conventions for
> existing entities that already have perfectly good names.  (Saving a few
> keystrokes is a negligible advantage, far outweighed by the added
> confusion.)
> 

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

#76230

On 17/11/2015 08:02, David Brown wrote:
> On 16/11/15 19:29, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:

>>> So, given that 'unsigned char' is too long-winded and unwieldy, that
>>> 'unsigned_char' would be pointless, and sill unwieldy, and 'uint8_t' is
>>> too ugly, I'd be interested in what typedef name /you/ would choose
>>> rather than 'unsigned char'.
>>
>> I'd use `unsigned char`.  I *might* consider `typedef unsigned
>> char byte;`, but I probably wouldn't bother.  I know exactly what
>> `unsigned char` means, and I'd expect the same of anyone reading
>> my code.  I don't consider it unwieldy -- though I might have preferred
>> it if the language had made "byte" a keyword.
>>
>
> I think it would be nice if the language had a defined "byte" type for
> plain data storage.  But a problem there is that the C standards use the
> term "byte" in a different way from almost every other document in the
> computing world, which would lead to confusion.
>
> For me, "char" is a type for holding characters.  Types for small
> integers are uint8_t and int8_t, and uint8_t is my choice of type for "a
> piece of data".  I might consider "typedef uint8_t byte;", but haven't
> felt the need so far.
>
> As for "uint8_t" being ugly, I think it is clear enough, and much nicer
> than the overly short u8 and friends.  It is also, for better or worse,
> the standard.

(I had at look at my language to see how many ways there were of 
denoting a byte type. I think there were about 13! That's before adding 
user-defined types either.

List here: http://pastebin.com/F1hSeJa1

At least you have a good selection to choose from, and you can't say any 
of them are long-winded. Ugly perhaps...)

-- 
Bartc

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

#76243

David Brown <david.brown@hesbynett.no> writes:
[...]
> I think it would be nice if the language had a defined "byte" type for
> plain data storage.  But a problem there is that the C standards use the
> term "byte" in a different way from almost every other document in the
> computing world, which would lead to confusion.

More formal documents use "octet" to refer to 8-bit quantities.  Bytes
were not originally just 8 bits, though they *almost* always are today.

> For me, "char" is a type for holding characters.  Types for small
> integers are uint8_t and int8_t, and uint8_t is my choice of type for "a
> piece of data".  I might consider "typedef uint8_t byte;", but haven't
> felt the need so far.
>
> As for "uint8_t" being ugly, I think it is clear enough, and much nicer
> than the overly short u8 and friends.  It is also, for better or worse,
> the standard.

"uint8_t" specifies exactly 8 bits.  If that's what you need, that's
fine, but if you want the fundamental storage unit without
overspecifying its size "unsigned char" is just the thing.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76245

On 17/11/15 16:05, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I think it would be nice if the language had a defined "byte" type for
>> plain data storage.  But a problem there is that the C standards use the
>> term "byte" in a different way from almost every other document in the
>> computing world, which would lead to confusion.
> 
> More formal documents use "octet" to refer to 8-bit quantities.  Bytes
> were not originally just 8 bits, though they *almost* always are today.

There are a few areas where the term "octet" is used - RFC's around
network protocols are a prime example (so "almost every other document"
was an exaggeration).

> 
>> For me, "char" is a type for holding characters.  Types for small
>> integers are uint8_t and int8_t, and uint8_t is my choice of type for "a
>> piece of data".  I might consider "typedef uint8_t byte;", but haven't
>> felt the need so far.
>>
>> As for "uint8_t" being ugly, I think it is clear enough, and much nicer
>> than the overly short u8 and friends.  It is also, for better or worse,
>> the standard.
> 
> "uint8_t" specifies exactly 8 bits.  If that's what you need, that's
> fine, but if you want the fundamental storage unit without
> overspecifying its size "unsigned char" is just the thing.
> 

I'd be reasonably happy with some other term that doesn't force the 8
bit specification.  But I don't like "char" for storage - the name
"char" implies "character" to me, and "unsigned character" is therefore
meaningless.  "byte" is certainly better, and maybe is the best choice
for C since it fits the definition used in the standard as the smallest
addressable unit of memory.

And then if all non-8-bit char systems were banned from the next C
standards, I'd be even happier :-)

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

#76293

On Tuesday, November 17, 2015 at 9:47:14 AM UTC-6, David Brown wrote:
> I'd be reasonably happy with some other term that doesn't force the 8
> bit specification.  But I don't like "char" for storage - the name
> "char" implies "character" to me, and "unsigned character" is therefore
> meaningless.  "byte" is certainly better, and maybe is the best choice
> for C since it fits the definition used in the standard as the smallest
> addressable unit of memory.

I think it's unfortunate that "char" was defined to be the smallest type,
given that there are systems whose smallest unit of addressable memory is
smaller than 8 bits, and the requirement that everything be a multiple of
"char" makes it impossible to take advantage of that in C.  Further, code
which needs to work with actual characters is in many cases made needlessly
inefficient because the Standard assumes that character pointers may
alias anything else, even though pointers to actual characters almost never
alias anything.

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

#76189 — Development Best Practices and C "nomenclature"

For decades, I worked as a professional programmer, both developing new code
and maintaining already-written code. It did not take me long in my job to
learn that
 - Computers do not care how verbose your nomenclature is; nomenclature only
   (marginally) affects compile time, and /rarely/ (if ever) affects run time.

 - Programmers, on the other hand, /do/ care how verbose your nomenclature is.
   Readable code with a clear, understandable naming convention allows /any/
   programmer conversant in the language (including the original author of the
   code) to read, analyze and revise the code as necessary. Often, it even
   permits programmers who are /not/ conversant in the language to read and
   understand the intent (if not the actual operation) of the code.

Thus, from my professional standpoint, readable code is much better than
compact code.


On Monday November 16 2015 02:00, in comp.lang.c, "asetofsymbols@gmail.com"
<asetofsymbols@gmail.com> wrote:

> This seems right:
> #define u8 unsigned char
> #define i32 int
> #define u32 unsigned int
> 
> #define R return
> #define F for

These are the sorts of things I would expect to see in "personal" code (code
not intended for anyone's eyes other than the author). Use these, and you
have managed to create "write-only" code. 

Just my two cents worth.
Now, get off my lawn  ;-)
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#76191 — Re: Development Best Practices and C "nomenclature"

On Monday, November 16, 2015 at 5:15:17 PM UTC, Lew Pitcher wrote:
> 
>  - Programmers, on the other hand, /do/ care how verbose your 
> nomenclature is.
>    Readable code with a clear, understandable naming convention
>  allows /any/ programmer conversant in the language (including the
> original author of the code) to read, analyze and revise the code as
> necessary. Often, it even permits programmers who are /not/ conversant 
> in the language to read and understand the intent (if not the actual
> operation) of the code.
> 
> Thus, from my professional standpoint, readable code is much better than
> compact code.
> 
Code that uses long identifiers is more readable to someone completely
new to the environment, but less readable to someone with a degree
of familiarity.
Mathematical convention is to use single characters as identifiers,
for a good reason, which is that it make expressions a lot easier
to read. No mainstream programming language supports the
ab equals a multiplied by b syntax, but you should try not to get
too far from mathematical conventions, especially in code which is
essentially numerical.

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

#76194 — Re: Development Best Practices and C "nomenclature"

I have a different experience;
The code more readable:
1)
use long names for functions
global variable and constants
that are used few times

2) use
short names
for the few key word language use,
for basic type language use
for the most used
functions, and 
for the most used macro

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

#76196 — Re: Development Best Practices and C "nomenclature"

On 16.11.2015 19:51, asetofsymbols@gmail.com wrote:
> I have a different experience;
> The code more readable:
> 1)
> use long names for functions
> global variable and constants
> that are used few times

Well, I like using easily understandable names, but was thinking about
it the other day.. if a function with a long name is called many, many
times - doesn't that require more space and time than a function with a
short name?

-Morten

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

#76197 — Re: Development Best Practices and C "nomenclature"

Morten wrote:
Well, I like using easily understandable names, but was thinking about 
it the other day.. if a function with a long name is called many, many 
times - doesn't that require more space and time than a function with a 
short name? 

-Morten
----------
For what depends for machine
it should be the same
Long names, short names
are all (32 bit 64 bit 16 bit depend of the machine) address for the machine
only one number...

For one person read the code is not
the same
long names would describe code better
but if consume too much line space
their vantage vanish 
This is my personal opinion on
the few lines of code I have seen
(I'm not an expert)

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

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

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

csiph-web